在数据库的开发过程中，
时常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作 。假如项
目标SP较多，书写又没有
定然的
标准，将会影响以后的系统
保护
困苦和大SP逻辑的难以
了解，另外假如数据库的数据量大或者
名目对SP的性能要求很，就会遇到优化的问题，不然速度有可能很慢，
通过
亲自
教训，一个
通过优化过的SP要比一个性能差的SP的效率甚至高几百倍 。
详尽内容：
1、开发人员假如用到
其余库的Table或View，务必在目前库中
构建View来实现跨库操作，最好不要直接
使用“databse.dbo.table_name”，由于sp_depends不能显示出该SP所
使用的跨库table或view，不容易校验 。
2、开发人员在提交SP前，必须已经
使用set showplan on
综合过
查问
方案，做过
本身的
查问优化
审查 。
3、高程序运行效率，优化
利用程序，在SP编写过程中应该
留神以下几点：
(a)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)，那么系统将会进行锁
晋级，页级锁会
晋级成表级锁 。
(b)索引的
使用
标准：
i. 索引的
缔造要与
利用
联合考量，
提议大的OLTP表不要超过6个索引 。
ii. 尽可能的
使用索引字段作为
查问条件，尤其是聚簇索引，必要时
可以通过index index_name来强制指定索引
iii. 幸免对大表
查问时进行table scan，必要时考量新建索引 。
iv. 在
使用索引字段作为条件时，假如该索引是联合索引，那么必须
使用到该索引中的第一个字段作为条件时
威力
保障系统
使用该索引，不然该索引将不会被
使用 。
v. 要
留神索引的
保护，周期性重建索引，再一次编译存储过程 。
(c)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的系统表 。
(d)
正当的算法
使用：
依据上面已提到的SQL优化技术和ASE Tuning手册中的SQL优化内容,
联合实际
利用,采纳多种算法进行
比较,以
获得
消费资源
起码、效率最高的
步骤 。具体可用ASE调优命令：set statistics io on, set statistics time on , set showplan on 等 。
