数据库中Sql语句，存储过程，触发器对性能影响的理解

相比inline sql，很多人更喜欢使用存储过程，为何？很多人会说：“因为存储过程是预编译并且缓存了的，因此比原生sql会更快”

这句话某个时候是正确的，先解释一下依据：sql第一次执行的时候，发生了三件事情1.  Sql 语法错误检查2.  最好的执行计划来执行Sql（例如选择使用聚簇索引，或者非聚簇索引等）3.  执行Sql       上述流程也适合存储过程第一次执行，只不过存储过程的执行计划会被缓存到内存中，所以，当存储过程下次再被执行的时候，就会从缓存中直接取出缓存的计划执行，而不再执行上述1 、2 两步，因此性能得以提高；而原生内嵌sql（不知道咋翻译，反正就是你在app中定义的sql，new sqlcommand("select * from user" +......)）则必须重复上述三个动作。     但是，上述情况的适用范围随着sqlserver的发展而有所变化，上述情况只发生在老版本的Sqlserver上，从sqlserver2005之后，系统一视同仁，存储这个优势没了，都会被预编译和缓存。Sql语句：新版本Sqlserver中，在Sql查询参数不变的情况下，会使用原来的缓存，若查询参数发生改变，则会重新执行12步操作，创建新的缓存(例如：select* from table where id=1;select * from table where id=2;)；存储过程：我们知道，存储过程会进行预编译并使用原来的缓存，但是在新版本Sqlserver中，使用参数化的内嵌Sql也能达到预编译都会被预编译和缓存。但是，使用存储过程有几点好处：

1.抽象分离
代码不用再考虑诸如字段名、表名的东西了，将减少改数据库时对代码影响
2.安全
这或许是最好的理由了，你可以为存储过程分配可执行权限
3.维护方便
出了问题，直接在存储过程中解决，不必重新发布编译exe/dll了
4.集中调整
若有sql性能问题，可以由DBA单独隔离搞定
5.游标，临时表
如有复杂的诸如if else ，cursor等东西，还是存储过程用起来顺手方便

触发器：

在大量并发的情况下，使用触发器是很危险的事。在并发量大的系统中触发器很影响性能的. 如果非用不可,一定要注意SQL的质量. 对性
4000
能的影响大小跟SQL的质量关系很大.不能一概而论.触发器多不是好事:      

第一:一定会影响性能,若是数据量大时,每次都要触发上百上千触发器可想而知      

第二:基于维护方面,不谈有多少触发器,当每修改一次触发表相应触发器就失效,符出代价可想而知.           

不建议多用触发器,用函数与过程代替之.

参考文档：http://blog.csdn.net/kufeiyun/article/details/8654336