参数化本身不慢，真正拖慢子查询的是隐式类型转换、索引失效或优化器误判相关性；当参数导致status字段发生CAST、未指定varchar长度或无法预估选择率时，易触发DEPENDENT SUBQUERY并放弃物化，使每行外层数据重复执行子查询。
参数化本身不会让子查询变慢——真正拖慢性能的，是参数化后触发了隐式类型转换、索引失效或优化器误判相关性。
为什么参数化反而让子查询变慢？
常见现象是：硬编码值时 WHERE id IN (SELECT user_id FROM logs WHERE status = 'active') 走索引很快，但改成 WHERE id IN (SELECT user_id FROM logs WHERE status = ?) 后执行时间翻倍甚至超时。根本原因不是“用了参数”，而是参数传入后导致字段类型与绑定值不匹配，或优化器无法预估选择率。
- 隐式类型转换：比如
status是VARCHAR字段，但应用层传入的是整数1（而非字符串'1'），数据库会自动加CAST(status AS SIGNED)，索引直接失效 - 参数未指定精度/长度：PostgreSQL 或 SQL Server 中，
varchar参数若未声明长度（如只写text或默认varchar），可能触发计划缓存复用失败，每次编译新计划 - 优化器对参数值“一无所知”：硬编码时优化器能基于统计信息估算返回行数；参数化后只能按“平均选择率”猜，容易选错驱动表或放弃物化，尤其在子查询含
GROUP BY或LIMIT时
MySQL 中参数化子查询触发 DEPENDENT SUBQUERY 的典型场景
只要子查询里引用了外层列，又带参数，MySQL 很可能放弃物化，退化为每行都重跑一次的 DEPENDENT SUBQUERY。这不是 bug，是设计使然——优化器无法确认参数值是否影响子查询逻辑依赖关系。
- 例如：
SELECT * FROM orders o WHERE EXISTS (SELECT 1 FROM users u WHERE u.id = o.user_id AND u.state = ?)，哪怕?值固定，只要u.id = o.user_id存在外层引用，就进嵌套循环 -
EXPLAIN FORMAT=TREE中看到dependent subquery节点 +Using temporary; Using filesort，基本可断定没物化 - 解决办法不是去掉参数，而是拆：把参数化子查询提前抽成派生表（
FROM (SELECT ... WHERE state = ?) AS tmp），确保它不依赖外层列
PostgreSQL 对参数化标量子查询的特殊限制
PostgreSQL 在 SELECT 列表中用标量子查询（如 (SELECT name FROM users WHERE id = o.user_id)）时，即使参数化，也强制走嵌套循环——这是引擎限制，不是配置问题。
- 标量子查询 + 参数 + 外层大表 = 性能灾难：10 万行外层数据，就会执行 10 万次子查询
- 替代方案只有两个：
LEFT JOIN预关联，或用LATERAL（需 PostgreSQL 9.3+），后者语法更接近原意但需显式声明依赖 - 注意：
LATERAL不等于自动加速，它只是让优化器明确知道“这个子查询要按行求值”，仍需配合索引；没索引的LATERAL比标量子查询还慢
最常被忽略的一点：参数化不是“安全开关”，而是把执行计划的控制权部分交给了运行时。子查询快不快，最终取决于 EXPLAIN 里那个 key 是否非空、rows 是否接近实际、有没有 dependent 标记——而不是你用了 ? 还是写了具体值。
