集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建议都分析一下。