HAibiiin 摘要: 1 张图，512 个字左右，让你在 3 分钟彻底搞 MySQL 产生“回表”现象的原因，同时了解“回表”现象对性能的实际影响，并掌握解决“回表”现象的思考方向。
在使用 MySQL 的过程中，你一定听说过“回表”这一概念。“回表”影响查询性能几乎成为大家的普遍共识，但事实真的是这样吗？虽然网络上关于“回表”的分析与解决方式的文章非常多，但是绝大多数文章点到为止，并未真正指明其原因。只要你使用的是 MySQL 数据库就会有“回表”的问题吗？
“回表”究竟是谁的问题？
首先 MySQL 从高层视角来看可以分成两个部分：MySQL Server 和 Storage Engine 。其中存储引擎可以认为是可插拔架构。
如果“回表”是 MySQL 的普遍现象，那么可以判断是 Server 的实现机制导致的回表，否则说明问题出现在引擎实现层面。
MySQL 虽然支持存储引擎的可插拔，并且除了提供一系列内置存储引擎实现外，也可由使用者实现自定义的存储引擎。但是 MySQL 使用最广泛的存储引擎还是集中在 InnoDB ，以及 MyISAM 上。
我们通过建立一张 city_info 表，分析其在两种存储引擎上的查询过程：
CREATE TABLE city_info (
id INT AUTO_INCREMENT PRIMARY KEY,
code VARCHAR(20),
name VARCHAR(50),
INDEX (code)
) ENGINE=InnoDB CHARSET=utf8mb4;
“回表”的真实原因
结合上图，MySQL 在使用 InnoDB 作为存储引擎时，通过辅助索引（二级索引）获取数据时，当索引中的字段无法覆盖选择列时才会出现所谓的“回表”现象。
产生这一现象的根本原因是辅助索引（二级索引）的叶子节点的值记录的是聚簇索引（主键索引）的主键值。如果 InnoDB 的辅助索引（二级索引）叶子节点的值记录的是聚簇索引（主键索引）的“地址”的引用，那么“回表”所带来的性能影响至多一次随机 I/O 。
首先如果采用记录“地址”引用的方式，那么数据变更的操作会更复杂，涉及更多的索引页变化，同时意味着锁的时间会变长，事务的时间会变长，影响写操作性能的同时也降低了负载。
通过记录“地址”引用的方式所带来的收益，在负面影响下似乎显得微不足道。那么为了降低“回表”的影响，InnoDB 做了那些优化呢？
通过默认开启自适应哈希索引（Adaptive hash index）的方式，对于频繁使用的辅助索引，通过在 Buffer Pool 的内存缓冲区中以哈希的结构提供更快速的查询（查询能力有限，支持等值或最左前缀匹配）。又因为 InnoDB 在从 Disk 获取数据页时，会将其加载到 Buffer Pool 内存缓冲区中，所以查询性能也会更快。
“回表”一定会带来性能问题吗
基于上文分析与描述，我们不需要彻底解决“回表”问题，因为如果我们检索数据的条件相对固定且频繁，InnoDB 内部优化机制会降低“回表”所带来的性能影响。
“回表”问题要如何解决
通常的实现方式是结合应用系统中的查询语句，将表中必要列加入到辅助索引（二级索引）中，避免对聚簇索引（主键索引）的查找。遗憾的是，因为辅助索引的存储空间成本，也不能够解决所有问题。如果是一个高频随机检索的表，并且伴随着极低频率的变更操作，那么这张表的存储引擎尝试用 MyISAM 替代 InnoDB 也未尝不可。
总结
回到我们文章的标题所提出的问题“为什么 MySQL 需要‘回表’？”。答案至此也相对明了，需要“回表”的只是 InnoDB 存储引擎。“回表”并不一定会对查询性能造成影响，同时只要使用 InnoDB 就无法 100% 的解决“回表”想象。
本文为 1KB 专栏系列文章。在这一专栏中，我将通过 1 张图，512 个字左右，让你在 3 分钟彻底搞懂一个技术领域问题、概念与知识。不论是日常工作还是面试准备，都可以快速检索与浏览。
如果您发现文章内容中任何不准确或遗漏的部分。非常希望您能评论指正，我将尽快修正疏漏，为大家提供优质技术内容。
你好，我是 HAibiiin，一名探索技术之外更多可能性的 Product Engineer。如果本篇文章对你有所启发或提供了一定价值，还请不要吝啬点赞、收藏和关注。
![[爱了]](/js/img/d1.gif)
![[尴尬]](/js/img/d16.gif)