MySQL迁云核心难点是一致性保障、延迟控制、权限适配和云性能瓶颈；需检查主键、用mydumper/myloader或DTS分步同步；GROUP BY变慢因云临时表强制落盘，应重写SQL；连接丢失因超时叠加，须对齐wait_timeout与安全组并启用连接池校验。
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 拉满——这时候加索引比调参管用十倍。
