MySQL不允许子查询中直接使用LIMIT，除非子查询被括号包裹且作为派生表（如FROM子句中的临时表）或标量子查询出现；否则会触发ERROR 1235等语法错误，且必须配合ORDER BY保证结果确定性。
子查询里直接写 LIMIT 会报错
MySQL 不允许在子查询中直接使用 LIMIT，除非整个子查询被括号包裹且作为独立 SELECT 表达式出现。否则会触发 ERROR 1235 (HY000): This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery' 或类似语法错误。
常见错误写法：SELECT * FROM users WHERE id IN (SELECT id FROM logs ORDER BY ts DESC LIMIT 10) —— 这在 MySQL 8.0 之前版本直接报错；即使 8.0+ 支持，也要求子查询必须加括号、且不能出现在 IN 左侧无修饰的上下文中。
- 正确写法必须显式用括号包围子查询：
(SELECT id FROM logs ORDER BY ts DESC LIMIT 10) -
IN子句中允许这种带LIMIT的子查询，但仅限于标量子查询或行子查询，且需括号 -
JOIN中的子查询也必须括号化，例如：SELECT u.* FROM users u JOIN (SELECT user_id FROM events ORDER BY created_at DESC LIMIT 100) e ON u.id = e.user_id
LIMIT 在子查询中的实际生效范围
子查询里的 LIMIT 只作用于该子查询本身的结果集，不会影响外层查询逻辑。但它可能改变外层行为：比如 IN 子查询返回 5 行 vs 500 行，对连接性能和结果完整性有直接影响。
- 若子查询用于
EXISTS，LIMIT 1是合理优化（只要确认存在即可）：EXISTS (SELECT 1 FROM orders WHERE user_id = u.id LIMIT 1) - 若用于
IN，且子查询结果可能重复或缺失，LIMIT可能导致漏匹配 —— 比如只取前 10 个user_id，但实际有 15 个符合条件 - 子查询中用了
LIMIT却没写ORDER BY，结果不可预测，外层查询每次执行可能拿到不同数据
MySQL 版本差异与替代方案
MySQL 5.7 不支持大多数含 LIMIT 的子查询；8.0.19+ 支持更多场景，但仍不支持 LIMIT 出现在 UNION 子句内部或某些嵌套层级中。
- 老版本绕过方法：用派生表（即把子查询当临时表用），例如：
SELECT * FROM users WHERE id IN (SELECT id FROM (SELECT id FROM logs ORDER BY ts DESC LIMIT 10) AS t) - 更稳妥的做法是拆成两步：先查出 ID 列表（应用层缓存或临时表），再用于主查询
- 如果目标是“取每个分组 Top N”，别硬套
LIMIT子查询，改用窗口函数：ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC)（MySQL 8.0+）
容易被忽略的排序依赖
子查询里写 LIMIT 却没配 ORDER BY，等于随机抽样 —— 外层查询结果每次执行都可能不同，调试时很难复现问题。
- 哪怕只是
LIMIT 1，也要明确排序依据，例如：(SELECT name FROM products WHERE category = 'book' ORDER BY price ASC LIMIT 1) - 复合排序更安全：避免因排序字段值重复导致每次选中不同行，例如加主键：
ORDER BY status, id DESC - 特别注意：子查询的
ORDER BY在没有LIMIT时会被优化器忽略；但一旦加了LIMIT，ORDER BY就强制生效（否则无法确定哪几行该被截断）
