触发器性能为什么通常比较低?

-------------来自前辈的建议
1，总体而言，触发器性能通常比较低。当运行触发器时，系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上，而删除表和插入表总是位于内存中。可见触发器所参照的其它表的位置决定了操作要花费的时间长短。

2，也有人说触发器的性能取决于,触发后执行脚本的内容.

3，另外微软官方说:执行触发器会影响大容量导入操作的性能
意思说,如果是小容量导入就不会影响性能了?

难道以上都对吗?另外" 系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上"
这句话不够明白,望各位大牛解释下,哈哈

参照其他表是什么东东?为什么不在内存和数据库设备上呢?


性能的影响是指什么呢?CPU?内存?磁盘IO?

现在有一个DDL触发器,想把DDL触发的内容都放在一个表中.而表又有一个DML触发的动作,来判断如果满足的就插入到另外一个表中
类似一个联级触发的过程.
另外一种实现方式呢,一开始就是在DDL触发中就按规则写好,如果满足条件的话就同时插入.
但是这样是否会影响到DDL的动作,比如重建索引的时候会有大量的记录录入,这个时候是否就没上面那种可以分担负载了?

17 个解决方案

#1

约束能解决的问题
通常不要让触发器去做

#2

引用 1 楼 angel1201 的回复:

约束能解决的问题
通常不要让触发器去做

不是为了约束,而是出于记录,这个程序很难实现DDL的,怎么能让程序开发人员开发记录这些呢?这个是一个记录审核的过程.

#3

1，总体而言，触发器性能通常比较低。当运行触发器时，系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上，而删除表和插入表总是位于内存中。可见触发器所参照的其它表的位置决定了操作要花费的时间长短。
====
意思是说，需要用触发器解决的问题通常会涉及到其它表。修改这个表的数据时，触发器还需要读取其它表的数据（可能不在内存或缓存，要到磁盘读取），往往是很大的性能开销。

2，也有人说触发器的性能取决于,触发后执行脚本的内容.
====
触发器的性能比约束差。触发器中执行脚本的内容越复杂，性能越差。

3，另外微软官方说:执行触发器会影响大容量导入操作的性能
====
大容量导入的性能影响大。小容易插入的性能影响小。
官方的说法是“会”，不是“只会”。

#4

引用 2 楼 lcw321321 的回复:

引用 1 楼 angel1201 的回复:
约束能解决的问题
通常不要让触发器去做

不是为了约束,而是出于记录,这个程序很难实现DDL的,怎么能让程序开发人员开发记录这些呢?这个是一个记录审核的过程.

约束能解决的问题，通常不要让触发器去做。

只能用触发器做的事情，就只好考虑编写更精简、高效的触发器语句。或者是用存储过程封装。

#5

能不用 尽量不要用

#6

"系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上"
这句话不够明白,望各位大牛解释下,哈哈

参照其他表是什么东东?为什么不在内存和数据库设备上呢?


=====>

有些表是读在内存里的 有些则存在硬盘上没读出来的 
触发器由于可能涉及到多表 所以自然要去读取这些表(这就是参考其他表)

#7

引用楼主 lcw321321 的回复:

-------------来自前辈的建议
1，总体而言，触发器性能通常比较低。当运行触发器时，系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上，而删除表和插入表总是位于内存中。可见触发器所参照的其它表的位置决定了操作要花费的时间长短。

2，也有人说触发器的性能取决于,触发后执行脚本的内容.

3，另外微软官方说:执行触发器会影响大容量导入操作的……

首先解释一下性能

性能就牵扯到性能优化

优化分两个方面

1 硬件优化

2 系统或软件优化 （包括SQL SERVER 语句，表结构，索引，架构）

你所提的问题 所属在 系统优化---架构优化中， 

另外你的问题是

如何影响性能

举个例子  上海世博会门岗 就是你的触发器， 每个客人是一个插入的表记录

如果1天30万人 那你的触发器就需要 被触动30万次， 另外还得考虑后面的工作，符合触发器怎么做

放人，没有票的人被禁止，这也需要触发器里面的SQL 语句去做。

小容量自然没有问题，一个小公园一天才10个人出入，一个人检票还有时间休息，所以数据库的架构设计

是一个数据库成败的关键。

以上纯属个人意见 


你面临的问题

1 触发器频繁操作，在大量数据涌入的情况下，会造成拥塞，数据库崩溃，这也就是良好设计的数据库很少用

   触发器的原因

2 触发器里面的SQL SCRIPT 如果设计不好，就更加重问题，所有没有解决的问题要放到缓存。


所以 

#8

学习 学习 。。

#9

引用 7 楼 liuhuayang 的回复:

引用楼主 lcw321321 的回复:
-------------来自前辈的建议
1，总体而言，触发器性能通常比较低。当运行触发器时，系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上，而删除表和插入表总是位于内存中。可见触发器所参照的其它表的位置决定了操作要花费的时间长短。

2，也有人说触发器的性能取决于,触发后执行脚本的内容.

3，另外微……

学习了

#10

该回复于2010-08-13 16:37:58被版主删除

#11

引用 7 楼 liuhuayang 的回复:

引用楼主 lcw321321 的回复:
-------------来自前辈的建议
1，总体而言，触发器性能通常比较低。当运行触发器时，系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上，而删除表和插入表总是位于内存中。可见触发器所参照的其它表的位置决定了操作要花费的时间长短。

2，也有人说触发器的性能取决于,触发后执行脚本的内容.

3，另外微……

对于世博的例子,如果每次都是一个小批量的录入话,应该验证票不存在问题,二,如果验证后就不再维护,如,只要你通过世博这个门了,以后就不会再去查这30万条记录,或者查的情况极少,那么世博门岗这个瓶颈也就不会出现了.
另外一个办法是,在世博外增加其它检查方式,就有如可以通过多个中间层在外围就检查了.而数据库触发器就只能在一个唯一数据库服务器上进行.

#12

引用 6 楼 feixianxxx 的回复:

"系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上"
这句话不够明白,望各位大牛解释下,哈哈

参照其他表是什么东东?为什么不在内存和数据库设备上呢?


=====>

有些表是读在内存里的 有些则存在硬盘上没读出来的 
触发器由于可能涉及到多表 所以自然要去读取这些表(这就是参考其他表)

明白了,但是如果参照的表很小,而且一直几乎都在内存中,也就不会出现性能瓶颈了

#13

说来说去,我觉得还是在讨论触发后执行的SQL脚本的性能问题.如果触发后执行的脚本性能高,那么是触发器本身就不存在性能问了.

#14

3，另外微软官方说:执行触发器会影响大容量导入操作的性能

--另一方面是它对别的事务影响，使得产生死锁的频率提高。

#15

引用 11 楼 lcw321321 的回复:

引用 7 楼 liuhuayang 的回复:
引用楼主 lcw321321 的回复:
-------------来自前辈的建议
1，总体而言，触发器性能通常比较低。当运行触发器时，系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上，而删除表和插入表总是位于内存中。可见触发器所参照的其它表的位置决定了操作要花费的时间长短。

2，也有人说触发器的性能……

Sorry 我可能没有讲清楚，这是我的问题， 小批量是没有问题，我举世博会的例子也是因为前些日子

有的检票口拥堵N多个人等待入场，而深有启发

如果这样那我就举一个实例好了

例如 你是一个在线商务网站

可能同时（可能在同一时间） 提交信息的人就有上千个，这个时候触发器就很显然不使用了，并发太多

是一定会对数据库操作产生性能上的问题，另外见过有的人利用触发器编写了大量的SQL 语句

想一次把问题解决，小批量运行的不错，但随着访问量变大性能是越来越低。

另外一方面，数据库存储到数据库后，也不见得不触动触发器，原因是不光是INSERT 触动

还有 Delete update 等等方面的问题，微软说的一点也没有错，小批量没有问题，可千万别

大量涌入数据库而且还在同一时间（设计数据库时当然要考虑）。

#16

3，另外微软官方说:执行触发器会影响大容量导入操作的性能
意思说,如果是小容量导入就不会影响性能了?



这是一个相对的概念，多少条记录能被称作是大容量或者小容量呢？这应该是结合你的服务器的环境来看的，服务器差的可能一、两万条就是大容量了，这样导入触发器肯定会影响性能的，但是对于一个很牛的服务器，这又只能算是小容量了，可能很容易处理。这个一、两万只是为举个例子而已。基本无参考价值。

#17

好,结贴,SQL 版新的牛人越来越多