子查询不能直接嵌在WHERE里引用外层字段，只有相关子查询（如WHERE、HAVING或SELECT标量位置）才能访问外层表字段；派生表或CTE不可穿透作用域，LATERAL可显式声明依赖但仅限FROM子句。
子查询不能直接嵌在WHERE里引用外层字段？
不是所有带括号的SELECT都能当“子查询”用。只有相关子查询（correlated subquery）才能访问外层表字段，比如写在WHERE、HAVING或SELECT标量位置的子查询。报错Unknown column 't1.name' in 'field list'，基本就是把派生表（FROM (SELECT ...)）或CTE误当成可穿透作用域的结构了。
常见错误包括：
• 在FROM子句里写(SELECT ... WHERE user_id = t1.id) AS t2——t1.id在括号内根本不可见
• 把WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = users.id)错写成WHERE (SELECT COUNT(*) FROM orders o WHERE o.user_id = users.id) > 0（后者虽能运行，但非相关子查询时users.id仍需显式限定）
- 确认子查询出现在
WHERE/HAVING/标量SELECT中，且外层表别名被显式写出（如users.id，而非id） - MySQL 8.0+ 或 PostgreSQL 可用
LATERAL显式声明依赖，但SQL Server和旧版MySQL只能靠标准相关子查询 - 三层以上嵌套时，SQL Server某些版本会拒绝解析外层字段，建议提前用
JOIN或APPLY替代
动态拼接时怎么避免SQL注入和类型错乱？
拼字符串是最危险的路径。哪怕只拼WHERE条件，CONCAT(' AND status = ', @status)这种写法一旦@status是用户输入，就等于敞开大门。
安全做法只有一条：参数化。但注意——子查询内部的参数绑定，必须由宿主环境统一处理，不能靠存储过程里EXEC sp_executesql单独包裹子查询。
- 在应用层（如C# SqlKata、Java MyBatis）用
.Where()链式构建，最终生成带?或@param占位符的SQL，由驱动自动绑定 - SQL Server存储过程中，若需动态子查询，应把整个查询语句作为参数传入
sp_executesql，且所有变量都列在第二、三参数中，例如：EXEC sp_executesql @sql, N'@uid INT', @uid = @user_id - 金仓数据库等兼容MySQL的系统支持命名参数（
:param_name）和位置参数（?），但不支持混合；绑定时务必严格匹配顺序和类型，否则可能触发隐式转换导致索引失效
为什么用JOIN比子查询更稳？
多数动态条件场景下，EXISTS或IN子查询看着简洁，但执行计划容易退化，尤其当子查询返回大量行或含ORDER BY/LIMIT时。而JOIN天然支持谓词下推、索引选择和统计信息复用。
比如要查“有订单且订单总额超5000的用户”，写成WHERE u.id IN (SELECT user_id FROM orders GROUP BY user_id HAVING SUM(amount) > 5000)，优化器可能放弃索引走嵌套循环；改用JOIN (SELECT user_id FROM orders GROUP BY user_id HAVING SUM(amount) > 5000) o ON u.id = o.user_id，就能明确控制连接顺序和物化时机。
- 派生表（
FROM (...) AS t）作用域仅限当前FROM，但它的结果可被WHERE引用（只要别名在外部可见） - CTE（
WITH t AS (...)）全局可见，适合复用聚合逻辑，但注意MySQL 5.7不支持CTE下推，WHERE条件可能无法下压到CTE内部 - 真正需要“参数化子查询”的场景（如按不同维度动态聚合），优先用
JOIN+ 应用层条件判断，而不是在SQL里拼IF分支
MyBatis里<foreach>和${}混用有多坑？
${}是纯文本替换，不经过预编译，拼表名、排序字段、GROUP BY列时看似方便，但一旦用户可控就直接RCE。而<foreach>本身安全，但它包裹的${}依然危险。
典型翻车现场：ORDER BY ${orderBy} + <foreach collection="ids" item="id">${id}</foreach>——前者可能被注入id; DROP TABLE users--，后者若ids来自前端，${id}就等于把恶意SQL直接塞进IN列表。
- 排序字段必须白名单校验，用
<if test="orderBy == 'name'">ORDER BY name</if>代替${orderBy} -
<foreach>只用于IN、VALUES等明确接受多值的位置，且内部一律用#{}（如#{id}） - 动态表名/列名无法参数化，只能靠服务端严格映射（如
map.get("user") → "t_user"），绝不能直通用户输入
复杂点在于：相关子查询的作用域规则、参数化与动态拼接的边界、以及不同数据库对LATERAL/CTE的支持差异。这些地方稍一松懈，不是查不出数据，就是查得太慢，或者干脆被拖库。
