InnoDB二级索引查询需回表，即先查二级索引得主键，再用主键查聚簇索引获取整行数据；MyISAM则直接通过物理地址读取数据，无需回表，但受限于表级锁和无事务。
InnoDB二级索引查完还要再搜一次主键
InnoDB的二级索引叶子节点只存PRIMARY KEY值，不存数据本身。比如你建了INDEX idx_name ON users(name)，查SELECT * FROM users WHERE name = 'Alice'时，MySQL先在idx_name树里找到对应主键（比如id = 1024），再拿着这个1024去聚簇索引（即主键索引）B+树里重新查找整行数据——这就是“回表”。整个过程至少两次B+树搜索，且第二次很可能触发磁盘随机IO。
常见错误现象：EXPLAIN中type是ref但Extra出现Using where; Using index或Using index condition，说明走了二级索引但仍需回表；如果SELECT字段没被索引覆盖，就一定会回表。
- 主键要是UUID或随机字符串，回表时B+树页分裂严重，buffer pool命中率暴跌
- 用
SELECT id, name FROM users WHERE name = ?就能避免回表——只要所有字段都在索引里，就是覆盖索引 - 隐式主键（如InnoDB自建的6字节
row_id）无法被引用，也不能用于优化回表路径
MyISAM二级索引叶子节点直接存物理地址
MyISAM所有索引（包括主键）都是非聚簇的，叶子节点存的是数据行在.MYD文件里的物理偏移量（比如第8327字节开始）。查WHERE name = 'Alice'时，索引定位后直接按地址读.MYD，一步到位，没有“再找一遍”的概念。
但这不等于更快：MyISAM的物理地址访问在高并发写入或数据频繁变更时局部性差，且.MYD文件本身无事务保护，崩溃后可能读到半截记录。
- MyISAM表导出再导入后容易丢失主键定义，
SHOW CREATE TABLE里看不到PRIMARY KEY，但业务SQL仍按主键逻辑写，导致隐式类型转换失败 - 它的“快”只在静态只读场景成立；一旦有
UPDATE或DELETE，表级锁会让并发吞吐断崖下跌 -
.MYI和.MYD可分置不同磁盘，靠系统层做IO优化；InnoDB的.ibd是混合存储，buffer pool压力更大
回表性能差距本质不在算法而在IO模式
表面上看，InnoDB多一次B+树查找，MyISAM少一层跳转。但真实瓶颈是IO行为：MyISAM的物理地址读取具备较好空间局部性（尤其顺序插入时），而InnoDB回表若主键离散（如UUID），会导致大量随机磁盘寻道——哪怕buffer pool够大，也难缓存住分散的主键页。
实操建议：
- 别为“减少一次查找”把InnoDB表强行改成MyISAM——表级锁和无事务才是更致命的短板
- 真要优化InnoDB回表，优先改主键：用自增
INT或BIGINT，避免UUID；其次建覆盖索引，把SELECT字段全包含进去 - MyISAM的
SELECT COUNT(*)快，是因为它缓存了行数；但带WHERE条件时，两者都得扫描，MyISAM并无优势
迁移MyISAM到InnoDB时最容易漏掉的事
执行ALTER TABLE t ENGINE=InnoDB只是换引擎，不解决根本问题。如果原MyISAM表没显式主键，InnoDB会悄悄加上隐藏row_id，但这个ID不可见、不可索引、不可用于JOIN，还额外占6字节空间，高并发INSERT时易成瓶颈。
必须同步补上显式主键：
- 已有业务字段能唯一标识行（如
user_id），直接设为PRIMARY KEY - 没有合适字段，加一个
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY，并确保AUTO_INCREMENT列是索引首列 - 别依赖MyISAM遗留的
KEY命名习惯——InnoDB对联合索引顺序敏感，(a,b)和(b,a)性能差异极大
回表不是个孤立操作，它把索引结构、主键设计、buffer pool利用率、甚至磁盘IO调度全串在一起。多数人卡在“为什么加了索引还是慢”，其实问题早埋在建表那行PRIMARY KEY里。
