应将深层子查询改写为物化临时表或CTE预聚合、用窗口函数替代逐行子查询、以EXISTS替代IN、对齐标准时间窗口并注意时区。
子查询嵌套过深导致超时，怎么改写？
直接在 WHERE 里连套三层子查询（比如先查 IP、再查该 IP 的请求频次、再和全局均值比），MySQL 8.0 下 1 亿行日志表大概率触发 Query execution was interrupted。本质是优化器无法为多层相关子查询生成有效执行计划。
实操建议：
- 把最内层聚合结果提前物化：用
CREATE TEMPORARY TABLE或 CTE（WITH）先算出每个client_ip的 5 分钟请求数，加索引KEY(client_ip, ts) - 避免在子查询里用
ORDER BY ... LIMIT 1做“取最新一条”，改用窗口函数ROW_NUMBER() OVER (PARTITION BY client_ip ORDER BY ts DESC)配合外层过滤 - 如果只是做阈值判断（如“单 IP 每分钟 > 1000 次”），优先用
HAVING COUNT(*) > 1000而非子查询比较
用 EXISTS 替代 IN 处理高基数 IP 列
日志中 client_ip 有上千万不同值时，WHERE client_ip IN (SELECT DISTINCT client_ip FROM logs WHERE status = 403) 会触发全表扫描 + 临时表排序，实际执行比 EXISTS 慢 3–5 倍。
原因在于 IN 子句对空值敏感且无法利用索引跳过匹配失败的分支；而 EXISTS 只要找到第一个匹配就短路返回。
正确写法：
SELECT DISTINCT client_ip
FROM logs l1
WHERE EXISTS (
SELECT 1 FROM logs l2
WHERE l2.client_ip = l1.client_ip
AND l2.status = 403
AND l2.ts > NOW() - INTERVAL 1 HOUR
);注意点：
- 子查询里必须关联外层表（这里是
l2.client_ip = l1.client_ip），否则变成非相关子查询，失去短路优势 - 子查询条件中尽量复用外层表已有的过滤字段（如时间范围），避免回表
时间窗口滑动异常：GROUP BY 时间切片不准
想查“每 10 分钟内请求量突增 300% 的 IP”，但用 GROUP BY FLOOR(UNIX_TIMESTAMP(ts)/600) 会导致跨天或夏令时边界错位，凌晨 1:59 和 2:01 被分到不同窗口。
更稳的做法是用日期函数对齐标准窗口：
- PostgreSQL：用
time_bucket('10 minutes', ts)（需安装 timescaledb） - MySQL 8.0+：用
DATE_SUB(ts, INTERVAL SECOND(ts)%600 SECOND)精确截断到最近整 10 分钟起点 - 通用方案：把
ts转成CHAR(13)格式（如'2024-05-22 14:3'）再分组，牺牲精度换稳定性
别忽略时区——日志时间戳若存的是 UTC，但业务监控看的是本地时区，直接按 HOUR(ts) 分组会漏掉关键时段。
关联子查询性能崩盘：为什么不能直接 SELECT 子查询字段？
写 SELECT client_ip, (SELECT COUNT(*) FROM logs l2 WHERE l2.client_ip = l1.client_ip AND l2.ts > l1.ts - INTERVAL 5 MINUTE) AS recent_cnt FROM logs l1 看似直观，但 MySQL 对每行 l1 都会重新执行一次子查询，100 万行日志可能触发 100 万次索引查找。
替代方案分场景：
- 需要实时逐行计算：改用窗口函数
COUNT(*) OVER (PARTITION BY client_ip ORDER BY ts RANGE BETWEEN INTERVAL 5 MINUTE PRECEDING AND CURRENT ROW) - 能接受轻微延迟：先用
INSERT INTO tmp_recent_counts SELECT client_ip, COUNT(*), FLOOR(UNIX_TIMESTAMP(ts)/300) AS bucket FROM logs GROUP BY client_ip, bucket预聚合，再 JOIN - 只关心 TopN 异常 IP：先
GROUP BY client_ip HAVING COUNT(*) > 5000缩小范围，再对这几百个 IP 做精细分析
真正难的不是写出子查询，而是判断哪一层该下推到存储引擎、哪一层该交给应用层缓存——比如用户行为序列中的“3 分钟内连续 5 次 404”这种模式，硬塞进 SQL 容易失控，不如导出 ID 后用 Python 的 pandas.DataFrame.rolling() 处理。
