为什么在信息爆炸的时代，论索引的重要性不容忽视？

开篇小测验 下面这样一个小SQL 你该怎么样添加最优索引 两个表上现在只有聚集索引 bigproduct 表上已经有聚集索引 ProductID bigtransactionhistory 表上已经有聚集索引 TransactionID 你是否一眼就能看出来呢？ 答案将在文章中逐步揭晓~~~ 简单粗暴的添加索引 首先我们看一下没有优化前的执行计划 clustered index scan 这其实就是表扫描，不是table scan 只是因为表上有聚集索引 可以看出这个查询俩表都使用了表扫描！ where 条件添加索引 首先大多数人都知道 where 条件中的字段需要添加索引! 我们添加一下看看效果创建 在 bigproduct 表上创建 name 列索引，在bigtransactionhistory表上创建TransactionDate 列索引。 再次执行语句看一下效果！ 添加where索引以后可以看到以下几个现象 bigproduct 从原来的clustered index scan 变成 index seek 另外多出来个KEY Lookup(clustered) bigproduct 上添加的索引起了作用，逻辑读bigproduct 由 601 变成10。 bigtransactionhistory 没啥变化啊还是clustered index scan 解释一下出现的现象 ：首先一点bigproduct 边添加的where条件索引，起到了作用，执行的时候不是全表扫描了，逻辑读有明显的下降，出现的 KEY Lookup 是因为选择（select）的列，在索引中没有，而需要通过聚集索引再查找一次，再找一次也意味着多一部分开销！那么同样添加了where 条件索引的bigtransactionhistory表为什么没起作用呢？那是因为SQL优化器在选择计划的时候认为，不使用TransactionDate 列索引查找效率会更好! 真的么？我们来验证一下，通过指定选择索引，来让优化器选择索引查找！ 强制使用索引以后，可以看出逻辑读由 14W 变成1961W，语句时间也变得很长，这就是优化器为什么不选用你加的索引！优化器还是很智能的吧。 高能预警：优化器可不是什么时候都这么智能的...由于缓存计划或优化器抽风等原因，也会出现优化器用了这种索引，导致你的语句奇慢，读飙升直接影响到你的内存、磁盘、CPU资源！另外如果这样一条语句是系统中一条很频繁运行的语句，你的系统就挂了！没错就挂了！这就是开篇抛出的问题就是因为一条语句！ 消灭Key Lookup 添加select 字段 这就是传说中的覆盖索引！ 看到执行计划中存在Key Lookup　而且消耗占比很高，如上面强制索引的计划，那么我们就要想到的 在索引中包含那些SELECT 的列！如果消耗低，逻辑读少，如上面bigproduct 表中的Key Lookup 就可以忽略（如果你追求完美，也一样优化就可以了）。