WHERE id = ? 不一定走主键索引，主要因类型不匹配、缺失PRIMARY KEY约束、SELECT *读取过多字段、JOIN中关联字段无索引或对id做计算等导致索引失效。
为什么 WHERE id = ? 不一定走主键索引
MySQL 或 PostgreSQL 看起来写了 id = 123 就能秒出结果，但实际可能全表扫描——常见原因是 id 字段类型和传入参数不一致。比如数据库里是 BIGINT，而应用层传了字符串 "123"，MySQL 会隐式转换字段值（而非参数），导致无法使用索引。PostgreSQL 更严格，类型不匹配直接报错或跳过索引。
- 检查执行计划：MySQL 用
EXPLAIN SELECT * FROM users WHERE id = 123;，重点看type是否为const或eq_ref，key是否显示主键名 - 确认字段类型：用
DESCRIBE users;或\d users查id实际类型，和代码里传参类型对齐 - ORM 框架要注意：如 Django 的
User.objects.get(id="123")在id是整型时会触发类型转换；应写成id=123（整数）
主键不是 PRIMARY KEY 就没用
有些表看着有 id 列，也设了 NOT NULL 和 AUTO_INCREMENT，但没显式加 PRIMARY KEY 约束——这种 id 不是主键，不会自动建聚簇索引，WHERE id = ? 就只是普通查询，性能无保障。
- 检查是否真为主键：MySQL 执行
SHOW CREATE TABLE orders;，确认输出里含PRIMARY KEY (`id`) - 修复方式：如果缺失，用
ALTER TABLE orders ADD PRIMARY KEY (id);（注意：要求id全非空且唯一） - 复合主键场景：
PRIMARY KEY (order_id, item_id)时，单查WHERE order_id = 123仍可能走索引，但WHERE item_id = 456就不行——最左前缀原则生效
SELECT * 在宽表中拖慢精确查找
主键查找本身很快，但若表有 50 个字段、其中几个是 TEXT 或 JSON，SELECT * 会让数据库读取大量无关数据页，I/O 和网络开销远超索引定位本身。
- 只查必需字段：把
SELECT *改成SELECT id, name, status，尤其避开大字段 - 注意覆盖索引机会：如果所需字段都在主键索引里（比如只有
id和created_at），InnoDB 可直接从 B+ 树叶子节点取值，不用回表 - ORM 中慎用
.values()或.only()：Django 的User.objects.only("id", "email")能减少传输量，但别漏掉业务逻辑依赖的字段
连接查询中主键查找失效的典型场景
单表 WHERE id = ? 很快，但一连表就变慢，往往不是主键本身的问题，而是优化器放弃了走主键索引。比如 JOIN 条件没走索引、驱动表选错、或 ON 子句用了函数。
- 确保被驱动表的关联字段有索引：例如
SELECT u.* FROM users u JOIN orders o ON u.id = o.user_id，orders.user_id必须有索引（哪怕不是主键） - 避免在
ON或WHERE里对主键做计算：如ON u.id + 0 = o.user_id或WHERE CAST(u.id AS CHAR) = "123"，都会让索引失效 - 小表驱动大表：如果
users是小表，orders是大表，确保users是驱动表（MySQL 8.0+ 通常自动判断，但复杂查询仍需STRAIGHT_JOIN干预）
主键索引不是银弹，它只对“等值、类型匹配、无计算、单字段”这类最干净的查询条件完全可靠。现实里多一个空格、少一个类型断言、连一次没索引的外键，都可能让它沉默退场。
