从MySQL 5.7迁到8.0那晚，我亲手删掉了自己的管理员账号

上周把跑了三年的站从MySQL 5.7往8.0搬，本来觉得"小版本升级能有多大事"，结果凌晨两点我在机房差点给自己一巴掌。不是数据丢了，是升级脚本里顺手写了个 `DROP USER 'admin'@'%'`，理由是"清理旧权限"——结果那个admin是我CMS后台用的独立只读账号，删完前台能跑，后台登录直接炸锅。

这事给我上了一课：迁移时的用户权限不是"顺便清理"，得单独开一张表做对照。我现在养了个习惯，任何涉及账号、表结构、存储过程的变更，必须先在Excel里列三列：旧环境对象名、新环境对应名、是否保留。别信脑子，凌晨两点的脑子不配信。

还有建表时的字符集陷阱。5.7里默认 `utf8mb4` 是新表标配，但老项目里混着一堆 `utf8`（那个阉割版三字节的）。迁移时我用 `mysqldump` 导出来直接灌，新库看着一切正常，直到有用户昵称带了生僻字——"𠮷"这种，直接变问号。后来才懂，导数据前先 `SHOW CREATE TABLE` 扫一遍，把旧表的 `utf8` 显式改成 `utf8mb4`，比事后修数据省事一百倍。

再说说卸载插件时的阴间操作。有个第三方论坛插件用了半年不想续了，后台点卸载，提示"清理完成"。结果数据库里留了七张孤儿表，前缀还带着插件标识，更绝的是其中一张做了外键关联，半年后我删另一张业务表时直接触发约束报错，报错信息还指错了表名，追了二十分钟才发现是这货埋的雷。

现在我给团队定了条规矩：插件卸载必须走验收清单，至少检查 `information_schema.TABLES` 里有没有残留、有没有触发器、有没有事件调度器里的定时任务。CMS后台那个"卸载"按钮很多时候只是删了前端菜单，数据库层面它根本不管，或者说它"以为"自己管了。

最后说个CDN+OSS迁移的教训。图片域名从七牛切到阿里云OSS，为了无缝切换，我先把新 bucket 建好、权限开完，然后打算让两边同时跑一周再切DNS。结果漏了一步：新 bucket 的回源地址填成了旧 bucket 的内网域名，测试时因为本地hosts指向新域名，看起来图片都能加载。等真切了DNS，外网用户全404，因为OSS内网域名从公网根本解析不通。回滚DNS要十分钟生效，那十分钟我在监控群里装死。

现在每次迁移，不管大小，我强制自己写个《回滚剧本》：哪一步出错、怎么验证、怎么回退、联系谁。不是怕技术搞不定，是怕凌晨两点脑子短路时，连 `iptables -L` 和 `iptables -S` 都能看错。

你们迁移时有没有删错过什么东西？我这边还有次把生产库的 `test_` 前缀表当成测试环境给 `DROP` 了的，但那又是另一个故事了……