子查询的核心价值在于解耦运行时依赖，而非替代硬编码；它通过动态计算逻辑下推至数据库执行层实现灵活性，但需配合索引优化、with复用、join替代相关子查询等设计才能落地。
子查询不是为了“替代硬编码”而存在，而是为了解耦运行时依赖。真正提升存储过程灵活性的，是把**动态计算逻辑下推到数据库执行层**，而不是把值写死在代码里。
子查询 vs 硬编码：本质差异在数据来源时机
硬编码（比如 WHERE status = 1）把业务规则锁死在 SQL 文本中；子查询（比如 WHERE status = (SELECT default_status FROM config)）让数据库在每次执行时去查当前有效的配置值。
关键区别：
• 硬编码修改必须改存储过程定义，触发重新编译
• 子查询只需更新 config 表，存储过程本身不动
• 配置变更对调用方完全透明，无需发版、无需重启应用
但单靠子查询不等于灵活——容易踩的坑
很多人以为只要把数字换成 (SELECT ...) 就算参数化了，结果反而更慢、更难维护：
-
WHERE id IN (SELECT user_id FROM blacklist)—— 如果blacklist表没索引，每次执行都全表扫描 -
WHERE amount > (SELECT AVG(amount) FROM orders o2 WHERE o2.user_id = orders.user_id)—— 相关子查询，主表每行都重跑一次，O(n×m) 复杂度 -
WHERE created_at > (SELECT DATE_SUB(NOW(), INTERVAL ? DAY))—— 参数占位符 ? 在子查询里不生效，MySQL 直接报错
真正提升灵活性的组合用法
单独用 子查询只是起点，要配合结构设计才能落地：
- 用
WITH提前计算并复用结果：比如WITH active_config AS (SELECT key, value FROM sys_config WHERE env = @env)，后续多处引用避免重复执行 - 和
JOIN替代相关子查询：把 “每个用户查一遍平均订单额” 改成先聚合再JOIN，执行计划从DEPENDENT SUBQUERY变成HASH JOIN - 子查询只负责“取值”，条件组装交给应用层或存储过程参数：比如
IF @status IS NOT NULL THEN SET @where = CONCAT(@where, ' AND status = ?');，再用sp_executesql绑定
硬编码仍有其合理场景
不是所有地方都要消灭硬编码。以下情况直接写死更稳妥：
- 状态码枚举值，如
order_status IN (1, 2, 3)—— 这些值几乎永不变更，且语义明确 - 时间偏移固定值，如
DATE_ADD(created_at, INTERVAL 7 DAY)—— 逻辑本身是业务契约，不应由配置表动态控制 - 性能敏感路径中的常量过滤，如分区键
WHERE tenant_id = 1001—— 避免额外 IO 和计划不确定性
