

你好,我是悟空。
今天又排查了一个 MySQL 慢查询的问题,接下来讲解下该 SQL 的问题和解决方案。整体过程如下图所示:

通过监控慢查询,可以看到最近1小时内执行了 700多次查询,平均执行时间 2s,如下图所示:

SQL语句如下:
select
overdue_amount
from
cont_execute exe
leftjoin (
SELECT
cont_number,
is_important_cont,
is_important_cont_in,
ROW_NUMBER() OVER (
PARTITIONBY
cont_number
ORDERBY
create_time DESC
) AS rn
FROM
cont_review_main
WHERE
del_flag = 0
) mainon exe.cont_number = main.cont_number
where
exe.del_flag = 0
and main.rn = 1
and main.is_important_cont_in = 0
and exe.cont_company_name = 'xx科技有限公司'
该监控工具没有给出实质性的优化建议,如下图所示,删除冗余索引,改写建议都无法提升 SQL的查询性能。


步骤 | 表 | 类型 | 行数 | 问题 |
|---|---|---|---|---|
DERIVED | cont_review_main | ref | 77,724 | 全量扫描 + filesort |
PRIMARY | <derived2> | ALL | 77,724 | 派生表无索引,全表扫描 |
PRIMARY | exe | ref | 1 | 通过 cont_number 索引查找 |
<derived2> 无索引,导致全表扫描 77,724 行子查询生成派生表后,MySQL 无法为其创建索引(除非用 LATERAL 或物化),所以 main.rn = 1 的过滤是在无索引的全表扫描上进行的。
cont_review_main 的 filesort 开销大Using filesort 对 77,724 行做窗口函数排序
虽然用了 idx_htps1_main(del_flag 上的索引),但 PARTITION BY cont_number ORDER BY create_time DESC 需要额外排序。
使用LATERAL关联子查询避免派生表全扫描(MySQL 8.0.14+)
SELECT
exe.overdue_amount
FROM
cont_execute exe
INNERJOINLATERAL (
SELECT
is_important_cont,
is_important_cont_in
FROM cont_review_main main
WHERE main.cont_number = exe.cont_number
AND main.del_flag = 0
ORDERBY main.create_time DESC
LIMIT1
) mainON main.is_important_cont_in = 0
WHERE
exe.del_flag = 0
AND exe.cont_company_name = '伟仕佳杰(重庆)科技有限公司';
优势:LATERAL 让子查询能利用 exe.cont_number 逐行过滤,避免生成大派生表。
需要的索引:
CREATE INDEX idx_main_cont_time
ON cont_review_main(cont_number, create_time DESC, del_flag);
测试执行时间,0.75s,共计 3w条数据,性能有较大提升。

LATERAL 是 MySQL 8.0.14+ 引入的关键字,意思是横向关联或逐行引用。
“空哥发言:普通子查询是独立执行的,LATERAL 子查询可以引用外层表的当前行。
-- 报错:exe.cont_number 在子查询里不认识
SELECT *
FROM cont_execute exe
INNER JOIN (
SELECT *
FROM cont_review_main m
WHERE m.cont_number = exe.cont_number -- ← 这里 exe 不存在!
LIMIT 1
) main
-- 正确:LATERAL 允许子查询引用 exe 的当前行
SELECT *
FROM cont_execute exe
INNER JOIN LATERAL (
SELECT *
FROM cont_review_main m
WHERE m.cont_number = exe.cont_number -- ← 现在可以用了!
ORDER BY m.create_time DESC
LIMIT 1
) main
直观比喻
类型 | 执行方式 | 类比 |
|---|---|---|
普通子查询 | 先一次性算完,再和外层关联 | 先印好一本通讯录,再发给大家 |
LATERAL | 逐行执行,每行都用外层的值去查 | 每个人报姓名,现场查电话 |
两个 SQL 在逻辑上基本等价,但存在一个微妙的潜在差异:当 cont_review_main 中同一合约存在多条 create_time 相同的记录时,两者选择“最新记录”的结果可能不一致。
维度 | SQL 1(LATERAL + LIMIT) | SQL 2(窗口函数 + ROW_NUMBER) |
|---|---|---|
筛选最新记录的方式 | ORDER BY create_time DESC LIMIT 1 | ROW_NUMBER() OVER (PARTITION BY cont_number ORDER BY create_time DESC) 后取 rn = 1 |
对于相同 create_time 的处理 | 数据库返回不确定的一条(通常依赖存储顺序或索引扫描顺序) | ROW_NUMBER() 的排序结果也不确定(若排序键不唯一,编号分配无稳定规则) |
核心过滤条件 | 要求最新记录的 is_important_cont_in = 0,且必须存在匹配的审核记录 | 同上(通过 WHERE main.rn = 1 AND main.is_important_cont_in = 0) |
JOIN 类型 | INNER JOIN LATERAL(隐式要求子查询有返回值) | LEFT JOIN + WHERE 条件(实际等效为 INNER JOIN,因为 main.rn 和 main.is_important_cont_in 均为 NOT NULL 时才会保留) |
其他 | 包含 USE INDEX 提示,仅影响执行计划,不改变结果 | 派生表中多选了 is_important_cont 列,未使用 |
create_time 具有唯一性(或业务上不存在重复时间)的前提下,两个 SQL 完全等价。如果需要严格等价且结果确定,可将两个 SQL 都改为按 (create_time DESC, id DESC) 排序(假设 id 唯一)