SQLServer数据库性能优化..doc

SQL Server数据库性能优化 设计阶段 主键的设计 主键是必要的，SQL SERVER的主键同时是一个唯一索引，而且在实际应用中，我们往往选择最小的键组合作为主键，所以主键往往适合作为表的聚集索引。 在有多个键的表，一般选择总的长度小的键作为主键，小的键的比较速度快，同时小的键可以使主键的B树结构的层次更少。 对于组合主键来说，不同的字段次序的主键的性能差别可能会很大，一般应该选择重复率低、单独或者组合查询可能性大的字段放在前面。 字段的设计 字段是数据库最基本的单位，其设计对性能的影响是很大的。需要注意如下： A、 B、 C、NULL，除非必要。可以用NOT NULL+DEFAULT代替。 D、TEXT和IMAGE，二进制字段的读写是比较慢的，而且，读取的方法也不多，大部分情况下最好不用。 E、 索引的设计 关于索引的选择，应改主意： A、 B、在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。??在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。在条件表达式中经常用到的不同值较多的列上建立检索，C、在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度、 E、 编码阶段 查询慢的原因 没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷) I/O吞吐量小，形成了瓶颈效应。 没有创建计算列导致查询不优化。 内存不足 网络速度慢 查询出的数据量过大（可以采用多次查询，其他的方法降低数据量） 锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷) sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 返回了不必要的行和列 查询语句不好，没有优化NOT IN操作符是强推荐不使用的，因为它不能应用表的索引。推荐方案：用NOT EXISTS 或（外连接+判断为空）方案代替IS NULL, , !=, !, !, NOT, NOT EXISTS, NOT IN, NOT LIKE, LIKE %500，因为他们不走索引全是表扫描。 注意UNion和UNion all的区别。UNION比union all多做了一步distinct操作。能用union all的情况下尽量不用union。 查询时尽量不要返回不需要的行、列。另外在多表连接查询时，尽量改成连接查询，少用子查询。 尽量少用视图，它的效率低。对视图操作比直接对表操作慢,可以用存储过程来代替它。特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。对单个表检索数据时，不要使用指向多个表的视图，没有必要时不要用DISTINCT和ORDER BY，这些动作可以改在客户端执行它们增加了额外的开销。这同UNION和UNION ALL一样的道理。 使用in时，在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，这样可以减少判断的次数 一次更新多条记录比分多次更新每次一条快,就是说批处理好 尽量将数据的处理工作放在服务器上，减少网络的开销，如使用存储过程。存储过程是编译好、优化过，并且被组织到一个执行规划里、且存储在数据库中的 SQL语句，是控制流语言的集合，速度当然快。 不要在一段SQL或者存储过程中多次使用相同的函数或相同的查询语句，这样比较浪费资源,建议将结果放在变量里再调用。这样更快。 返回数据到客户端至少需要数据库提取数据、网络传输数据、客户端接收数据以及客户端处理数据等环节，如果返回不需要的数据，就会增加服务器、网络和客户端的无效劳动，其害处是显而易见的，避免这类事件需要注意： A、SELECT *的语句，而是明确选择好你需要的字段。 B、WHERE子句，尽量不要写没有WHERE的SQL语句。 C、SELECT INTO后的WHERE子句，因为SELECT INTO把数据插入到临时表，该过程会锁定一些系统表，如果这个WHERE子句返回的数据过多或者速度太慢，会造成系统表长期锁定、诸塞其他进程。 D、HAVING子句进一步限定返回的行。 尽量少做重复的工作 这一点和上一点的目的是一样的，就是尽量减少无效工作，但是这一点的侧重点在客户端程序，需要注意的如下： A、? B、 C、 D、UPDATE，比如 UPDATE?EMPLOYEE?SET?FNAME=’HAI’?WHERE?EMP_ID=’VPA’ UPDATE?EMPLOYEE?SET?LNAME=’YAN’?WHERE?EMP_ID=’VPA’ 这两个语句应该合并成以下一个语句 UPDATE?EMPLOY