6.5 MySQL 查询优化器的局限性

6.5.1 关联子查询

一般 SQL 写成:

普通人认为的查询顺序:

MySQL 实际改写为:

• 查看其执行计划, 可以使用 EXPLAIN EXTENDED 查看改写成什么样子
• 是相关子查询
• 性能糟糕

重写查询:

书中内容有些过时, 请参考:

• mysql数据库中 IN 和 EXISTS 的误区

也就是说, 如果不确定性能怎样, 那么就查看一下执行计划.

如何用好关联子查询

写法一:

写法二:

区别:

性能测试:

相反的举例

写法一:

写法二:

性能测试:

还是那句话, 想知道性能如何, 就要测试.

6.5.2 UNION 的限制

在 UNION 的两个子查询中使用 LIMIT 来减少临时表中的数据:

注意:

• 从临时表中取出的数据的顺序不是一定的, 如果想要获得正确的顺序, 还需要加上全局的 ORDER BY 和 LIMIT

6.5.3 索引合并优化

MySQL 能够访问单个表的多个索引以合并和交叉过滤的方式来定位需要查找的行.

6.5.4 等值传递

IN() 列表非常大会出现性能问题.

6.5.5 并行执行

MySQL 无法利用多核特性来并行执行查询.

6.5.6 哈希关联

当时的 MySQL 不支持哈希关联.

• 使用嵌套循环关联

6.5.7 松散索引扫描

• MySQL 不支持松散索引扫描, 无法按照不连续的方式扫描一个索引

例子:

• 无法使用 (a, b) 上的索引

• 全表扫描

• 松散索引扫描的路径

MySQL5.0 之后的版本, 在某些特殊的场景下可以使用松散索引扫描:

• Using index for group-by 表示使用松散索引扫描

6.5.8 最大值和最小值优化

优化前:

• first_name 上没有索引

优化后:

• 损失了查询含义

6.5.9 在同一个表上查询和更新

• 错误的更新 SQL

• 重写