inner join 仅返回两表关联字段均存在且匹配的记录，结果偏少主因是连接字段含 null、类型不一致或隐式转换；on 控制连接逻辑，where 过滤结果；性能瓶颈多因缺失索引或函数导致索引失效。
INNER JOIN 能准确筛出两张表都存在的关联记录，但一旦连接字段有 NULL 或值不匹配，对应行就直接消失——这不是 bug，是它的设计本意。
为什么用 INNER JOIN 后结果比预期少？
最常见的原因是连接条件字段存在 NULL、空字符串或类型不一致（比如 user_id 一边是整数、另一边是字符串）。数据库不会把 NULL 和任何值（包括另一个 NULL）匹配上，也不会自动做类型转换。
- 检查两边连接字段是否都
NOT NULL，用SELECT COUNT(*) FROM table WHERE column IS NULL快速验证 - 确认字段类型一致：用
DESCRIBE table_name或PRAGMA table_info(table_name)查看定义 - 避免隐式转换：如果
orders.user_id是VARCHAR，而users.id是INT，显式写成CAST(orders.user_id AS INTEGER) = users.id
ON 子句里能写过滤条件吗？
可以，但要分清和 WHERE 的区别：ON 决定“哪些行参与连接”，WHERE 是在连接结果上再筛选。放错位置会导致逻辑错误。
- 想只查“已付款的订单及其用户信息”：把
status = 'paid'放ON是错的，它会把未付款订单也拉进来（只是用户字段为 NULL），正确做法是放在WHERE - 想查“每个用户最近一笔订单”，
ON里必须用子查询或窗口函数限制，不能只靠WHERE - 多表 JOIN 时，
ON条件只作用于当前 JOIN 的两张表，别指望它影响前面或后面的表
性能差得明显，是不是 JOIN 写法有问题？
90% 的慢 JOIN 源于缺少索引或连接字段没走索引。即使写了 INNER JOIN，如果数据库没法快速定位匹配行，就会退化成嵌套循环扫描。
- 确保
ON中的字段都有索引：比如JOIN orders ON users.id = orders.user_id，就要在users.id和orders.user_id上分别建索引 - 避免在
ON字段上用函数：写ON UPPER(u.email) = UPPER(o.email)会让索引失效，应提前标准化数据 - 用
EXPLAIN QUERY PLAN（SQLite）或EXPLAIN（PostgreSQL/MySQL）看实际执行路径，重点关注是否出现SCAN或Using temporary
真正容易被忽略的是连接顺序——有些数据库优化器会重排 JOIN 顺序，但复杂查询中手动把小表放前面、大表放后面，仍可能减少中间结果集大小。别假设优化器永远最优。
