索引的维护以及建议:

1.         数据变化顺便最好和聚集索引的顺序相一致。如果不一致,SQL 都需要调整表中的记录存储顺序,这会大大降低数据存储的效率。EX:对于论坛的数据,数据插入的顺序是按时间,如果将数据放在用户ID上,则每次为了把用户ID的数据组织在一起,SQL 都要调整相关位置,效率会非常的低下。建立在时间上效果会比较好
2.         列宽要尽可能短,聚集索引的列宽越大,意味着普通索引需要的空间就越多。空间越大,一方面意味着存储空间的浪费,另一方面SQLSERVER在处理数据时,从所周知是以8K的数据页为单位,每页可容纳的数据越小,扫描数据读取所需要读取的页就越多。性能自然是越低
3.         尽量选择唯一和列值不可为空的列。唯一和列值不为空可以做到准确定位
4.         在计算列上建立索引可以加快速度,但是过多的索引势必会大大降低数据变化操作的新能,因此,索引的数据不应该无限制的建立。索引需要一些维护,以保证其性能。
5.         索引的应用上主要考虑是看WHERE的列上是否能用到覆盖索引,如果不是顺序使用索引的中列,是无法使用覆盖索引的。
6.         查看索引的碎片,可用sys.dm_db_index_physical_stats 动态管理函数,其中avg_fragmentation_in_percent 大于5%~30% 之间用REORGANIZE来整理索引,大于30%则用REBUILD来解决索引问题。fragment_count  索引中碎片的数量(物理上连续的叶)
avg_fragment_size_in_pages 索引中一个碎片的平均数量,具体自己看联机帮助吧。具体整理脚本需要可以问我~
7.         索引视图适用于很少更新基础数据,如果经常更新基础数据,维护视图数据的成本可能超过使用索引视图所带来的性能收益,自己考虑下成本问题。
8.         不要盲目建立索引
SQL语句都没确定的情况下,盲目建立任何索引。一般不建议建立没有主键或者聚集索引的表。
 

T-SQL 编写规范及个人建议

1.         注意代码格式
具有良好的TSQL代码,体现个人的风格,使用空格作为缩进,则不能再使用TAB做缩进处理。对于关键字,系统变量名和系统函数等,建议用大写,以增加可读性。
2.         使用两部分对象名称
在引用对象时,建立显示指定对象架构(一般都为DBO)如果引用对象未指定架构,一方面会对性能有所影响,另一方面,对象名相同时,也有可能调用了不希望饮用的对象。
3.         避免语句中含有SELECT *
SELECT * 容易导致潜存的错误产生。如果某个应用程序依赖于某个列,在使用了SELECT *的情况下,当调整了基础表的列顺序以后,某个应用程序就会执行失败。更严重的问题则为列的兼容问题
4.         明确引用对象来自哪个对象
如果有一个T-SQL语句涉及多张表,则引用的大对象应该指定该列所属的对象,一方面有利于以后的修改分析,另一方面,则可以减少潜在的错误发生。当表TA和TB都有ID这个列时,原本正确的查询会发生错误,因为没有明确指定ID属于哪个列。
5.         在 INSERT语句中,应明确列的列表 INSERT()SELECT * FROM *****
6.         善用NOLOCK
在非事务和特别的完整性要求的上下文中,建议始终使用锁提示NOLOCK。比如我们的老刘要查询本月的当前销售情况,由于销售是不段进行的,所有没有必要保证查询时所包含的数据是否一定是已经提交了事务了的。
7.         保证事务语句的配对
如果事务语句不配对,容易造成事务的阻塞,从而引起死锁。
8.         为调试的语句加上特别的注释
为了调试的需要,会在SP中编写一些输出信息的语句,在正式发布时,应该取消。
9.         注意条件中的类型转换
对于类型不相同的两个数据进行逻辑处理(比较和赋值时),建议显示使用数据的类型转换(CAST,CONVERT )并注意转换是否会存在的问题。
10.     处理NULL值,建议使用ISNULL函数代替CASE WHEN,缩短代码和增加可读性。
11.     用外键代替TRIGGER来实现数据的引用完整性。
外键约束是SQL 内部实现的,已经是内置的二进制处理代码,比起需要经过编译才能使用的TRIGGER或者用户定义代码而言,有最高的效率。
12.     正确使用表变量和临时表
两者都能换存中间数据,表变量上不能建立索引,因此不适合处理大量数据。
13.     使用结构化的错误处理
SQL 2005 增加了TRY。。CATCH语句来实现结构的处理,用来代替2000@@ERROR+IF+GOTO的处理方式。