B、可以用语句UPDATE STATISTICS或者SQL SERVER维护计划设定定时进行索引统计信息的更新，其目的是使得统计信息更能反映实际情况，从而使得优化器选择更合适的索引。
C、可以用DBCC CHECKDB或者DBCC CHECKTABLE语句检查数据库表和索引是否有问题，这两个语句也能修复一般的问题。
五、网上资料中一些说法的个人不同意见
1、“应尽量避免在 WHERE 子句中对字段进行 NULL 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
| SELECT ID FROM T WHERE NUM IS NULL |
可以在NUM上设置默认值0，确保表中NUM列没有NULL值，然后这样查询：
| SELECT ID FROM T WHERE NUM=0” |
个人意见：经过测试，IS NULL也是可以用INDEX SEEK查找的，0和NULL是不同概念的，以上说法的两个查询的意义和记录数是不同的。
2、“应尽量避免在 WHERE 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。”
个人意见：经过测试，<>也是可以用INDEX SEEK查找的。
3、“应尽量避免在 WHERE 子句中使用 OR 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
| SELECT ID FROM T WHERE NUM=10 OR NUM=20 |
可以这样查询：
|
|
个人意见：主要对全表扫描的说法不赞同。
4、“IN 和 NOT IN 也要慎用，否则会导致全表扫描，如：
| SELECT ID FROM T WHERE NUM IN(1,2,3) |
对于连续的数值，能用 BETWEEN 就不要用 IN 了：
| SELECT ID FROM T WHERE NUM BETWEEN 1 AND 3” |
个人意见：主要对全表扫描的说法不赞同。
5、“如果在 WHERE 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然 而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
| SELECT ID FROM T WHERE NUM=@NUM |
可以改为强制查询使用索引：
| SELECT ID FROM T WITH(INDEX(索引名)) WHERE NUM=@NUM” |
个人意见：关于局部变量的解释比较奇怪，使用参数如果会影响性能，那存储过程就该校除了，我坚持我上面对于强制索引的看法。
6、“尽可能的使用 VARCHAR/NVARCHAR 代替 CHAR/NCHAR ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。”
个人意见：“在一个相对较小的字段内搜索效率显然要高些”显然是对的，但是字段的长短似乎不是由变不变长决定，而是业务本身决定。在 SQLSERVER6.5或者之前版本，不定长字符串字段的比较速度比定长的字符串字段的比较速度慢很多，所以对于那些版本，我们都是推荐使用定长字段存 储一些关键字段。而在2000版本，修改了不定长字符串字段的比较方法，与定长字段的比较速度差别不大了，这样为了方便，我们大量使用不定长字段。
7、关于连接表的顺序或者条件的顺序的说法，经过测试，在SQL SERVER，这些顺序都是不影响性能的，这些说法可能是对ORACLE有效。
相关链接：
