主键查询快是因为InnoDB中主键索引即聚簇索引，叶子节点直接存储整行数据，一次B+树查找即可获取全部字段，无需回表；而二级索引需先查索引再回表。
主键查询为什么快？因为数据就存索引里
MySQL 的 InnoDB 引擎中，主键索引就是聚簇索引——PRIMARY KEY 对应的 B+ 树叶子节点直接存着整行数据。查主键时，一次 B+ 树搜索就能拿到全部字段，不用回表。
这和普通二级索引完全不同：INDEX idx_name 的叶子节点只存主键值，查它得先扫索引树、再拿主键去聚簇索引里二次查找（回表）。所以主键等值查询天然最快。
- 必须是
InnoDB引擎才生效；MyISAM没有聚簇索引概念 - 主键越短越好：用
BIGINT代替VARCHAR(36)做主键，B+ 树层级更低，IO 更少 - 主键要是自增的（
INT UNSIGNED AUTO_INCREMENT），能减少页分裂，写入更连续
用 EXPLAIN 看出是否真走主键索引
别光看 SQL 里写了 WHERE id = ? 就以为走了主键。实际执行计划可能因隐式类型转换、函数包裹或统计信息偏差而失效。
执行 EXPLAIN SELECT * FROM users WHERE id = '123'; 后重点看三列：
-
type应为const（等值匹配单行）或eq_ref（关联查询中主键匹配） -
key应显示PRIMARY，不是NULL或其他索引名 -
rows应为1，不是几百几千
常见翻车点：WHERE id = '123abc' 触发隐式转换，id 列被当字符串比对，索引失效；WHERE CAST(id AS CHAR) = '123' 同理，函数导致无法使用索引。
联合主键下，查询必须「最左前缀」才有效
如果主键是复合的，比如 PRIMARY KEY (org_id, user_id)，那只有按顺序用上左边字段，才能利用聚簇索引优势。
-
WHERE org_id = 100 AND user_id = 200✅ 走主键，一次定位 -
WHERE org_id = 100✅ 范围扫描主键前缀，仍高效 -
WHERE user_id = 200❌ 不走主键索引，全表扫描 -
WHERE user_id = 200 AND org_id = 100✅ MySQL 会自动调整顺序，等价于上面第一条
注意：这种联合主键结构会让 ORDER BY user_id 无法利用索引排序，除非同时带上 org_id 条件。
主键不是万能加速器，大字段和高并发下有隐藏代价
聚簇索引把数据按主键物理排序，听起来很美，但真实场景里容易忽略两点：
- 主键更新等于移动整行数据（比如把
id从 100 改成 200），InnoDB 会先删后插，锁住原位置和新位置，极易引发死锁 - 如果表里有大字段（
TEXT、BLOB），即使只查主键，也可能触发额外 IO：InnoDB 默认把大字段溢出到单独页，查主键时若涉及这些字段，仍要多读几次磁盘 - 高并发插入自增主键时，所有写请求都挤在 B+ 树最右页，可能成为热点，表现为
innodb_row_lock_waits上升
真正影响性能的，往往不是“有没有主键”，而是主键怎么选、怎么用、以及它背后牵动的数据物理布局。很多慢查问题，追到底其实是主键设计和查询模式不匹配。
