子查询超时本质是外层语句等待其结果触发时限，关键在EXPLAIN中识别DERIVED/MATERIALIZED及rows过大或type=ALL，结合应用层timeout配置排查，而非单纯重写子查询。
子查询超时不是子查询本身“卡住”，而是整个外层语句在等待子查询结果时触发了数据库级或应用级的执行时限。排查重点不在“重写子查询”，而在确认它是否被优化器正确处理、是否触发了隐式全表扫描或优化器超时。
检查 EXPLAIN 输出里子查询是否转为派生表（derived）或物化（materialized）
MySQL 5.7+ 和 MariaDB 10.2+ 会对部分子查询自动物化，但物化过程若缺少索引或数据量大，会导致延迟飙升。执行 EXPLAIN 后重点关注 select_type 列：
- 出现
DERIVED：说明子查询被当作临时派生表处理，需检查其内部 WHERE 条件是否有索引 - 出现
MATERIALIZED：表示子查询结果被缓存，但若rows值极大（如 >10万），说明物化成本高 -
type=ALL出现在子查询对应的行：直接暴露未走索引，哪怕外层有索引也无用
警惕 Oracle/SQL Server 中子查询导致优化器超时
Oracle 10g–12c 和 SQL Server 在多层嵌套子查询 + 多表 JOIN 场景下，容易触发优化器超时（StatementOptmEarlyAbortReason="TimeOut"）。这不是 SQL 写得慢，而是优化器放弃穷举更优计划：
- SQL Server 查询计划 XML 中搜索
TimeOut字符串，确认是否真因优化器提前终止 - Oracle 中查看
V$SQL_PLAN.OTHER_XML是否含optimizer_mode=first_rows类提示，这类模式在复杂子查询中极易退化 - 临时绕过方式：用
WITH子句将子查询提前物化（Oracle/SQL Server 都支持），强制拆分优化边界
避免 WHERE 中使用非关联子查询 + 函数或类型转换
这类写法会让优化器无法下推条件，导致子查询每次外层行都重新执行，且极易失效索引：
- 错误示例：
WHERE user_id IN (SELECT CAST(id AS CHAR) FROM black_list)——CAST导致索引失效，且子查询无法复用 - 错误示例：
WHERE create_time > (SELECT MAX(update_time) FROM config)—— 若config表无索引，该子查询虽只执行一次，但MAX()仍需全表扫描 - 正确做法：确保子查询字段与外层类型严格一致；对单行标量子查询，优先用
JOIN替代，尤其当子查询表有合适索引时
区分是数据库超时还是应用连接超时
子查询耗时 8 秒，但应用报错是 “Connection timed out” 或 “Query timeout”，大概率是应用层设置过严，而非数据库真卡死：
- Spring Boot 的
spring.datasource.hikari.connection-timeout默认 30 秒，但若设成 5 秒，就会掩盖真实问题 - MySQL 客户端默认
wait_timeout=28800（8 小时），但 JDBC URL 若加了connectTimeout=3000&socketTimeout=5000，则 5 秒就断连 - 先查数据库实际执行耗时：在 MySQL 中运行
SELECT NOW(); /* your query */; SELECT NOW();，对比时间差，再比对应用日志里的报错时间戳
子查询超时最常被忽略的点是：你以为它只跑一次，其实它被重复执行；你以为它走索引，其实函数一裹全失效；你以为是数据库慢，其实是应用把 5 秒当 500 毫秒来管。盯住 EXPLAIN 里的 select_type 和 rows，再核对应用层 timeout 配置，90% 的“子查询超时”根本不是子查询的问题。
