LEFT JOIN后WHERE过滤右表字段会退化为INNER JOIN，因SQL执行顺序是先JOIN后WHERE，右表NULL行被WHERE中非空条件（如status='paid'）判定为不成立而整行丢弃；正确做法是将右表筛选条件移入ON子句。
LEFT JOIN后WHERE过滤右表字段等于变INNER JOIN
这不是数据库bug，是SQL执行顺序决定的：先完成JOIN，再执行WHERE。LEFT JOIN产生的NULL行，在WHERE中遇到orders.status = 'paid'这种判断时，直接被判定为不成立而丢弃——结果看起来像“数据丢了”，其实是逻辑上被筛掉了。
常见错误写法：LEFT JOIN orders ON users.id = orders.user_id WHERE orders.status = 'paid'；正确做法是把条件挪进ON：LEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'paid'。
- 如果业务真需要保留无订单用户，又只想要已支付订单，就只能用
WHERE orders.status = 'paid' OR orders.status IS NULL，但要注意语义是否还符合需求 - 用
EXPLAIN看执行计划里rows是否明显少于左表总行数，这是最直接的线索 - 临时加
COUNT(*) OVER (PARTITION BY users.id)，观察单个用户是否关联了异常多条订单——如果是，大概率连接失控或条件错位
ON条件漏写主外键等值关系导致笛卡尔积
写成LEFT JOIN orders ON orders.status = 'paid'，没写users.id = orders.user_id，数据库就按规则做CROSS JOIN：每个用户都和所有已支付订单配一遍。结果集爆炸，后续加LIMIT或聚合时，看似有数据，实则随机截断、漏掉大量主表记录。
典型现象：Rows_examined远大于Rows_sent（比如前者1248902，后者仅12），或者EXPLAIN里出现type: ALL配合Extra: Using where; Using join buffer。
- 逐个检查每个
JOIN后面是否紧跟着含左右表字段的等值条件，比如ON t1.id = t2.ref_id - 别依赖“反正WHERE会筛”，
WHERE是在JOIN之后才生效的 - 多表JOIN时，第三张表最容易漏掉中间连接点，比如
addresses.city_id = cities.id没写，就会让整条链断裂
JOIN字段类型不匹配引发隐式转换和NULL失效
当users.id是BIGINT，而orders.user_id是VARCHAR，数据库会尝试隐式转换。这不仅可能触发全表扫描（索引失效），更危险的是：字符串里带空格、制表符，或超长数字转double时精度丢失（如"111111111111111111"和111111111111111110被当成相等），导致匹配错乱或完全不匹配。
- 用
DESCRIBE table_name确认字段类型是否一致 - 查右表连接字段是否有NULL：
SELECT COUNT(*) FROM orders WHERE user_id IS NULL - 清理不可见字符：
SELECT user_id, HEX(user_id) FROM orders WHERE user_id LIKE '%123%'，看HEX里有没有20（空格）或09（制表符） - 显式转换比依赖隐式更可靠，例如
ON users.id = CAST(orders.user_id AS SIGNED)
分页+JOIN组合导致OFFSET跳行或重复
只用ORDER BY created_at DESC LIMIT 20 OFFSET 1000在JOIN结果上分页，风险极大。因为created_at不唯一，数据库每次执行时相同时间戳的行顺序可能不同，OFFSET 1000实际跳过的“第1000行”不是固定记录，翻页就漏或重。
更糟的是，JOIN后结果集膨胀（比如1万订单×平均3条明细=3万行），却只想要20条订单——数据库反复搬运3万行中间结果，再丢掉前1万行。
- 强制补全排序依据：
ORDER BY created_at DESC, id DESC（id主键天然唯一） - 给该组合建联合索引：
CREATE INDEX idx_orders_created_id ON orders(created_at, id) - 改用“先分页主表再JOIN”：
SELECT * FROM orders o JOIN (SELECT id FROM orders ORDER BY created_at DESC, id DESC LIMIT 20 OFFSET 1000) t ON o.id = t.id LEFT JOIN order_items oi ON o.id = oi.order_id - 子查询里严禁出现从表字段、
JOIN、GROUP BY或函数，否则优化器放弃索引下推
真正容易被忽略的，不是语法对不对，而是ON和WHERE的分工边界、类型是否真的一致、以及分页时排序是否足够稳定——哪怕索引全建好，一个条件放错位置，或一个字段类型没对齐，就足以让结果集崩掉一半。
