深入sql语句性能调整

《深入sql语句性能调整》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、深入SQL语句性能调整（一）　　1、数据库设计与规划　　•PrimaryKey字段的长度尽量小，能用smallinteger就不要用integer。例如员工数据表，若能用员工编号当主键，就不要用身分证号码。　　•一般字段亦同。若该数据表要存放的数据不会超过3万笔，用smallinteger即可，不必用integer。　　•文字数据字段若长度固定，如：身分证号码，就不要用varchar或nvarchar，应该用char或nchar。　　•文字数据字段若长度不固定，如：地址，则该用varchar或nvarchar。除了可节省存储空间外，存取硬盘时也会较有效率。　　•设计字段时

2、，若其值可有可无，最好也给一个默认值，并设成「不允许NULL」(一般字段默认为「允许NULL」)。因为SQLServer在存放和查询有NULL的数据表时，会花费额外的运算动作[2]。　　•若一个数据表的字段过多，应垂直切割成两个以上的数据表，并可用同名的PrimaryKey一对多连结起来，如：Northwind的Orders、OrderDetails数据表。以避免在存取数据时，以「集簇索引(clusteredindex)」扫描时会加载过多的数据，或修改数据时造成互相锁定或锁定过久。　　2、适当地建立索引　　•记得自行帮ForeignKey字段建立索引，即使是很少被JOIN

3、的数据表亦然。　　•替常被查询或排序的字段建立索引，如：常被当作WHERE子句条件的字段。　　•用来建立索引的字段，长度不宜过长，不要用超过20个Byte的字段，如：地址。　　•不要替内容重复性高的字段建立索引，如：性别;反之，若重复性低的字段则适合建立索引，如：姓名。　　•不要替使用率低的字段建立索引，以免浪费硬盘空间。　　•不宜替过多字段建立索引，否则反而会影响到「INSERT、UPDATE、DELETE」的性能，尤其是以「OLTP(联机事务处理;在线交易)」为主的网站数据库。　　•若数据表存放的数据很少，就不必刻意建立索引。否则可能数据库沿着存放索引的「树状结构」(

4、BalancedTree)去搜寻索引中的数据，反而比扫描整个数据表还慢。　　•若查询时符合条件的数据很多，则透过「非集簇索引(non-clusteredindex)」搜寻的性能，反而可能不如整个数据表逐笔扫描。　　•建立「集簇索引」的字段选择至为重要，会影响到整个索引结构的性能。要用来建立「集簇索引」的字段，务必选择「整数」类型(键值会较小)、唯一、不可为NULL。　　3、适当地使用索引　　•有些书籍会提到，使用「LIKE、%」做模糊查询时，即使您已替某个字段建立索引(如下方代码的CustomerID字段)，但以常量字符开头才会使用到索引，若以万用字符(%)开头则不会使用

5、索引，如下所示：　　USENorthwind;　　GO　　SELECT*FROMOrdersWHERECustomerIDLIKE'D%';--使用索引　　SELECT*FROMOrdersWHERECustomerIDLIKE'%D';--不使用索引　　　　在SQLServer2005执行完成后按Ctrl+L，可检阅如下图的「执行计划」。　　　　图1　　　可看出「查询最佳化程序」有使用到索引做搜寻　　　　图2　　　在此的「集簇索引」扫描，并未直接使用索引，性能上几乎只等于扫描整个数据表　　但经反复测试，这种语法是否会使用到索引，抑或会逐笔扫描，并非绝对的。仍要看所下的查

6、询关键词，以及字段内所存储的数据内容而定。但对于存储数据笔数庞大的数据表，最好还是少用LIKE做模糊查询。　　•以下的运算符会造成「负向查询」，常会让「查询最佳化程序」无法有效地使用索引，最好能用其它运算符和语法改写(经版工测试，并非有负向运算符，就绝对无法使用索引)：　NOT、!=、<>、!>、!<、NOTEXISTS、NOTIN、NOTLIKE　　•避免让WHERE子句中的字段，去做字符串的串接或数字运算，否则可能导致「查询最佳化程序」无法直接使用索引，而改采「集簇索引扫描」(经版工测试并非绝对)。　　•数据表中的数据，会依照「集簇索引」字段的顺序存放，因此当您下BE

7、TWEEN、GROUPBY、ORDERBY时若有包含「集簇索引」字段，由于数据已在数据表中排序好，因此可提升查询速度。　　•若使用「复合索引」，要注意索引顺序上的第一个字段，才适合当作过滤条件。深入SQL语句性能调整（二）2008年12月30日星期二下午04:454、避免在WHERE子句中对字段使用函数　　对字段使用函数，也等于对字段做运算或串接的动作，一样可能会让「查询最佳化程序」无法有效地使用索引。但真正对性能影响最重大的，是当您的数据表内若有10万笔数据，则在查询时就需要呼叫函数10万次，这点才是真正的性能杀手。程序员应