写这篇东西的起因，是因为最近半年聊MySQL的人，口径悄悄变了。前两年大家问的都是“8.0能不能上”，现在问的是“8.0我们也上了，但这些怪问题你们遇到过没有”。MySQL 8.x已经成了新项目的事实标准，老项目也基本都在迁移路上或者已经迁完，但大量此前没被暴露的坑，恰恰是等大家真正跑起来、跑久了以后才集中冒出来的。
我自己是从5.7时代一路用过来的，一开始也是把8.0当成“大版本号+性能优化”去理解，结果在认证、优化器、存储结构、复制、在线DDL这些方向上，先后被上了一课又一课。这篇文章不打算复述官方文档，而是把我在生产环境里真实撞过、或者帮别人排查过的那些“8.0特有坑”整理出来。适合三类人看：正在做5.7到8.0迁移评估的架构师、已经上线8.0但遇到诡异问题的DBA、以及写SQL时总被执行计划“教育”的后端开发。
1. 一进版本就能撞上的三个默认值变化：认证、排序规则、SQL模式
1.1 caching_sha2_password不只是“改回去”这么简单
8.0的默认认证插件从mysql_native_password换成了caching_sha2_password，这个事绝大多数人都知道，但知道和踩坑是两回事。最常见的症状是：代码连不上库，报Authentication plugin 'caching_sha2_password' cannot be loaded，于是很多人第一反应就是把用户的认证方式改回mysql_native_password。
我见过好几个团队都是这么干的，也确实立刻解决了问题。但这么做只是把一个坑挪到未来罢了：老认证协议迟早被彻底弃用，如果你们公司的安全审计已经开始强制检查弱认证协议，你会发现腾挪空间越来越小。而且更隐蔽的是，同一个实例里如果既有新插件用户又有老插件用户，一些连接池在预热时的行为会很古怪，偶发握手失败，查日志又什么都看不出来。
真正稳妥的做法是升级客户端驱动，然后保留caching_sha2_password。这里有一个典型的细节：Java驱动默认不允许获取RSA公钥来做密码明文传输，如果不显式开启allowPublicKeyRetrieval=true，在缓存认证失效的瞬间就会报Public Key Retrieval is not allowed。很多系统测试环境跑得好好的，一到线上并发一上来就偶发报错，就是因为第一次握手需要做公钥交换。我自己的习惯是：升级8.0后，先把所有连接池预热脚本跑一遍，再观察一两天认证相关的错误日志，确认没有偶发握手失败再放量。
1.2 默认排序规则变了，索引可能在你没意识到的情况下失效
8.0默认字符集是utf8mb4，默认排序规则是utf8mb4_0900_ai_ci，而大量5.7老库用的是utf8mb4_general_ci。这两者的区别不只是“排序结果可能不同”，更麻烦的是它会悄悄影响SQL的执行计划。
举个例子，一张业务表用了utf8mb4_general_ci，另一张字典表用了utf8mb4_0900_ai_ci，两张表做JOIN，连接字段的排序规则不一致，优化器没法直接按索引条件做等值匹配，可能就把连接条件当成普通表达式处理，结果就是本来该走索引的变成了全表扫描。我不止一次看到有人排查慢SQL，EXPLAIN一看索引没用上，最后才发现是两个表collation不一致导致的。
另外，0900系列排序规则对特殊字符的相等性判断和general_ci不完全一样，某些别名、特殊符号、带重音字符的排序，在两套规则下结果可能根本不同。迁移时的建议很明确：不要指望全库默认值帮你兜底，直接梳理一遍核心业务表的DDL，统一成同一种排序规则，再上线。这个动作放在迁移初期做，成本最低。
1.3 严格模式和ONLY_FULL_GROUP_BY：老代码的第一个报错现场
8.0默认sql_mode里带STRICT_TRANS_TABLES、ONLY_FULL_GROUP_BY、NO_ZERO_IN_DATE、NO_ZERO_DATE、ERROR_FOR_DIVISION_BY_ZERO等一堆选项。5.7其实默认也有，但很多老实例上线时被人为改成了宽松模式，或者从古老版本一路升级上来，实际跑代码的风格一直是“怎么都能塞进去”。
所以迁移8.0以后，最先炸的往往不是性能，而是一堆“以前能跑、现在直接报错”的SQL。最经典的是SELECT name, COUNT(*) FROM member GROUP BY age这种写法，name没有出现在GROUP BY里，8.0直接拒绝执行；还有往int列插入超长数值，5.7只是warning然后截断，8.0直接报错；日期字段插入0000-00-00，也一样被拒。
这类问题真正难搞的地方在于测试环境不容易暴露。开发测主流程都是正常数据，只有报表、数据修复脚本、批量任务这类会在边界数据上跑的SQL，才会在线上忽然给你来个“启动失败”。处理建议是：先别想着把sql_mode全局改宽松，那相当于把脏数据问题重新请回来。正确做法是逐条修SQL，然后把sql_mode固化到实例配置里，并且纳入监控，防止某台从库或某个测试实例因为配置不一致，造出一套和线上完全不同的行为。这里可以给一个简单对照：
| 常见老写法 | 5.7宽松模式下 | 8.0默认模式下 |
|---|---|---|
| insert超长字符串 | warning后截断 | 直接报错 |
| group by外查询非聚合列 | 返回随机值 | 报ONLY_FULL_GROUP_BY错误 |
| 日期字段写0000-00-00 | 允许写入 | 默认拒绝 |
| 除数为0 | warning后结果为NULL | 直接报错 |
2. 优化器“换人”了：我最信任的几条5.7经验全都失效
2.1 hash join：等值连接不建索引反而“更聪明”了
8.0.18开始，优化器在等值连接无法有效利用索引时可以选择hash join。这条特性本身是好事，尤其对OLAP风格的查询，问题在于它彻底颠覆了很多5.7时代的调优经验。
以前我们处理大表JOIN小表，核心思路是让小表驱动大表，大表连接字段必须建索引，这样才能一路嵌套循环走下去。到了8.0，优化器有可能认为hash join代价更低，直接对大表做一次全表扫描构建hash表，然后另一个连接端再扫描。如果连接字段的字符集或排序规则不一致，或者存在隐式类型转换，hash join还可能要额外做转换，内存开销和临时落盘都可能暴涨。
我实际排查过一个案例（某订单统计场景，单表几千万行级别）：SQL完全相同，5.7执行两秒多，8.0执行十几分钟。EXPLAIN里出现了Using join buffer (hash join)，优化器认为它选的方案更优，但实际运行时hash表落盘，性能反而不如老计划。这类问题不能靠“禁用hash join”一劳永逸，更实用的处理是：检查连接字段的类型、字符集、排序规则是否完全一致，消除隐式转换；如果优化器还是选错，再考虑通过索引或FORCE INDEX把执行计划引导回嵌套循环。记住一个关键点：hash join是在“没办法用索引”时才容易被选中的，把连接字段的索引做对，优化器自然会变回去。
2.2 IN子查询和派生表不再按5.7的经验走
5.7时代很多DBA会教你把IN改成EXISTS，或者把一个子查询改成JOIN，大家普遍觉得这样更快。到了8.0，优化器对IN子查询的semi-join物化处理已经很成熟，很多时候它自己就能生成不错的计划，反而是那些“人工改写”的SQL出了问题。
我见过一个挺典型的反面案例：有人为了让一条IN查询更快，改写成INNER JOIN，并加上DISTINCT去重。5.7里这个改写确实有提升，但到8.0后，因为优化器的等价变换逻辑变了，改写后的SQL反而被评估成一种更昂贵的派生表物化路径，结果没快反而慢了一截。更麻烦的是这类改写常常会改变结果集语义，出现重复行翻倍的问题，排查起来特别费劲。
我的建议是：进了8.0，先把那些基于5.7经验的“SQL改写手册”全部重新审视一遍。遇到IN慢查询，第一件事是用EXPLAIN看它到底走了semi-join还是物化，再决定要不要动SQL。很多老经验在新优化器下已经不成立了，硬套反而帮倒忙。
2.3 直方图与统计信息：升级后手动ANALYZE的节奏变了
8.0支持直方图，这是优化器能力的一个重要升级，但默认并不会自动给所有列建直方图。很多DBA从5.7带过来的习惯是“大版本升级完，先跑一轮全库ANALYZE TABLE”，这个动作在8.0下要谨慎。
原因有两层：第一，8.0的统计信息存放在数据字典里，采样和持久化机制跟5.7不完全一样，全库一次性ANALYZE可能造成大量表的数据字典更新，引发短暂的锁竞争和连接阻塞；第二，如果某个表已经存在手动创建的直方图，ANALYZE的行为会和统计信息刷新叠加，优化器读到的“选择性”可能变化很剧烈，执行计划从好变差、从差变好都有可能。
更值得警惕的是，8.0下很多“绕过DDL直接改数据”的批量操作，不会自动触发统计信息更新。比如一行一行UPDATE、DELETE后，如果表数据分布已经明显变化，优化器还拿着旧统计信息预估行数，就可能选错索引。遇到这类场景，针对单表做一次ANALYZE TABLE是合理的，但别搞成全库统一刷。实践上我倾向于：升级后先只对核心大表做受控的统计刷新，观察一两天慢日志，再决定要不要扩大范围。
3. 存储层静默改版：redo、undo、临时表和系统表空间全换了名字和格式
3.1 8.0.30的redo日志改名事件
8.0.30之前，redo日志文件是ib_logfile0、ib_logfile1这样的固定命名；8.0.30之后，redo日志被统一放到了#innodb_redo目录下，文件名也变成了#ib_redoNN一类。这个变化本身是InnoDB为了更灵活管理redo文件做的架构调整，但对运维脚本来说简直是一场“定时炸弹”。
很多团队的监控脚本、备份脚本、日志清理脚本都是按老目录和老文件名校验的。升级到8.0.30之后，脚本可能找不到文件，监控项直接失效，或者清理逻辑把不该动的目录漏掉。更隐蔽的是，老参数innodb_log_file_size和innodb_log_files_in_group在8.0.30之后语义变了，真正生效的是innodb_redo_log_capacity，如果你还在老配置文件里改这两个参数，不仅不会达到预期效果，日志里还可能出现参数废弃的warning。
这里给一个非常具体的建议：在升级到8.0.30或更高版本之前，先全局搜一遍所有包含ib_logfile关键字的脚本、告警配置、自动化巡检项，逐个改成新路径。别相信“我的脚本只读参数不读文件”这种话，实际排查里我见过太多因为监控哑掉而让redo空间撑爆的案例。
3.2 临时表和ibtmp1：排序慢从“内存不足”变成“磁盘类型”
8.0内部临时表的实现从MEMORY引擎换成了TempTable引擎，内存不够落盘时也不再写MyISAM格式，而是用InnoDB格式临时表。这带来的最直接变化是：你在5.7里对临时表空间的理解基本要推翻。
以前出现Using temporary，大家第一反应是tmp_table_size设太小，内存里的临时表不够用，落到磁盘就慢。8.0里除了这个因素，你还要留意临时文件写到哪去了。默认tmpdir如果放在系统盘，或者某些环境是挂载在/dev/shm这种内存盘，一旦大排序、大GROUP BY触发落盘，可能直接把那个分区的空间写满。
另一个老生常谈的坑是ibtmp1文件。8.0的临时表空间文件尺寸增长后不会自动收缩，长时间跑大查询、大事务的系统，ibtmp1涨到几十上百G是很常见的，而且等查询结束它也不会自动瘦身，可能只能等实例重启才能释放。排查的时候记得把ibtmp1当成“只记录峰值，不自动回收”的文件来看，别指望它像普通binlog那样自己清理。对策很简单：监控tmpdir和ibtmp1的增长率，独立挂载临时目录，SQL层面尽量消灭大排序和大临时表。
3.3 mysql.ibd、undo和双写缓冲的新布局
8.0的系统表空间不再是那个膨胀到几十GB的ibdata1，数据字典和系统表大部分挪到了mysql.ibd。以前5.7时代有些DBA会通过“重建ibdata1”来收缩系统表空间，这个土方子在8.0里千万不要再用，因为那基本等同于删掉数据字典，实例直接起不来。
undo表空间的布局也变了。5.7能把innodb_undo_tablespaces配成多个文件分散放，8.0初始化后默认2个undo表空间，数量调整和文件管理方式都有新规则。升级时如果老配置里带了旧的undo路径或数量，可能被新版本忽略，或者产生告警。
8.0.20之后，双写缓冲也不再沿用老文件布局，而是放到#innodb_dblwr目录下。如果你的备份恢复、数据文件巡检脚本里还在找老的双写文件路径，升级后就会失效。这类问题的共同点是：一切跟“文件名、目录路径”相关的运维经验，都要拿官方文档重新对一遍，千万别拿5.7手册直接套8.0。
4. 复制链路的变化：从库追不上和半同步超时，都换了症状
4.1 binlog默认ROW，排障方式完全不同
8.0默认binlog_format=ROW，很多从5.7带着STATEMENT或MIXED习惯过来的团队，在排查主从不一致时会被狠狠教育一次。ROW模式下，binlog里记录的不再是原始SQL，而是每一行数据变更前和变更后的镜像。
以前排查数据不一致，可以对着binlog里的SQL语句在从库手动重放一遍看结果；现在这么做基本没用，你手工执行的结果和从库应用的结果都可能对不上，因为从库应用的是行镜像，触发器、存储过程、函数在复制链路上根本不会二次执行。我们踩过的真实场景是：主库某条数据被修复后，从库的数据和主库不一致，但靠SQL日志完全看不出原因，最后只能用mysqlbinlog --base64-output=DECODE-ROWS把行事件解出来，对比前后镜像才定位到问题。
另外，8.0.20开始支持binlog事务压缩。压缩是好东西，但如果你有一些基于binlog解析的数据同步工具或审计脚本，版本跟不上就会直接不认识压缩事件，表现为解析中断或跳过一堆事务。升级前务必把所有binlog消费端、解析工具全部核对版本，做好兼容性测试。
4.2 并行复制配置和参数迁移
很多5.7实例的并行复制配的是slave_parallel_type=DATABASE，因为不同库的事务才能并行。到了8.0，默认的并行复制策略已经是基于LOGICAL_CLOCK，能在一个库内并行应用没有锁冲突的事务，这样效率高得多。但麻烦在于：如果迁移时直接把老的my.cnf复制过来，配置还是DATABASE模式，从库并行能力就废掉大半，大事务一多延迟立刻飙升。
更隐蔽的是，老配置里那些replicate-wild-ignore-table之类的过滤规则，在8.0下的语义也可能有变化。如果过滤规则写得不准，可能把不该过滤的表也滤掉，造成从库与主库结构漂移。我建议升级8.0复制链路时，参数不要无脑搬运，而是重新根据新版本默认值来写；大事务造成延迟时，也别急着调大slave_parallel_workers，先看并行应用的锁等待状态，很多时候瓶颈不是线程数，是行锁竞争。
4.3 从库重建的姿势要更新：server_uuid和克隆插件
5.7时代重建从库最常见的方式是拿物理备份直接拷贝到新机器，然后change master。这个流程在8.0里有一个特别容易忽略的雷：物理备份通常会连带auto.cnf里的server_uuid一起带走，多台从库如果都从同一份备份克隆，就会出现多个实例使用同一个server_uuid。
这个问题的诡异之处在于，主库初期看不出任何异常，因为连接和复制都能正常建立。但等你要做选主、一主多从切换，或者某些管理工具基于server_uuid做实例识别时，就会开始出现错乱。排查起来极其费神，因为日志不会直接告诉你“UUID重复了”。
8.0官方提供了CLONE插件来做在线克隆，它会在目标实例上重新生成必要的实例标识，比老办法规范得多。如果还是习惯用物理备份手工重建从库，至少要在恢复完成后主动删除或替换auto.cnf，让实例重新生成server_uuid。这个动作建议写进SOP，否则早晚出事。
5. 在线DDL变“瞬时”后，真正的隐患才开始显现
5.1 INSTANT加列：快是真的，隐患也是真的
8.0的INSTANT DDL能让你在秒级内给一张大表加列，第一次用的时候真的会觉得“这功能太香了”。但深入了解之后才发现，快是有代价的。INSTANT加列不是完全无痕，它会基于表当前的行格式做“元数据级变更”，本质上是在行记录里扩展一个“新列的空值版本”。如果一张表被反复执行INSTANT加列，行格式里会积累大量“历史列信息”，表碎片会增加，全表扫描的代价也会悄无声息地上升。
我自己碰到过一个案例：某业务表一年内被各种需求加了差不多20个字段，大部分是INSTANT加的，后来一条简单查询忽然变慢，EXPLAIN里走的是全表扫描，优化器估算代价很高。整理完表之后，扫描代价明显下降。所以这里有一条经验：8.0里加列虽然爽，但要记住定期巡检那些频繁加列的表，必要时执行ALTER TABLE ... FORCE或OPTIMIZE TABLE整理一次。把INSTANT DDL当成“可以频繁用，但不能无限用”的工具，会稳妥很多。
5.2 临时目录决定了大表DDL的生死
8.0执行ALGORITHM=COPY或部分INPLACE重建时，会在tmpdir下生成临时文件。很多DBA都知道临时表会用到tmpdir，但忽略了在线DDL也一样依赖这个目录。你在生产环境跑一个大表ALTER，如果tmpdir所在分区空间不足，DDL会直接报磁盘满，甚至把整个实例的写入拖垮。
我帮别人排查过一个真实事故：某系统在给一张快上亿行的表加索引，执行到一半报错“No space left on device”，但业务库所在的数据盘明明还剩很多空间，最后才发现问题出在系统盘/tmpdir上。当时的tmpdir目录就在根分区，根分区剩余空间本身就不多，一个重建操作直接把它写满了。对策归纳起来就是三条：tmpdir单独挂载到有足够空间的数据盘，别放系统盘也别放内存盘；执行大DDL前检查磁盘水位；给DDL设置合理的锁等待超时时间，避免它无限期卡住。
5.3 在线DDL照样会被MDL锁卡死
“在线DDL”这个名字很容易让人误以为它完全不影响业务，实际上8.0的DDL在整个执行过程中还是需要获取元数据锁（MDL），只是持有时间和锁粒度比5.7优化了不少。真正卡死系统的场景经常是这样：某个长事务占着表的MDL读锁，然后你启动了一个ALTER，ALTER排队等写锁，结果后续所有对该表的DML也全部排队，最后整个连接池被打满，应用瞬间雪崩。
这个故障链条非常典型，而且特别难排查，因为表面上看“ALTER没跑完”只是慢，实际是“整个表不可用”。如果执行DDL之前不检查是否有长事务或锁等待，生产事故基本就是时间问题。我现在每次执行DDL前，都会先查information_schema.innodb_trx和sys.schema_table_lock_waits，确认没有长事务和锁链了再动手。特别是那种业务高峰期有人开了事务没提交的情况，DDL一排队，后续所有查询都得跟着陪葬。
另外说一个容易被忽略的细节：8.0的在线DDL在复制环境中，主库执行完很快，但从库应用DDL时同样要拿元数据锁，如果从库上有正在执行的长查询，从库的DDL一样会卡住，进而拖垮从库的复制线程。升级到8.0后，很多人只盯着主库的DDL表现，忘了检查从库的锁等待，这也是一种“新暴露的坑”。
最后补一点个人体会：从5.7迁到8.0，最大的障碍其实不是文档差，而是你脑子里那套“老经验”太根深蒂固。我现在的习惯是每升一个版本，先把配置文件里所有参数对照官方文档过一遍，再重点检查脚本里写死的文件路径和目录名，最后才是跑业务SQL验证。MySQL 8.x已经是绕不开的事实标准了，与其等它在生产环境给你上一课，不如提前把这篇里提到的这些坑，当成升级前的体检清单，一项一项过一遍。
