不能直接替代，因@@wait_timeout是服务端C++变量，而标量子查询走SQL引擎路径，二者生命周期、作用域、权限模型完全不同。
标量子查询不能直接替代系统配置函数，但能安全封装配置读取逻辑——前提是配置表结构稳定、有唯一键约束。
为什么不能直接用 (SELECT value FROM config WHERE key = 'timeout') 替代 @@wait_timeout
MySQL 的 @@wait_timeout 是服务端变量，由 C++ 层维护，而标量子查询走的是 SQL 引擎执行路径，二者生命周期、作用域、权限模型完全不同。强行用子查询模拟系统变量，会导致：
- 每次执行都触发一次独立查询，无法被查询缓存（即使 MySQL 8.0+ 已移除 Query Cache，仍影响计划重用）
- 若
config表无索引或存在重复key，会报错Subquery returns more than 1 row - 事务中读取配置可能受隔离级别影响（如
REPEATABLE READ下读到旧快照）
如何让标量子查询真正“动态”且安全
关键不在语法，而在数据层契约。必须满足三个前提：
-
config表主键或唯一索引必须是key字段（不是联合索引，不带前导列） - 所有业务写入配置必须通过存储过程或应用层校验，禁止
INSERT IGNORE或ON DUPLICATE KEY UPDATE隐式覆盖 - 读取时强制加
FOR UPDATE（仅限需要强一致的场景），否则默认用SELECT ... FROM config WHERE key = ?
示例：在存储过程中获取超时值并参与计算
SELECT id, name, IFNULL((SELECT CAST(value AS UNSIGNED) FROM config WHERE key = 'default_page_size'), 20) AS page_size FROM users WHERE status = 'active';
注意：IFNULL 和 CAST 不可省略——字符串型配置值直接参与数值运算会隐式转为 0，且无警告。
PostgreSQL 和 SQL Server 的等效写法差异
PostgreSQL 支持更严格的标量子查询空值处理：
- 用
(SELECT value FROM config WHERE key = 'log_level')::integer强制类型转换，失败则报错，不静默为 NULL - 可用
COALESCE((SELECT ...), 'info')，但需确保所有分支类型兼容
SQL Server 要特别注意 NULL 传播：
-
ISNULL((SELECT value FROM config WHERE key = 'retry_count'), 3)安全；COALESCE在子查询为空时可能因类型推导失败报错 - 必须显式声明子查询返回单值，否则报错
Subquery returned more than 1 value
最易被忽略的点：标量子查询里的 config 表访问，不会触发外层查询的统计信息更新，优化器对它的代价估算永远是“常量开销”。一旦配置表变大或缺少索引，性能劣化毫无征兆。
