mysql 5.7及更早版本禁止在in/all/any子查询中直接使用limit，属版本硬限制；须外层嵌套派生表并显式命名别名，如where id in (select t.id from (select id from log order by ts desc limit 10) as t)。
MySQL 5.7 及更早版本明确禁止 LIMIT 出现在 IN/ALL/ANY 子查询中
这不是语法写错，而是版本级硬限制。报错信息 This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery' 直接说明：解析器在语法分析阶段就拒绝了这种组合。哪怕你加了括号、ORDER BY，只要 LIMIT 出现在 WHERE ... IN (SELECT ... LIMIT ...) 这种结构里，MySQL 5.6 或更早版本会直接报错退出，根本不进入执行阶段。
根本原因在于：IN 子句要求右侧子查询返回一个“值集合”，而早期 MySQL 的查询优化器无法安全推导带 LIMIT 的标量子查询或集合子查询的语义边界，尤其当它可能被重写为 semi-join 时存在不确定性。
外层再套一层派生表必须带别名，否则报错 Every derived table must have its own alias
常见错误是只加括号不加别名，比如写成 WHERE id IN (SELECT id FROM (SELECT id FROM log LIMIT 10)) —— 这会触发 ERROR 1248: Every derived table must have its own alias。MySQL 要求所有 FROM 子句中的子查询（即派生表）必须显式命名。
- ✅ 正确写法：
WHERE id IN (SELECT t.id FROM (SELECT id FROM log ORDER BY ts DESC LIMIT 10) AS t) - ❌ 错误写法：
WHERE id IN (SELECT id FROM (SELECT id FROM log LIMIT 10))（缺AS t） - ⚠️ 注意：别名
t只需在派生表位置声明，SELECT t.id中的t.是可选的，但加上更清晰，也避免字段歧义
用 JOIN 替代 IN 更高效，尤其当子查询结果集较大时
单纯“套一层”只是绕过语法限制，没解决性能问题。如果子查询返回几千行 ID，IN 在某些场景下仍可能触发全表扫描或临时表膨胀。JOIN 方式让优化器更容易利用索引，并显式控制连接顺序。
- 等价改写：
SELECT u.* FROM users u JOIN (SELECT id FROM log ORDER BY ts DESC LIMIT 10) AS recent ON u.id = recent.id - 优势：避免
IN对右侧结果集做隐式去重和重复匹配；支持对recent派生表加索引提示（如FORCE INDEX） - 注意：若主表
users有重复id（比如逻辑删除未过滤），JOIN 可能放大结果行数，此时需确认业务是否允许
MySQL 8.0+ 已支持，但别盲目依赖版本文档
MySQL 8.0.19 开始，官方文档称已支持 LIMIT 用于 IN 子查询，但实测发现部分部署仍报错——原因常是服务器实际运行的是旧版二进制，或启用了兼容模式。不要仅凭文档判断，务必用 SELECT VERSION() 确认真实版本。
更稳妥的做法是：无论版本如何，只要逻辑上需要“取前 N 条 ID 再关联”，统一采用 JOIN (SELECT ... LIMIT N) AS t 结构。它在所有 MySQL 版本中都稳定，语义清晰，且便于后续迁移到其他数据库（如 PostgreSQL 或 SQL Server）时复用逻辑。
真正容易被忽略的是：嵌套后没检查 ORDER BY 是否还在内层——LIMIT 必须配合 ORDER BY 才有意义，而外层别名表本身不继承排序，所以 ORDER BY 一定要保留在最内层 SELECT 中。
