mysql check约束仅在8.0.16+真正生效，低版本仅解析语法不校验；必须实测插入非法值验证，且依赖严格模式、innodb引擎和dynamic行格式。
相关子查询不能直接用于 CHECK 约束或触发器外的校验逻辑——这不是写法问题，是数据库引擎的硬性限制。你真正能用它做业务校验的地方，只有 SELECT、UPDATE、DELETE 的 WHERE 或 SELECT 列表中，且必须接受“逐行执行、性能敏感、结果必须单行单列”这三条铁律。
WHERE 中用相关子查询做动态存在性校验
比如要查“所有有至少一条有效订单的用户”，不能靠应用层先查再过滤，而要用 EXISTS 显式表达语义：
-
EXISTS比IN更安全：子查询里字段为 NULL 时，IN整个条件变UNKNOWN，行被静默丢弃；EXISTS只看是否存在匹配，不受 NULL 影响 - 子查询里写
SELECT 1而非SELECT *，部分数据库可跳过列解析，轻微提速 - 被关联字段（如
orders.user_id）必须有索引，否则每次主表扫描都触发一次全表扫描 - 错误写法：
WHERE user_id IN (SELECT user_id FROM orders WHERE status = 'paid')—— 若orders.user_id允许 NULL，结果不可靠 - 正确写法：
WHERE EXISTS (SELECT 1 FROM orders WHERE orders.user_id = users.id AND status = 'paid')
SELECT 列表中用相关子查询返回标量校验结果
当你需要在查询结果里附带一个“是否符合某规则”的标记（比如是否 VIP、是否有逾期账单），相关子查询是最直白的方式，但必须确保它只返回一行一列：
- 每个子查询结尾加
LIMIT 1或用聚合函数（如MAX()、COUNT(*)）强制单行，否则报错Subquery returns more than 1 row - 用
COALESCE((SELECT ...), 0)显式处理 NULL，避免和主查询其他字段参与计算时出错 - 避免在
CASE WHEN里嵌套多层相关子查询，类型不一致（比如有的分支返回字符串，有的返回数字）会导致排序错乱或隐式转换失败 - 示例：
(SELECT COALESCE(MAX(1), 0) FROM vip_rules vr WHERE vr.user_id = u.id AND vr.expires_at > NOW()) AS is_vip
UPDATE/DELETE 中用相关子查询实现条件驱动的写操作
UPDATE 语句里用相关子查询看似方便，但极易踩坑——它不像 JOIN 那样有明确的执行计划，优化器难推导，且 MySQL 对 UPDATE 子查询有额外限制：
- 优先改用
JOIN：例如 “给 VIP 用户加 5% 积分”，写成UPDATE users u JOIN vip_rules v ON u.id = v.user_id SET points = points * 1.05，比UPDATE users SET points = points * 1.05 WHERE id IN (SELECT user_id FROM vip_rules)更可控 - 若必须用子查询，WHERE 条件必须加明确限定（如
AND status = 'active'），防止误更新 - MySQL 8.0+ 支持
UPDATE ... FROM语法，更接近标准 SQL，推荐替代老式子查询写法 - 禁止在子查询里调用
NOW()、RAND()等非确定性函数，否则可能被重复求值，导致结果不一致
为什么你总在性能上栽跟头？关键在索引和物化
相关子查询最常被忽略的不是语法，而是执行路径：它本质是 N+1 查询，主表每行都触发一次子查询执行。没索引就是灾难：
- EXPLAIN 输出里看到
DEPENDENT SUBQUERY就该警觉——说明正在走嵌套循环 - 子查询 WHERE 条件中的外键字段（如
orders.user_id）必须建索引；如果还要按时间排序取最新一条，建组合索引更优：CREATE INDEX idx_orders_user_status_time ON orders(user_id, status, created_at DESC) - MySQL 8.0.22+ 可用
/*+ MATERIALIZE */提示强制物化子查询结果，但仅适用于非相关子查询；相关子查询无法物化，只能靠索引硬扛 - 三层以上相关子查询基本等于放弃优化——此时应该拆成 CTE 或应用层分步处理，别硬刚
