MySQL 8.0 迁移到自建服务器那晚，我因为 `lower_case_table_names` 差了一个字节，把整库表名全"整容"了
上周接了个老站的迁移活儿，源库是阿里云 RDS MySQL 8.0，目标机是我宝塔面板新开的 8.0.36。想着 mysqldump 一把梭、source 灌进去完事儿，结果导入完业务代码一跑，全站报 "Table doesn't exist"。
我人都傻了。表明明在啊，show tables 看得清清楚楚。折腾了四十分钟才反应过来——源库 `lower_case_table_names=1`（表名存为小写），目标机我编译安装时没管这个，默认走了 `0`（区分大小写）。代码里写的 `UserOrder`，库里实际叫 `userorder`，Linux 下直接翻脸不认。
更绝的是我想改配置重启，MySQL 8.0 这参数初始化完就不让动了，改 my.cnf 直接起不来，报错说得拿 `--initialize` 重头来。凌晨两点我盯着那堆数据，冷汗是真的有。
最后只能曲线救国：导出时加 `--set-gtid-purged=OFF`，重新初始化实例指定 `--lower-case-table-names=1`，再导一遍。前后多耗了三个钟头，业务停到早上六点。
说几个我这次用血换的迁移 checklist，你们直接抄：
一、建表阶段就把"大小写"钉死
别信什么"Linux 规范就是区分大小写"。业务代码一旦跨平台（开发机 Windows、线上 Linux、还有我这种混合云迁移），`lower_case_table_names` 不一致就是定时炸弹。我的做法现在是：所有新实例统一设 1，表名全小写加下划线，代码里 ORM 也强制转小写匹配。宁可丑一点，不要半夜哭。
二、dump 参数别偷懒，一行错全盘输
我以前图省事就 `mysqldump -u root -p db > db.sql`，这次吃了大亏。现在我的标准命令是：
`mysqldump --single-transaction --quick --set-gtid-purged=OFF --triggers --routines --events -u root -p db > db.sql`
尤其 `--set-gtid-purged=OFF`，MySQL 8.0 默认开 GTID，跨实例导入时 GTID 不一致直接给你拦外面。还有事件和存储过程，漏了这俩，定时任务全灭，你还得一个个手动重建。
三、升级场景：字符集和排序规则是隐形刺客
5.7 升 8.0 我遇到过 `utf8mb4_0900_ai_ci` 和 `utf8mb4_general_ci` 混用，连表查询直接炸。迁移前务必 `SHOW VARIABLES LIKE 'character_set%';` 和 `SHOW VARIABLES LIKE 'collation%';` 两边对比，不一致的先统一。
我的土办法：导出前在源库跑一遍 `ALTER DATABASE db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;` 把库级别钉死，表跟着改。虽然粗暴，但比迁移后联调时发现某个字段排序规则不对、索引失效强一百倍。
四、卸载/回滚：binlog 和备份是最后底裤
这次迁移我搞了个骚操作——目标机导入完觉得不对，直接删库准备重来。结果源库那边业务还在跑，新产生的数据我没二次同步，差点丢了两个小时订单。
现在我的规矩：任何迁移先开 `log-bin`，做完第一步全量 dump 后，记下当时的 `master status` 或者 `gtid_executed`。万一要回滚或者增量追平，有 binlog 位点才能精准续命。别信"我就试一下"，试试就逝世。
五、宝塔面板用户额外注意：一键安装的数据库可能"缺配置"
宝塔装 MySQL 8.0 是编译好的，但 `my.cnf` 模板里有些关键参数没放开。我这次就是吃了这个亏——`lower_case_table_names` 在宝塔默认配置里被注释掉了，我没检查，它走了系统默认值。
建议装完先 `mysqld --verbose --help | grep lower-case-table-names` 确认实际生效值，别只看配置文件。还有 `innodb_buffer_pool_size`，宝塔默认给得偏保守，大库迁移时临时调大能省一半时间。
迁移这活儿，表面是导数据，实际是打信息差——你不知道两个环境哪里藏着不一致，它就在最不该出现的时候给你一刀。我现在每次迁移前都拉个 Excel，两边实例参数逐行对比，宁可事前啰嗦十分钟，不要事后通宵到天明。
你们迁移时踩过什么奇葩坑？我这次算是被大小写上了一课，下次可能轮到时区或者 sql_mode 了。
