自建mysql迁移到阿里云polardb（mysql版）本质是架构底座替换，最常出问题的是连接池配置、事务行为差异、锁机制变化及监控盲区；需重调连接池参数、校验事务隔离级别、启用sql洞察与performance_schema、改用物理备份或适配导入方式，并警惕计算节点无状态导致的会话丢失。
直接说结论：自建 MySQL 迁移到阿里云 PolarDB（MySQL 版）不是“换数据库”，而是换架构底座，**最常翻车的不是 SQL 兼容性，而是连接池、事务行为、锁机制和监控盲区**。
连接池配置必须重调，不能照搬自建参数
自建 MySQL 常用的 maxActive（如 Druid 的 50）、minIdle、maxWait 等值，在 PolarDB 上容易引发连接堆积或空闲超时。PolarDB 的连接管理更激进，尤其在高并发短连接场景下：
- PolarDB 默认连接空闲超时是
wait_timeout=300秒（自建常设为 28800），客户端若未主动 close 或 keep-alive，连接会被服务端断开，应用层报MySQLNonTransientConnectionException: No operations allowed after connection closed - 推荐将连接池
maxIdle设为minIdle的 1.2–1.5 倍，避免连接池频繁创建/销毁；timeBetweenEvictionRunsMillis调小至 30000（30 秒），配合minEvictableIdleTimeMillis=60000主动清理陈旧连接 - 务必开启
testOnBorrow=true+validationQuery=SELECT 1，否则连接复用时可能拿到已失效连接
事务隔离级别默认不同，READ-COMMITTED 不等于“安全”
自建 MySQL 5.7+ 默认是 REPEATABLE-READ，而 PolarDB MySQL 版（8.0 兼容版）默认仍是 REPEATABLE-READ，但底层存储引擎（X-Engine）对 MVCC 的实现与 InnoDB 有细微差异，尤其在长事务 + 高频更新场景下：
- 如果应用依赖
REPEATABLE-READ下的“快照读不阻塞写”，需确认业务逻辑是否隐含“同一事务内多次读取结果必须严格一致”的假设——PolarDB 的一致性快照点可能因只读节点延迟而略滞后 - 不要盲目降级为
READ-COMMITTED来“规避幻读”，PolarDB 在该级别下仍可能因并行复制延迟导致从库读到非预期中间状态 - 建议在迁移前用
SELECT @@tx_isolation和SHOW VARIABLES LIKE 'transaction_isolation'校验实际生效值，而非仅看配置文件
慢查询日志和性能洞察必须切换采集方式
自建 MySQL 通常靠 slow_query_log=ON + long_query_time=1 写本地文件，但在 PolarDB 上这条路走不通：
- PolarDB 不开放
slow_query_log_file路径写入权限，开启slow_query_log后日志只进审计系统，且默认不包含执行计划（log_output=TABLE无效） - 正确做法是：在控制台开通「SQL洞察」功能，并设置采样率（推荐 100% 初期），它能捕获
EXPLAIN FORMAT=JSON级别的完整执行上下文，包括实际扫描行数、临时表使用、是否走索引合并等 - 特别注意：PolarDB 的
performance_schema默认关闭，若需实时监控语句等待事件（如wait/io/file/innodb/innodb_data_file），需手动在参数模板中启用performance_schema=ON并重启节点
备份恢复链路要重新验证，不能依赖 mysqldump
自建环境常用 mysqldump --single-transaction 做逻辑备份，但迁到 PolarDB 后会遇到两个硬伤：
-
mysqldump导出的 SQL 文件在 PolarDB 上导入时，若含大量INSERT ... VALUES (...),(...),(...)批量插入，默认会触发单条语句限流（max_statement_time），导致导入卡住或超时；应改用mysqlimport或 PolarDB 控制台的「物理备份恢复」功能 - PolarDB 的全局事务 ID（GTID）模式与自建 GTID 不完全兼容，跨版本迁移（如自建 5.7 → PolarDB 8.0）时，DTS 任务若选「结构+全量+增量」，必须确保源库
gtid_mode=ON且enforce_gtid_consistency=ON，否则增量同步会中断并报GTID set mismatch - 切记：PolarDB 的「克隆实例」功能虽快，但克隆的是某个时间点的物理快照，不包含克隆时刻之后的 binlog，无法用于持续增量同步场景
真正容易被忽略的，是 PolarDB 的「计算节点无状态」特性——所有连接、会话变量、临时表都绑定在当前计算节点上，一旦发生主备切换或自动扩缩容，这些上下文就丢了。别指望 SET @var := 1 能跨请求生效，也别把临时表当缓存用。
