JOIN字段类型不一致必然导致隐式转换，引发索引失效、全表扫描（EXPLAIN中type=ALL、key=NULL）及结果错误；须通过SHOW CREATE TABLE或INFORMATION_SCHEMA比对DATA_TYPE/CHARACTER SET/COLLATION并用ALTER TABLE统一类型。
JOIN字段类型不一致导致隐式转换
这是最隐蔽也最常踩的坑：比如users.id是bigint，而orders.user_id是varchar，mysql或postgresql在join时会自动做类型转换，结果就是索引失效——哪怕两边都有索引，执行计划里key也会是null，type变成all。
实操建议：
- 用
DESCRIBE table_name或Navicat右键“对象信息”确认字段类型，逐字比对（包括长度，如VARCHAR(20)和VARCHAR(50)也可能触发转换） - 修改字段类型前先备份，MySQL中改类型可能锁表；PostgreSQL可用
ALTER COLUMN ... TYPE bigint USING user_id::bigint - 避免用字符串存数字ID，尤其在关联字段上
ON条件写在WHERE里让LEFT JOIN退化
写成LEFT JOIN logs ON u.id = logs.user_id WHERE logs.level = 'error'，表面看是左连接，实际优化器会把它当作INNER JOIN处理，还可能导致users表的索引无法利用。
原因在于WHERE过滤发生在JOIN之后，而logs.level为NULL的行被直接剔除，破坏了LEFT语义。
正确做法是把条件移到ON子句：
LEFT JOIN logs ON u.id = logs.user_id AND logs.level = 'error'
这样既保留左表全量，又只关联符合条件的右表记录，索引也能正常走。
执行计划显示possible_keys有值但key为空
这不代表SQL写错了，而是优化器主动放弃了索引。常见诱因：
- 统计信息过期：
ANALYZE TABLE users（MySQL）或ANALYZE users（PostgreSQL）强制刷新 - 索引选择性太低：比如
status只有'active'/'inactive'两个值，优化器认为全表扫描更快 - JOIN顺序不合理：大表被当作驱动表，小表没索引可走；用
STRAIGHT_JOIN（MySQL）或/*+ Leading() */（PG）手动指定驱动表 - 字符集/排序规则不一致：如一张表用
utf8mb4_0900_as_cs，另一张用utf8mb4_unicode_ci，会导致Using temporary; Using filesort并跳过索引
PostgreSQL中Seq Scan不是病，但得看上下文
Navicat里看到Seq Scan别急着加索引。它只是说明走了全表扫描，是否真慢取决于：
- 表大小：1万行以内
Seq Scan可能比索引+随机IO还快 - WHERE条件是否用了函数：
WHERE to_char(created_at, 'YYYY-MM') = '2026-01'会让索引失效，改成范围查询created_at >= '2026-01-01' AND created_at -
random_page_cost值是否合理：SSD上建议调到1.1，否则优化器总以为随机读比顺序读贵得多
真正该警惕的是Seq Scan出现在百万行以上表、且rows远高于实际返回数——这时才要查缺失索引或重写条件。
