子查询必须用别名，否则因字段解析错误导致ERROR 1054；应显式限定表别名（如o1、o2），优先用EXISTS替代IN以防NULL干扰，时间值需参数化避免CURDATE()重复调用偏差，并为user_id和created_at建复合索引优化相关子查询性能。
子查询必须用别名，否则会报 ERROR 1054 (42S22): Unknown column
MySQL 和 PostgreSQL 都不允许在子查询中直接引用外层查询的同名字段（尤其当子查询和主表是同一张表时），不加别名就会把字段解析成子查询内部的列——而它根本不存在。比如想比对「今天」和「昨天」的订单量：
SELECT COUNT(*) AS today_cnt FROM orders WHERE DATE(created_at) = CURDATE() AND user_id IN ( SELECT user_id FROM orders WHERE DATE(created_at) = CURDATE() - INTERVAL 1 DAY );
这段看似合理，但若 orders 表里没有 user_id 字段（或拼写错误），或者子查询里没限定好范围，就会触发 Unknown column。更稳妥写法是显式加别名：
- 主表 alias 为
o1，子查询 alias 为o2 - 所有字段前缀写全：
o1.user_id、o2.user_id - 子查询必须返回单列（除非用
EXISTS或元组比较）
用 EXISTS 比 IN 更安全，尤其当子查询可能返回 NULL
IN 遇到子查询结果含 NULL 时，整行判定为 UNKNOWN，导致数据丢失——这在时间字段有空值的业务表里极常见。例如查「昨天下单、今天又下单的用户」：
SELECT DISTINCT o1.user_id
FROM orders o1
WHERE DATE(o1.created_at) = CURDATE()
AND EXISTS (
SELECT 1 FROM orders o2
WHERE o2.user_id = o1.user_id
AND DATE(o2.created_at) = CURDATE() - INTERVAL 1 DAY
);EXISTS 只关心是否存在匹配行，不依赖值是否为 NULL，也不受子查询返回列内容影响。注意：SELECT 1 是惯用写法，实际可写 SELECT NULL 或任意常量。
时间范围别硬写 CURDATE()，用参数化或变量避免重复计算
如果子查询和主查询都调用 CURDATE() 或 NOW()，数据库可能在两次调用间产生微小偏移（尤其高并发场景），导致逻辑错位。更稳的方式是提前算好时间边界：
- MySQL：用
SET @today = CURDATE(); SET @yesterday = @today - INTERVAL 1 DAY;，后续子查询直接引用@yesterday - PostgreSQL：用
WITH time_bounds AS (SELECT CURRENT_DATE AS td, CURRENT_DATE - '1 day'::INTERVAL AS yd)做前置绑定 - 应用层传参时，统一生成两个时间字符串（如
"2024-06-15"和"2024-06-14"），避免数据库函数歧义
硬写函数还会影响查询计划缓存——不同时间点执行的 SQL 文本不同，无法复用执行计划。
大表慎用相关子查询，先加复合索引再测性能
上面的 EXISTS 示例是相关子查询（依赖外层 o1.user_id），对每行 o1 都要跑一次 o2 查询。若 orders 有千万级数据，没索引会全表扫描子查询几十万次。
必须确保子查询过滤条件能走索引：
-
WHERE o2.user_id = o1.user_id AND DATE(o2.created_at) = ...→user_id和created_at的复合索引才有效 - 不要用
DATE(created_at)，改用范围查询：o2.created_at >= '2024-06-14' AND o2.created_at ，这样能命中 <code>created_at索引 - 验证是否走索引：MySQL 用
EXPLAIN FORMAT=TREE，PostgreSQL 用EXPLAIN (ANALYZE, BUFFERS)
时间字段上函数包裹、类型隐式转换、字符集不一致，都会让索引失效——这是最常被跳过的排查点。
