MySQL 迁移到云平台不是简单地把数据 dump 出来再 load 进去，核心难点在迁移过程中的**一致性保障、延迟控制、权限适配和云环境特有性能瓶颈**。直接用
mysqldump+
mysql在中大型库上极易失败或导致业务中断超时。
如何避免主从延迟爆炸式增长（尤其在 RDS 或 PolarDB 等托管服务中）
云数据库默认开启 binlog 且多数强制 ROW 格式，但迁移工具若未适配，会触发大量无主键表的全表扫描写入，瞬间拉高复制延迟。RDS 的只读实例延迟超过 30 秒可能被自动踢出集群。
迁移前必须检查所有表是否有主键或唯一非空索引，SELECT table_schema, table_name FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys') AND table_name NOT IN (SELECT table_name FROM information_schema.key_column_usage WHERE constraint_name = 'PRIMARY' GROUP BY table_name);
使用 mydumper替代
mysqldump，它支持多线程导出+按 chunk 分片，对大表更友好；导入端用
myloader并设置
--threads=8 --enable-binlog若用 DTS（如阿里云 DTS、AWS DMS），务必关闭「结构迁移后立即启动数据同步」选项，先停写、导结构、再启同步，否则增量日志堆积无法追赶
为什么迁到云上后 GROUP BY
变慢，且 tmp_table_size
调整无效
云平台 MySQL 实例（如 AWS RDS、腾讯云 CDB）的临时表默认走磁盘而非内存，即使你调大了
tmp_table_size和
max_heap_table_size，只要查询涉及
TEXT/
BLOB字段或排序字段长度超阈值，仍会强制落盘 —— 而云磁盘 IOPS 是受限的。 检查执行计划：如果
Extra列出现
Using temporary; Using filesort，基本确认走磁盘临时表 用
SHOW VARIABLES LIKE '%tmp%';确认实际生效值（RDS 中部分变量只读，需通过参数模板修改） 更治本的方法是重写 SQL：用子查询提前过滤、加覆盖索引避免排序，或拆分
GROUP BY字段为整型 ID 关联维度表
迁移后连接池频繁报 Lost connection to MySQL server during query
这不是网络问题，而是云平台安全组 + 数据库内核双重超时叠加的结果。典型路径：应用层 wait_timeout=28800 → 云防火墙空闲连接 5 分钟断连 → 内核 net.ipv4.tcp_fin_timeout=60 → 客户端收到 RST 后未重试就复用旧连接。
在 RDS 参数组中将wait_timeout和
interactive_timeout统一设为 300（5 分钟），与安全组空闲超时对齐 客户端连接池（如 HikariCP）必须启用
connection-test-query=SELECT 1和
validation-timeout=3000，禁用
test-while-idle=false禁止在代码里手动
conn.close()后还持有 Connection 对象引用，云环境连接释放更敏感
SET GLOBAL wait_timeout = 300; SET GLOBAL interactive_timeout = 300;
云上 MySQL 的“优化”本质是接受它的约束边界，而不是对抗它。最常被忽略的是：云存储的随机 IOPS 不等于本地 SSD，任何依赖
ORDER BY RAND()或未命中索引的
LIMIT OFFSET分页，在百万级数据下都会让实例 CPU 拉满——这时候加索引比调参管用十倍。
