迁移后延迟不飙升的关键是网络链路对齐：应用与rds必须同vpc内，且仅使用内网域名访问；跨vpc时优先选vpc对等连接而非公网中转。
怎么让迁移后延迟不飙升
迁移后查询变慢、连接超时，大概率不是RDS性能差，而是网络链路没对齐。RDS本身延迟本就比本地高，但只要控制在1ms内，业务几乎无感。
关键动作只有两步：把应用服务器和RDS放在同一个VPC里；禁用公网地址，只用内网域名访问。跨VPC或走公网时，ping rds-instance-endpoint 常常超过10ms，SELECT 1 就可能卡住200ms以上。
- 别用“公网连接测试”代替真实链路验证——哪怕控制台能连上，应用实际走的可能是NAT或代理路径
- 如果必须跨VPC（比如旧系统在经典网络），优先走云厂商提供的VPC对等连接，而不是SLB或公网中转
- 检查应用配置里的数据库地址：确认是
rm-xxx.mysql.rds.aliyuncs.com这类内网域名，不是带public或proxy字样的地址
为什么mysqldump导入后还是慢
mysqldump 导出再导入看似简单，但默认参数会让RDS承受远超预期的写压力，尤其在通用型SSD盘上容易触发IOPS限速，导致后续查询排队。
真正有效的做法是关掉自动提交、禁用唯一性校验、调低并发写入节奏：
- 导出时加
--single-transaction --skip-triggers --no-autocommit，避免长事务锁表 - 导入前在RDS上执行
SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;，完事后恢复 - 大库拆成单表导入，用
mysql -h <code>rds-endpoint-u user -p db_name 逐个跑，别用管道直连 - 导入期间关闭RDS的备份任务和SQL审计，减少后台干扰
DTS增量同步卡在“正在追平”不动了
这不是DTS坏了，而是源库binlog被清理或目标库写入瓶颈卡住了。DTS依赖源库的binlog position持续推进，一旦position断档，就会停在“正在追平”状态，且不报错。
先查源库：SHOW MASTER STATUS 看当前binlog文件和position；再查DTS任务详情页里的“已拉取到的binlog位置”，两者不一致就说明源库binlog被删了。
- 源库必须设置
expire_logs_days = 7（至少保留7天），不能依赖默认的0或1天 - 如果DTS显示“目标写入QPS过低”，检查RDS的
innodb_buffer_pool_size是否设得太小（低于内存50%），会导致刷脏页慢 - 别在增量同步阶段执行
ALTER TABLE或大批量DELETE，这类操作会产生巨量binlog，拖慢追平速度
RDS连接池配置不当反而加重延迟
很多团队直接把自建MySQL的Druid/HikariCP配置照搬过去，结果连接数暴涨、TIME_WAIT堆积、甚至触发RDS的 max_connections 限制，新请求排队等连接释放。
RDS的连接管理更敏感，必须按实际并发压测结果调参，不是越大越好：
-
maxActive（Druid）或maximumPoolSize（HikariCP）建议设为应用峰值QPS × 0.8，而不是盲目设成200+ -
minIdle和minimumIdle设为5~10即可，空闲连接太多会占用RDS连接数配额 - 务必开启
testWhileIdle=true+timeBetweenEvictionRunsMillis=30000，及时剔除失效连接，避免拿到底层已断开的socket - 如果RDS开启了透明连接池（如阿里云RDS Proxy），应用侧连接池最大值应下调30%，否则Proxy起不到复用作用
