移动云数据库，照搬自建MySQL容易踩坑

把自建那套配置原封不动搬到移动云数据库上，SQL 语句基本不用改，出问题的全是语法之外的东西。托管产品把操作系统、备份、监控这些活儿接了过去，代价是你得按它的规矩来。配置文件改不了、root 账号不能随便用、定时备份脚本可能根本跑不起来——这些在迁移前都不显眼，上线之后一个接一个冒出来。

移动云数据库把运维接走了，规矩也跟着来了

自建的时候习惯性 vi /etc/my.cnf，云上没这回事。参数要么走控制台，要么用参数模板批量套，还有一批是锁死的、改了要重启才生效的。所以迁移第一步不是导数据，是把现在实例的参数导出来列成清单，一项项对照：哪些能改、哪些改了要重启、哪些压根不给改。不确定就看控制台说明和官方文档，别信论坛里几年前的帖子，产品迭代快，那些结论早过期了。

还有一个容易忽略的：自建时自己装的插件、自定义函数、甚至某些存储引擎，托管环境不一定支持。导之前先把这些东西清一遍，不然导入到一半报错，回滚都麻烦。

root 账号那一套，搬过去就是找麻烦

自建时 root@localhost 通吃一切，代码里写死 root 的连接串也不少见。云上通常给一个高权限账号，但主机白名单、访问来源、SUPER 这类权限是分开管的。把业务代码原样搬过去，要么连不上，要么被安全策略拦下来。正常做法是建业务专用账号，只授权它需要的库和增删改查权限，连接来源写成具体网段而不是 %。视图和存储过程里还有 DEFINER 的问题，跨账号导入时会报 definer 不存在，导之前统一改成 INVOKER，或者先把对应账号建好。

参数照抄，内存先炸

innodb_buffer_pool_size 在自建机上按物理内存的六七成给，云上规格是套餐，你按老比例算完，系统自己还得留一份，结果就是内存吃紧。max_connections 抄个两千上去看着气派，可每个连接都占内存，规格小的时候一压就出问题。wait_timeout 自建设成八小时，云上中间还隔着代理或负载均衡，长时间空闲的连接被中间层掐掉，应用侧报 MySQL server has gone away，查半天以为是网络。这些都得按实际规格和链路重算。

备份做了，不等于能恢复

自建时 mysqldump 定时跑，脚本自己写自己改。托管产品一般带自动备份，但备份策略、保留天数、能不能按时间点恢复、能不能恢复到新实例，这几项得逐个确认清楚。binlog 保留多久尤其关键，想做时间点恢复，binlog 得在。最要紧的一条是找个测试实例真恢复一次——备份文件躺在那儿不算数，恢复出来数据对得上才算。

字符集、时区、大小写，迁完才炸的三个小事

字符集，自建库可能是 utf8，实际是 utf8mb3，云上默认 utf8mb4，导过去排序规则不一致，两张表 join 就报 illegal mix of collations。时区，应用端和数据库端对不上，时间字段差几个小时，报表全歪，还查不出原因。lower_case_table_names 更麻烦，Linux 上一般是 0，从 Windows 迁过来的表名大小写不一致，直接就找不到表，而这个参数不少实例创建后改不了，只能在建库前定死。这类小事最好在预演环境全跑一遍。

迁移节奏，别一步切过去

稳妥的路子就那几步：先全量导入，再开 binlog 同步增量，业务先只读切过去跑一段，盯慢查询、连接数、复制延迟，没问题再灰度写，最后全量切，中间留个能回滚的窗口。别赶在业务高峰或者快下班的时候动手，出问题没人扛，第二天一早才发现就更被动。

连不上先看白名单和网络

云数据库基本都要配白名单。应用服务器出口 IP 变了、容器重启换了地址、走 NAT 网关出去的公网 IP 和你以为的不是一个，都会连不上。报错往往是超时而不是拒绝连接，很容易误判成数据库挂了。先在实例上看连接来源，再回头核对白名单。能走内网就走内网，公网访问能不开就不开，省事也省风险。

监控和慢日志，托管不等于不用管

控制台有现成指标，但默认面板是给通用场景看的。CPU、连接数、磁盘、慢查询这些得自己配告警阈值，不然等到有人反馈卡了才知道。slow_query_log 该开，long_query_time 按业务实际来定，别用默认那个十秒——真看到十秒的慢查询，业务那边早就喊起来了。performance_schema 会吃点资源，但排查问题时确实有用。

落到执行上其实就几条：参数清单对着官方文档逐条过，业务账号不用 root，备份真恢复一次，字符集时区和大小写在建库前定死，迁移按只读、灰度、全切三段走，白名单和告警上线前配好。托管省掉的是运维体力活，判断力这块还得自己扛。至于具体规格参数和功能边界，以服务商控制台和官方页面说明为准，别拿别人的配置单直接套。