还是将一个大的触发器分成相对小点的多个触发器的效率高呢?
因为我要用触发器做数据的运算,所以对效率问题比较关注
14 个解决方案
#1
触发器可以理解为系统函数调用api一类的东西
肯定是越少越好了。
ps,如果是复杂运算，建议在业务逻辑里面做。在触发器里面的话，很容易把自己都搞晕，久了就找不到了。
肯定是越少越好了。
ps,如果是复杂运算，建议在业务逻辑里面做。在触发器里面的话，很容易把自己都搞晕，久了就找不到了。
#2
另外还有个问题,表上的多个触发器是同时一次触发动作呢?
还是顺序触发,一个触发器完成了再触发下一个触发器呢?
还是顺序触发,一个触发器完成了再触发下一个触发器呢?
#3
如果同种触发器超过2个的话，只能定义第一个和最后一个触发器的调用顺序，其他触发器什么时候调用，完全由SQL说了算。也就是说，随机。。。。
#4
to iamltd(妖)
谢谢,我的业务逻辑基本上都是由SQL的触发器完成的啊,因为数据在
不断改变,改变的同时要计算出下个逻辑需要的数据,根据你上面所说
的话,我一个表只能放2个触发器了,因为我的数据要即时的,其他触发
器什么时候调用，完全由SQL说了算。也就是说，随机是不能满足我的
要求的.
谢谢,我的业务逻辑基本上都是由SQL的触发器完成的啊,因为数据在
不断改变,改变的同时要计算出下个逻辑需要的数据,根据你上面所说
的话,我一个表只能放2个触发器了,因为我的数据要即时的,其他触发
器什么时候调用，完全由SQL说了算。也就是说，随机是不能满足我的
要求的.
#5
如 iamltd(妖) 所說，觸發器實際上就是一個SQL 觸發事件，然後由用戶定義的函數，所以它在執行上來說與函數調用機質非常類似，隻不過是由事件觸發而已，所以，如果把所有的事情都寫在同一個觸發器中是不明智的，因為有些程序此次事件觸發並不需要執行，但是被你寫在同一函數中了，它還是會被調出來進行編譯(雖然不一定執行)，如果分開寫的話就不會有這個問題了。
觸發器的調用在默認上是會按注冊的先後順序執行的，除非你為它設定了執行的先後順序，(但是這種先後順序好象不是串行的，所以相互之間傳值我試過幾次都失敗)。
觸發器的調用在默認上是會按注冊的先後順序執行的，除非你為它設定了執行的先後順序，(但是這種先後順序好象不是串行的，所以相互之間傳值我試過幾次都失敗)。
#6
真有那么复杂的逻辑，需要N多个触发器？
我写过八百行的触发器，几百个用户读写表，表里现在已经有一千多万行的记录，也不没见什么效率问题啊
我写过八百行的触发器，几百个用户读写表，表里现在已经有一千多万行的记录，也不没见什么效率问题啊
#7
我的触发器已经写了有3000行了,在数据不多时(一万左右)我用SQL2005
执行没有什么问题,可是数据量一大(20万左右),以前30秒的过程现在要
2分钟左右,并且数据量还在不断增加中
执行没有什么问题,可是数据量一大(20万左右),以前30秒的过程现在要
2分钟左右,并且数据量还在不断增加中
#8
1、多个触发器的好处在哪里？个人真的找不出来，唯一的可能是一个触发器的字节数超出限制的情况。
2、效率方面，个人认为，一个高于多个，因为你的业务需要，每个触发器都必须执行，SQL SERVER也不允许你选择执行某（几）个触发器，但是触发器相当于存储过程，其调用需要花费资源，调用多个在这方面的花费会大些。
3、可以指定最后和最先，再加上中间一个不指定的，所以可控次序的最多触发器是3个，不是两个。
2、效率方面，个人认为，一个高于多个，因为你的业务需要，每个触发器都必须执行，SQL SERVER也不允许你选择执行某（几）个触发器，但是触发器相当于存储过程，其调用需要花费资源，调用多个在这方面的花费会大些。
3、可以指定最后和最先，再加上中间一个不指定的，所以可控次序的最多触发器是3个，不是两个。
#9
触发器效率是很重要的，但是效率和触发器个数的联系并不大，和相关表的数据量、索引情况才是最主要的
#10
to Haiwer(海阔天空)
谢谢,讲的相当详细和客观.
我触发器中包含了我的业务逻辑,但中间有3/2都是选者(IF..ELSE..)之类的,3000多行实际要执行的也就只有1000多行,其他不符合条件的都不执行了,这样做是提高了效率呢,还是降低了效率啊,因为我想,触发器也有个编译过程,我写的代码多了,编译的时间就要长了,相当于效率减低了,会不会出现这样的问题呢?
谢谢,讲的相当详细和客观.
我触发器中包含了我的业务逻辑,但中间有3/2都是选者(IF..ELSE..)之类的,3000多行实际要执行的也就只有1000多行,其他不符合条件的都不执行了,这样做是提高了效率呢,还是降低了效率啊,因为我想,触发器也有个编译过程,我写的代码多了,编译的时间就要长了,相当于效率减低了,会不会出现这样的问题呢?
#11
3000 lines? OMG!
我想你应做的是整理逻辑或重新设计表结构，20万行记录属于小表，30秒已经太夸张了，何况两分钟！执行一个触发器超过5秒我都觉得难以接受了。
何况3000行的代码，维护起来实在要命。其实在触发器中是可以用函数的，如果你某些代码只是要得到值的话。当然，影响速度的是SQL语句的写法，有没有用到索引是决定因素。
我想你应做的是整理逻辑或重新设计表结构，20万行记录属于小表，30秒已经太夸张了，何况两分钟！执行一个触发器超过5秒我都觉得难以接受了。
何况3000行的代码，维护起来实在要命。其实在触发器中是可以用函数的，如果你某些代码只是要得到值的话。当然，影响速度的是SQL语句的写法，有没有用到索引是决定因素。
#12
to edp08()
代码有3000行,可是实际执行的部分就只有3/1左右,因为有大量的选择语句,
这个是影响效率的因素吗?
代码有3000行,可是实际执行的部分就只有3/1左右,因为有大量的选择语句,
这个是影响效率的因素吗?
#13
if else不怎么影响效率的，主要是SQL语句的执行最慢。
仔细检查一下代码吧。
3000行的代码确实太恐怖了点，呵呵
仔细检查一下代码吧。
3000行的代码确实太恐怖了点，呵呵
#14
同意楼上，if else不影响效率
至于编译时间，个人认为影响也很小，而且sql server的触发器有预编译，一般常用的触发器都是编译好放在内存的。如果你的系统有不少的触发器，用
dbcc MEMUSAGE
可以看到内存的前几个存储过程都是触发器
至于编译时间，个人认为影响也很小，而且sql server的触发器有预编译，一般常用的触发器都是编译好放在内存的。如果你的系统有不少的触发器，用
dbcc MEMUSAGE
可以看到内存的前几个存储过程都是触发器
#1
触发器可以理解为系统函数调用api一类的东西
肯定是越少越好了。
ps,如果是复杂运算，建议在业务逻辑里面做。在触发器里面的话，很容易把自己都搞晕，久了就找不到了。
肯定是越少越好了。
ps,如果是复杂运算，建议在业务逻辑里面做。在触发器里面的话，很容易把自己都搞晕，久了就找不到了。
#2
另外还有个问题,表上的多个触发器是同时一次触发动作呢?
还是顺序触发,一个触发器完成了再触发下一个触发器呢?
还是顺序触发,一个触发器完成了再触发下一个触发器呢?
#3
如果同种触发器超过2个的话，只能定义第一个和最后一个触发器的调用顺序，其他触发器什么时候调用，完全由SQL说了算。也就是说，随机。。。。
#4
to iamltd(妖)
谢谢,我的业务逻辑基本上都是由SQL的触发器完成的啊,因为数据在
不断改变,改变的同时要计算出下个逻辑需要的数据,根据你上面所说
的话,我一个表只能放2个触发器了,因为我的数据要即时的,其他触发
器什么时候调用，完全由SQL说了算。也就是说，随机是不能满足我的
要求的.
谢谢,我的业务逻辑基本上都是由SQL的触发器完成的啊,因为数据在
不断改变,改变的同时要计算出下个逻辑需要的数据,根据你上面所说
的话,我一个表只能放2个触发器了,因为我的数据要即时的,其他触发
器什么时候调用，完全由SQL说了算。也就是说，随机是不能满足我的
要求的.
#5
如 iamltd(妖) 所說，觸發器實際上就是一個SQL 觸發事件，然後由用戶定義的函數，所以它在執行上來說與函數調用機質非常類似，隻不過是由事件觸發而已，所以，如果把所有的事情都寫在同一個觸發器中是不明智的，因為有些程序此次事件觸發並不需要執行，但是被你寫在同一函數中了，它還是會被調出來進行編譯(雖然不一定執行)，如果分開寫的話就不會有這個問題了。
觸發器的調用在默認上是會按注冊的先後順序執行的，除非你為它設定了執行的先後順序，(但是這種先後順序好象不是串行的，所以相互之間傳值我試過幾次都失敗)。
觸發器的調用在默認上是會按注冊的先後順序執行的，除非你為它設定了執行的先後順序，(但是這種先後順序好象不是串行的，所以相互之間傳值我試過幾次都失敗)。
#6
真有那么复杂的逻辑，需要N多个触发器？
我写过八百行的触发器，几百个用户读写表，表里现在已经有一千多万行的记录，也不没见什么效率问题啊
我写过八百行的触发器，几百个用户读写表，表里现在已经有一千多万行的记录，也不没见什么效率问题啊
#7
我的触发器已经写了有3000行了,在数据不多时(一万左右)我用SQL2005
执行没有什么问题,可是数据量一大(20万左右),以前30秒的过程现在要
2分钟左右,并且数据量还在不断增加中
执行没有什么问题,可是数据量一大(20万左右),以前30秒的过程现在要
2分钟左右,并且数据量还在不断增加中
#8
1、多个触发器的好处在哪里？个人真的找不出来，唯一的可能是一个触发器的字节数超出限制的情况。
2、效率方面，个人认为，一个高于多个，因为你的业务需要，每个触发器都必须执行，SQL SERVER也不允许你选择执行某（几）个触发器，但是触发器相当于存储过程，其调用需要花费资源，调用多个在这方面的花费会大些。
3、可以指定最后和最先，再加上中间一个不指定的，所以可控次序的最多触发器是3个，不是两个。
2、效率方面，个人认为，一个高于多个，因为你的业务需要，每个触发器都必须执行，SQL SERVER也不允许你选择执行某（几）个触发器，但是触发器相当于存储过程，其调用需要花费资源，调用多个在这方面的花费会大些。
3、可以指定最后和最先，再加上中间一个不指定的，所以可控次序的最多触发器是3个，不是两个。
#9
触发器效率是很重要的，但是效率和触发器个数的联系并不大，和相关表的数据量、索引情况才是最主要的
#10
to Haiwer(海阔天空)
谢谢,讲的相当详细和客观.
我触发器中包含了我的业务逻辑,但中间有3/2都是选者(IF..ELSE..)之类的,3000多行实际要执行的也就只有1000多行,其他不符合条件的都不执行了,这样做是提高了效率呢,还是降低了效率啊,因为我想,触发器也有个编译过程,我写的代码多了,编译的时间就要长了,相当于效率减低了,会不会出现这样的问题呢?
谢谢,讲的相当详细和客观.
我触发器中包含了我的业务逻辑,但中间有3/2都是选者(IF..ELSE..)之类的,3000多行实际要执行的也就只有1000多行,其他不符合条件的都不执行了,这样做是提高了效率呢,还是降低了效率啊,因为我想,触发器也有个编译过程,我写的代码多了,编译的时间就要长了,相当于效率减低了,会不会出现这样的问题呢?
#11
3000 lines? OMG!
我想你应做的是整理逻辑或重新设计表结构，20万行记录属于小表，30秒已经太夸张了，何况两分钟！执行一个触发器超过5秒我都觉得难以接受了。
何况3000行的代码，维护起来实在要命。其实在触发器中是可以用函数的，如果你某些代码只是要得到值的话。当然，影响速度的是SQL语句的写法，有没有用到索引是决定因素。
我想你应做的是整理逻辑或重新设计表结构，20万行记录属于小表，30秒已经太夸张了，何况两分钟！执行一个触发器超过5秒我都觉得难以接受了。
何况3000行的代码，维护起来实在要命。其实在触发器中是可以用函数的，如果你某些代码只是要得到值的话。当然，影响速度的是SQL语句的写法，有没有用到索引是决定因素。
#12
to edp08()
代码有3000行,可是实际执行的部分就只有3/1左右,因为有大量的选择语句,
这个是影响效率的因素吗?
代码有3000行,可是实际执行的部分就只有3/1左右,因为有大量的选择语句,
这个是影响效率的因素吗?
#13
if else不怎么影响效率的，主要是SQL语句的执行最慢。
仔细检查一下代码吧。
3000行的代码确实太恐怖了点，呵呵
仔细检查一下代码吧。
3000行的代码确实太恐怖了点，呵呵
#14
同意楼上，if else不影响效率
至于编译时间，个人认为影响也很小，而且sql server的触发器有预编译，一般常用的触发器都是编译好放在内存的。如果你的系统有不少的触发器，用
dbcc MEMUSAGE
可以看到内存的前几个存储过程都是触发器
至于编译时间，个人认为影响也很小，而且sql server的触发器有预编译，一般常用的触发器都是编译好放在内存的。如果你的系统有不少的触发器，用
dbcc MEMUSAGE
可以看到内存的前几个存储过程都是触发器