主键查找慢的根源不在B+树搜索，而在页加载、锁等待、溢出页IO、结果集序列化及网络传输等后续环节；EXPLAIN无法反映真实瓶颈，需结合Handler_read_key、innodb_buffer_pool_reads及INNODB STATUS诊断。
主键查找为什么还会慢？先看执行路径
MySQL 的主键查找（SELECT * FROM t WHERE id = ?）理论上是 O(log n) 的 B+ 树搜索，但实际慢往往不是因为算法，而是执行链路中被拖慢了。InnoDB 会依次走：连接器 → 分析器 → 优化器（这里基本无代价）→ 执行器 → 存储引擎（定位聚簇索引页 → 加载数据页 → 返回行）。真正卡点常在页加载和锁等待。
- 如果
id对应的数据页不在 Buffer Pool，就要从磁盘读取，一次随机 IO（毫秒级），比内存访问慢 3–4 个数量级 - 若该行正被其他事务加了
X锁（比如正在UPDATE），当前查询会等锁，表现为Waiting for table metadata lock或更常见的Waiting for X lock on PRIMARY - 表没加主键？那 InnoDB 会自建隐藏的
row_id，但此时WHERE row_id = ?无法走索引，退化为全表扫描
EXPLAIN 看不出问题？得看 Handler_read_key 和 innodb_buffer_pool_reads
EXPLAIN 对单行主键查找几乎总是显示 type: const 或 eq_ref，看起来没问题，但掩盖了底层真实开销。关键要看运行时状态变量：
-
SHOW STATUS LIKE 'Handler_read_key'：每成功走一次索引查找就 +1，值低但响应慢？说明是 IO 或锁瓶颈，不是 SQL 写法问题 -
SHOW STATUS LIKE 'innodb_buffer_pool_reads'：非零且持续增长？代表频繁磁盘读页，Buffer Pool 不够或访问模式太散 -
SHOW ENGINE INNODB STATUS\G中的SEMAPHORES和TRANSACTIONS部分，能直接看到锁等待线程和持有者
别只盯着 EXPLAIN 的 key 列是否用了主键——它只告诉你“走了索引”，不告诉你“走得多快”或“有没有被拦住”。
SELECT * 主键查比 SELECT id, name 慢在哪？
主键查找本身不因字段数变慢，但结果集传输和内存拷贝会。尤其当表有大字段（TEXT、BLOB、长 VARCHAR）时：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- InnoDB 行格式为
Dynamic或Compressed时，大字段可能被存到溢出页（off-page），主键查找后还需额外 IO 加载这些页 -
SELECT *会让 MySQL 把整行（包括溢出列）拼成一个内部缓冲区再发给客户端，内存分配和序列化成本上升 - 网络传输量增大，尤其在高并发下容易打满网卡或触发 TCP 拥塞控制
实测：一张含 TEXT 字段的表，SELECT * 平均耗时 8ms，而 SELECT id, name 仅 0.3ms——差的不是索引查找，是后续环节。
唯一能绕过 B+ 树查找的主键访问：SELECT ... INTO @var + 预编译
常规 SELECT 总要走完整执行器路径，哪怕只查一行。但如果你只需要把值存进变量（比如做简单判断或中间计算），可以用更轻量的方式：
SET @v = 0; SELECT name INTO @v FROM users WHERE id = 123;
这种写法跳过了结果集构造和网络包封装，执行器直接赋值给用户变量，对高并发简单判断场景（如权限校验）可降低 10%–20% 延迟。配合预编译语句（PDO::prepare 或 mysql_stmt_prepare）还能省去 SQL 解析开销。
- 注意：
INTO @var要求结果必须恰好一行，否则报错Subquery returns more than 1 row或No data to FETCH - 不能用于返回给应用层；只是服务端内部快速取值
- MySQL 8.0.23+ 支持
SELECT ... FROM VALUES ROW()语法模拟点查，但仅限字面值，不适用真实业务主键
真正的瓶颈从来不在“能不能找到”，而在“找到之后做了什么”——溢出页、锁竞争、大字段序列化、客户端收包逻辑，这些才是压垮简单 point select 的最后一根稻草。
