数据库优化方案（五）

四、测试、试运行、维护阶段

测试的主要任务是发现并修改系统的问题，其中性能问题也是一个重要的方面。重点应该放在发现有性能问题的地方，并进行必要的优化。主要进行语句优化、索引优化等。

试运行和维护阶段是在实际的环境下运行系统，发现的问题范围更广，可能涉及操作系统、网络以及多用户并发环境出现的问题，其优化也扩展到操作系统、网络以及数据库物理存储的优化。

这个阶段的优花方法在这里不再展开，只说明下索引维护的方法：

A、 可以用DBCCDBREINDEX语句或者SQL SERVER维护计划设定定时进行索引重建，索引重建的目的是提高索引的效能。

B、 可以用语句UPDATESTATISTICS或者SQL SERVER维护计划设定定时进行索引统计信息的更新，其目的是使得统计信息更能反映实际情况，从而使得优化器选择更合适的索引。

C、 可以用DBCCCHECKDB或者DBCC CHECKTABLE语句检查数据库表和索引是否有问题，这两个语句也能修复一般的问题。

 

五、网上资料中一些说法的个人理解

1、应尽量避免在WHERE 子句中对字段进行 NULL 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

SELECT ID FROM T WHERE NUM IS NULL

可以在NUM上设置默认值0，确保表中NUM列没有NULL值，然后这样查询：

SELECT ID FROM T WHERE NUM= 0

个人意见：经过测试，ISNULL也是可以用INDEX SEEK查找的，0和NULL是不同概念的，以上说法的两个查询的意义和记录数是不同的。

 

2、应尽量避免在WHERE 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

个人意见：经过测试，<>也是可以用INDEXSEEK查找的。

 

3、应尽量避免在WHERE 子句中使用 OR 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：

SELECT ID FROM T WHER ENUM=10OR NUM=20

可以这样查询：

SELECTID FROM T WHERE NUM=10

UNION ALL

SELECT ID FROM T WHERE NUM=20

个人意见：主要对全表扫描的说法不赞同。

 

4、IN 和 NOT IN 也要慎用，否则会导致全表扫描，如：

SELECT ID FROM T WHERE NUM IN(1,2,3)

对于连续的数值，能用 BETWEEN 就不要用 IN 了：

SELECT ID FROM T WHERE NUMBETWEEN 1 AND 3

 

5、 如果在WHERE 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：

SELECTID FROM T WHERE NUM=@NUM

可以改为强制查询使用索引：

SELECTID FROM T WITH(INDEX(索引名))WHERE NUM=@NUM

个人意见：关于局部变量的解释比较奇怪，使用参数如果会影响性能，那存储过程就该移除了，我坚持我上面对于强制索引的看法。

 

6、 尽可能的使用VARCHAR/NVARCHAR 代替 CHAR/NCHAR ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。

个人意见：“在一个相对较小的字段内搜索效率显然要高些”显然是对的，但是字段的长短似乎不是由变不变长决定，而是业务本身决定。在SQLSERVER6.5或者之前版本，不定长字符串字段的比较速度比定长的字符串字段的比较速度慢很多，所以对于那些版本，我们都是推荐使用定长字段存储一些关键字段。而在2000版本，修改了不定长字符串字段的比较方法，与定长字段的比较速度差别不大了，这样为了方便，我们大量使用不定长字段。

 

7、关于连接表的顺序或者条件的顺序的说法，经过测试，在SQLSERVER，这些顺序都是不影响性能的，这些说法可能是对ORACLE有效。