个人创作公约：本人声明创作的所有文章皆为自己原创，如果有参考任何文章的地方，会标注出来，如果有疏漏，欢迎大家批判。如果大家发现网上有抄袭本文章的，欢迎举报，并且积极向这个 github 仓库 提交 issue，谢谢支持~本文是“为什么我建议”系列第三篇，本系列中会针对一些在高并发场景下，我对于组内后台开发的一些开...

这个 SQL 执行了 20 分钟才有结果。但是我们换一个 user_id，执行就很快。从线上业务表现来看，大部分用户的表现都正常。我们又用一个数据分布与这个用户相似的用户去查，还是比较快。

这个 SQL 其实就是将 t_retailer_order_record 中 archive_id 为 420a7fe7-4767-45e8-a5f5-72280c192faa 的所有记录的订单 id order_id，对应的订单表中的记录的 archive_id 也更新为 420a7fe7-4767-45e8-a5f5-72280c192faa 并且更新时间保持不变（因为表上有 update_time 按当前时间更新的触发器）。

今天收到运营同学的一个 SQL，有点复杂，尤其是这个 SQL explain 都很长时间执行不出来，于是我们后台团队帮忙解决这个 SQL 问题，却正好发现了一个隐藏很深的线上问题。

本文基于 MySQL 8在前面的两篇文章，我们分析了 MySQL InnoDB 引擎的两种行记录存储格式：Compact 格式Redundant 格式在这里简单总结下：Compact 格式结构：变长字段长度表：包括数据不为NULL的每个可变长度字段的长度，并按照列的顺序逆序排列NULL 值列表：针对可以为 NULL 的字段，用一个 BitMap 来标识哪些字段为 NUL...