这类报错基本不是语法错误，而是数据库版本、方言限制或上下文约束导致的硬性拦截；需先定位“不支持”类型再更换写法，如mysql低版本用外层子查询加别名替代limit+in，sql server标量子查询改用offset/fetch或cte，postgresql保留字须加双引号。
直接说结论：这类报错基本不是你写错了，而是数据库版本、方言限制或上下文约束导致的硬性拦截。得先定位是哪类“不支持”，再换写法。
MySQL 5.7 及更早版本中 LIMIT 出现在 IN/ANY 子查询里
错误信息典型是 This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY subquery'。这不是语法错，是版本锁死——MySQL 5.6 和更早压根不解析这种组合。
- 最稳解法：外层再套一层子查询，并给它加别名，例如把
WHERE id IN (SELECT id FROM log ORDER BY ts DESC LIMIT 10)改成WHERE id IN (SELECT t.id FROM (SELECT id FROM log ORDER BY ts DESC LIMIT 10) AS t) - 替代方案：用
JOIN替代IN，比如SELECT o.* FROM orders o JOIN (SELECT id FROM log ORDER BY ts DESC LIMIT 10) l ON o.id = l.id - 注意：别漏
AS t—— MySQL 要求FROM后的子查询必须有别名，否则仍报错
SQL Server 标量子查询里用了 TOP
写成 (SELECT TOP 1 status FROM events WHERE user_id = u.id ORDER BY ts DESC) 会直接失败，因为 SQL Server 在标量上下文中禁用 TOP（除非整个子查询被括号包裹且明确单行）。
- 安全写法是换用
OFFSET 0 ROWS FETCH NEXT 1 ROW ONLY，它被明确允许在子查询中使用 - 或者改用窗口函数提前物化，比如先用 CTE 算出每组最新值，再关联，避免在标量位置硬塞排序+截断
- 额外提醒：
TOP不带唯一ORDER BY时结果不可重复，而OFFSET/FETCH同样依赖排序字段能唯一确定行
低版本 SQL Server（如 2003）在 VALUES 列表里嵌套子查询
类似 INSERT INTO t(a, b) VALUES ('x', (SELECT MAX(id)+1 FROM t)) 在老版本会报 在此上下文中不允许使用子查询。只允许使用标量表达式。
- 不能靠加括号绕过，得彻底换语法：改用
INSERT INTO t(a, b) SELECT 'x', MAX(id)+1 FROM t - 这种写法把子查询变成
SELECT的一部分，不在VALUES的受限上下文中，所有版本都认 - 如果原语句还要插入多行，就用
UNION ALL拼多个SELECT，别回到VALUES里硬塞子查询
PostgreSQL 中保留字当字段名但没加双引号
报错像 syntax error at or near "user"，看着像 user 这个词出问题，其实是因为它被识别为内置函数，导致前面的语法结构断裂。
- 所有疑似保留字（
user、order、group、table等）作为标识符时，必须用双引号包裹，例如SELECT "user".name FROM "user" - 别信 IDE 自动补全——它可能只在外层加引号，而子查询里的同名字段漏了，照样崩
- 查当前版本完整保留字列表：运行
SELECT * FROM pg_get_keywords() WHERE catcode = 'R'
真正麻烦的不是语法本身，而是同一段 SQL 在不同数据库、不同版本、甚至不同执行上下文（VALUES vs SELECT vs UPDATE SET）里，支持边界完全不同。写之前先确认目标环境的具体限制，比事后调错快得多。
