触发器性能通常比较低？？？？

Question

在线库 用了若干触发器
检查慢查询的查询， 发现这些有触发器的表 在慢查询里出现频率是相当的高反复思考
-------------来自前辈的建议
总体而言，触发器性能通常比较低。当运行触发器时，系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上，而删除表和插入表总是位于内存中。可见触发器所参照的其它表的位置决定了操作要花费的时间长短。
在实际的项目中，不推荐使用触发器。我的在线db 并发性很高 ， 而且做了单向复制，正好这些有触发器的表都是复制表。 总之感觉饿这些表好慢困惑：我该如何才能提高性能 。  是否需要停掉全部的触发器。te 25w记录这个表有2个触发器  复制表
user 10w 记录 有2个触发器    复制表
account 10w记录 有1个触发器  复制表
------------------这种情况是否压迫我停掉所有触发器！！ （实在头疼基本慢查询都是这些表  其他大表反倒慢查询不会那么多
当然这些表使用是相当频繁的 ）

Answer 1

他本质也是个存储过程 ---------------按照道理必然占用表资源  ，造成lock相当大。 存储过程放在服务器段（db server ）执行 ，导致也好用服务器资源。 总体赶不上 java code ， 客户端web服务器可以分担部分计算资源，减轻db压力

Answer 2

一样啊dml频繁的表还是别用trigger比较好。

Answer 3

于直接使用临时表来创建中间表，其速度不如人意，因而就有了把临时表建成内存表的想法。但内存表和临时表的区别且并不熟悉，需要查找资料了。
一开始以为临时表是创建后存在，当连接断开时临时表就会被删除，即临时表是存在于磁盘上的。而实际操作中发现临时表创建后去目录下查看发现并没有发现对应的临时表文件（未断开链接）.因而猜测临时表的数据和结构都是存放在内存中，而不是在磁盘中.
    这样一想内存表不是也是存在在内存中吗，那么他和临时表有什么区别？他们的速度是什么样子？
    查找了官方手册有以下的一些解释：
The MEMORY storage engine creates tables with contents that are stored in memory. Formerly, these were known as HEAP tables. MEMORY is the preferred term, although HEAP remains supported for backward compatibility.
Each MEMORY table is associated with one disk file. The filename begins with the table name and has an extension of .frm to indicate that it stores the table definition.
由此可以看出来内存表会把表结构存放在磁盘上 ，把数据放在内存中 。
并做了以下实验：
临时表
mysql> create temporary table tmp1(id int not null);
Query OK, 0 rows affected (0.00 sec)
mysql> show create table tmp1;
+-------+----------------------------------------------------------------------------------------------+
| Table | Create Table                                                                               |
+-------+----------------------------------------------------------------------------------------------+
| tmp1   | CREATE TEMPORARY TABLE `tmp1` ( `id` int(11) NOT NULL) ENGINE=MyISAM DEFAULT CHARSET=utf8    |
+-------+----------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
内存表
mysql> create table tmp2(id int not null) TYPE＝HEAP;
Query OK, 0 rows affected (0.00 sec)
mysql> show create table tmp2;
+-------+------------------------------------------------------------------------------------+
| Table | Create Table                                                                       |
+-------+------------------------------------------------------------------------------------+
| tmp2   | CREATE TABLE `tmp2` (
   `id` int(11) NOT NULL
) ENGINE=MEMORY DEFAULT CHARSET=utf8 |
+-------+------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
可以看出来临时表和内存表的ENGINE 不同，临时表默认的是MyISAM,而内存表是MEMORY .去数据库目录查看，发现tmp2.frm而没有tmp1表的任何文件。看来实际情况是符合官方解释的。
那么速度方面呢（即MyISAM和MEMORY之间的区别）？
实验开始：
实现手段：对基于2张千万级别的表做一些OLAP切分操作，中间表的建立使用2种不同的方式。最后把中间表的数据按照要求取出，插入到结果表中
实验目的;测试临时内存表和临时表的速度
1.中间表的建立使用Create temporary table type = heap 即 把中间表建立成临时内存表
2.中间表直接使用Create temporary table建立
实验结果：
临时内存表： 1小时
1 2008-09-25 11:03:48
1 2008-09-25 12:03:39
临时表：1小时17分钟
2 2008-09-25 12:25:28
2 2008-09-25 13:42:37
由此发现MEMORY比MyISAM快大概20％。
接着查找官方手册：
As indicated by the name, MEMORY tables are stored in memory. They use hash indexes by default, which makes them very fast, and very useful for creating temporary tables. However, when the server shuts down, all rows stored in MEMORY tables are lost. The tables themselves continue to exist because their definitions are stored in .frm files on disk, but they are empty when the server restarts.
可以看出来MEMORY确实是very fast，and very useful for creating temporary tables .把临时表和内存表放在一起使用确实会快不少 ：create table tmp2(id int not null) engine memory;
内存表的建立还有一些限制条件：
MEMORY tables cannot contain        BLOB or TEXT columns. HEAP不支持BLOB/TEXT列。   
The server needs sufficient memory to maintain all   MEMORY tables that are in use at the same time. 在同一时间需要足够的内存.
To free memory used by a MEMORY table when   you no longer require its contents, you should execute DELETE or TRUNCATE TABLE, or remove the table altogether using DROP        TABLE.为了释放内存，你应该执行DELETE FROM heap_table或DROP TABLE heap_table。