深刻了解存储过程的编写经验和优化措施

 在数据库的开发过程当中，常常会遇到复杂的业务逻辑和对数据库的操做，这个时候就会用SP来封装数据库操做。若是项目的SP较多，书写又没有必定的规范，将会影响之后的 系统 维护困难和大SP逻辑的难以理解，另外若是数据库的数据量大或者项目对SP的性能要求很，就会遇到优化的问题，不然速度有可能很慢，通过亲身经验，一个通过优化过的SP要比一个性能差的SP的效率甚至高几百倍。

　　一、开发人员若是用到其余库的Table或View，务必在当前库中创建View来实现跨库操做，最好不要直接使用“databse.dbo.table_name”，由于sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。

　　二、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，作过自身的查询优化检查。

　　三、高程序运行效率，优化应用程序，在SP编写过程当中应该注意如下几点：

　　SQL的使用规范

　　i. 尽可能避免大事务操做，慎用holdlock子句，提升系统并发能力。

　　ii. 尽可能避免反复访问同一张或几张表，尤为是数据量较大的表，能够考虑先根据条件提取数据到临时表中，而后再作链接。

　　iii.尽可能避免使用游标，由于游标的效率较差，若是游标操做的数据超过1万行，那么就应该改写；若是使用了游标，就要尽可能避免在游标循环中再进行表链接的操做。

　　iv. 注意where字句写法，必须考虑语句顺序，应该根据索引顺序、范围大小来肯定条件子句的先后顺序，尽量的让字段顺序与索引顺序相一致，范围从大到小。

　　v. 不要在where子句中的“=”左边进行函数、算术运算或其余表达式运算，不然系统将可能没法正确使用索引。

　　vi. 尽可能使用exists代替select count(1)来判断是否存在记录，count函数只有在统计表中全部行数时使用，并且count(1)比count(*)更有效率。

　　vii.尽可能使用“>=”，不要使用“>”。

　　viii.注意一些or子句和union子句之间的替换

　　ix.注意表之间链接的数据类型，避免不一样类型数据之间的链接。

　　x. 注意存储过程当中参数和数据类型的关系。

　　xi.注意insert、update操做的数据量，防止与其余应用冲突。若是数据量超过200个数据页面（400k），那么系统将会进行锁升级，页级锁会升级成表级锁。

　　索引的使用规范

　　i. 索引的建立要与应用结合考虑，建议大的OLTP表不要超过6个索引。

　　ii. 尽量的使用索引字段做为查询条件，尤为是聚簇索引，必要时能够经过index index_name来强制指定索引

　　iii.避免对大表查询时进行table scan，必要时考虑新建索引。

　　iv. 在使用索引字段做为条件时，若是该索引是联合索引，那么必须使用到该索引中的第一个字段做为条件时才能保证系统使用该索引，不然该索引将不会被使用。

　　v. 要注意索引的维护，周期性重建索引，从新编译存储过程。

　　tempdb的使用规范

　　i. 尽可能避免使用distinct、order by、group by、having、join、cumpute，由于这些语句会加剧tempdb的负担。

　　ii. 避免频繁建立和删除临时表，减小系统表资源的消耗。

　　iii.在新建临时表时，若是一次性插入数据量很大，那么可使用select into代替create table，避免log，提升速度；若是数据量不大，为了缓和系统表的资源，建议先create table，而后insert。

　　iv. 若是临时表的数据量较大，须要创建索引，那么应该将建立临时表和创建索引的过程放在单独一个子存储过程当中，这样才能保证系统可以很好的使用到该临时表的索引。

　　v. 若是使用到了临时表，在存储过程的最后务必将全部的临时表显式删除，先truncate table，而后drop table，这样能够避免 系统 表的较长时间锁定。

　　vi. 慎用大的临时表与其余大表的链接查询和修改，减低系统表负担，由于这种操做会在一条语句中屡次使用tempdb的系统表。

　　合理的算法使用

　　根据上面已提到的SQL优化技术和ASE Tuning手册中的SQL优化内容,结合实际应用,采用多种算法进行比较,以得到消耗资源最少、效率最高的方法。具体可用ASE调优命令：set statistics io on, set statistics time on , set showplan on 等。