集30条，查询效率提高了10倍，平均在0.001秒，数据库压力骤降。

影响结果集的常见误区

影响结果集并不是说数据查询出来的结果数或操作影响的结果数，而是查询条

件的索引所命中的结果数。

实战范例

某游戏数据库使用了innodb，innodb是行级锁，理论上很少存在锁表情

况。出现了一个SQL语句(delete from tabname where xid=…)，这个SQL

非常用SQL，仅在特定情况下出现，每天出现频繁度不高（一天仅10次

左右），数据表容量百万级，但是这个xid未建立索引，于是悲惨的事情

发生了，当执行这条delete 的时候，真正删除的记录非常少，也许一到

两条，也许一条都没有；但是！由于这个xid未建立索引，delete操作时

遍历全表记录，全表被delete操作锁定，select操作全部被locked，由于

百万条记录遍历时间较长，期间大量select被阻塞，数据库连接过多崩溃。

这种非高发请求，操作目标很少的SQL，因未使用索引，连带导致整个

数据库的查询阻塞，需要极大提高警觉。

总结：

影响结果集是搜索条件索引命中的结果集，而非输出和操作的结果集。

影响结果集越趋近于实际输出或操作的目标结果集，索引效率越高。

请注意，我这里永远不会讲关于外键和join的优化，因为在我们的体系里，

这是根本不允许的！ 架构优化部分会解释为什么。

理解执行状态

常见分析手段

慢查询日志，关注重点如下

是否锁定，及锁定时间

如存在锁定，则该慢查询通常是因锁定因素导致，本身无需优化，需解决

锁定问题。

影响结果集

如影响结果集较大，显然是索引项命中存在问题，需要认真对待。

Explain 操作

索引项使用

不建议用using index做强制索引，如未如预期使用索引，建议重新斟酌

表结构和索引设置。

影响结果集

这里显示的数字不一定准确，结合之前提到对数据索引的理解来看，还记

得嘛？就把索引当作有序序列来理解，反思SQL。

Set profiling , show profiles for query操作

执行开销

注意，有问题的SQL如果重复执行，可能在缓存里，这时要注意避免缓

存影响。通过这里可以看到。

执行时间超过0.005秒的频繁操作SQL建议都分析一下。