MySQL表结构迁移翻车现场：我亲历的字符集连环坑

昨天帮朋友迁移Discuz论坛数据，本以为简单的mysqldump导入导出，结果在字符集上栽了大跟头。原库用latin1存了十年中文数据，新服务器默认utf8mb4，导进去直接乱码狂欢。

血泪教训1：一定要用--hex-blob导出二进制字段。当时没加这个参数，用户头像blob字段全变成问号，被迫连夜用16进制编辑器抢救。

更坑的是编码转换：先用iconv转存sql文件，发现auto_increment值丢失；后来改在MySQL层用convert()函数，结果索引全部失效。最终方案是建临时库中转，先按原字符集导入再alter table转码，虽然多花两小时但保住了数据。

建议各位站长迁移前务必确认三件事：1. 用SHOW CREATE TABLE核对原表结构 2. 测试环境先跑完整流程 3. 备好phpMyAdmin和命令行双通道。现在看着那个被字符集折磨到凌晨三点的黑眼圈，终于理解为什么老司机都说"编码不规范，运维两行泪"。