-------------来自前辈的建议
1，总体而言，触发器性能通常比较低。当运行触发器时，系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上，而删除表和插入表总是位于内存中。可见触发器所参照的其它表的位置决定了操作要花费的时间长短。2，也有人说触发器的性能取决于,触发后执行脚本的内容.3，另外微软官方说:执行触发器会影响大容量导入操作的性能
意思说,如果是小容量导入就不会影响性能了?难道以上都对吗?另外"系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上"
这句话不够明白,望各位大牛解释下,哈哈
参照其他表是什么东东?为什么不在内存和数据库设备上呢?
性能的影响是指什么呢?CPU?内存?磁盘IO?现在有一个DDL触发器,想把DDL触发的内容都放在一个表中.而表又有一个DML触发的动作,来判断如果满足的就插入到另外一个表中
类似一个联级触发的过程.
另外一种实现方式呢,一开始就是在DDL触发中就按规则写好,如果满足条件的话就同时插入.
但是这样是否会影响到DDL的动作,比如重建索引的时候会有大量的记录录入,这个时候是否就没上面那种可以分担负载了?
1，总体而言，触发器性能通常比较低。当运行触发器时，系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上，而删除表和插入表总是位于内存中。可见触发器所参照的其它表的位置决定了操作要花费的时间长短。2，也有人说触发器的性能取决于,触发后执行脚本的内容.3，另外微软官方说:执行触发器会影响大容量导入操作的性能
意思说,如果是小容量导入就不会影响性能了?难道以上都对吗?另外"系统处理的大部分时间花费在参照其它表的这一处理上，因为这些表既不在内存中也不在数据库设备上"
这句话不够明白,望各位大牛解释下,哈哈
参照其他表是什么东东?为什么不在内存和数据库设备上呢?
性能的影响是指什么呢?CPU?内存?磁盘IO?现在有一个DDL触发器,想把DDL触发的内容都放在一个表中.而表又有一个DML触发的动作,来判断如果满足的就插入到另外一个表中
类似一个联级触发的过程.
另外一种实现方式呢,一开始就是在DDL触发中就按规则写好,如果满足条件的话就同时插入.
但是这样是否会影响到DDL的动作,比如重建索引的时候会有大量的记录录入,这个时候是否就没上面那种可以分担负载了?
首先解释一下性能性能就牵扯到性能优化优化分两个方面1 硬件优化2 系统或软件优化 （包括SQL SERVER 语句，表结构，索引，架构）你所提的问题 所属在 系统优化---架构优化中， 另外你的问题是如何影响性能举个例子 上海世博会门岗 就是你的触发器， 每个客人是一个插入的表记录如果1天30万人 那你的触发器就需要 被触动30万次， 另外还得考虑后面的工作，符合触发器怎么做放人，没有票的人被禁止，这也需要触发器里面的SQL 语句去做。小容量自然没有问题，一个小公园一天才10个人出入，一个人检票还有时间休息，所以数据库的架构设计是一个数据库成败的关键。以上纯属个人意见
你面临的问题1 触发器频繁操作，在大量数据涌入的情况下，会造成拥塞，数据库崩溃，这也就是良好设计的数据库很少用 触发器的原因2 触发器里面的SQL SCRIPT 如果设计不好，就更加重问题，所有没有解决的问题要放到缓存。
所以
Sorry 我可能没有讲清楚，这是我的问题， 小批量是没有问题，我举世博会的例子也是因为前些日子有的检票口拥堵N多个人等待入场，而深有启发如果这样那我就举一个实例好了例如 你是一个在线商务网站可能同时（可能在同一时间） 提交信息的人就有上千个，这个时候触发器就很显然不使用了，并发太多是一定会对数据库操作产生性能上的问题，另外见过有的人利用触发器编写了大量的SQL 语句想一次把问题解决，小批量运行的不错，但随着访问量变大性能是越来越低。另外一方面，数据库存储到数据库后，也不见得不触动触发器，原因是不光是INSERT 触动还有 Delete update 等等方面的问题，微软说的一点也没有错，小批量没有问题，可千万别大量涌入数据库而且还在同一时间（设计数据库时当然要考虑）。