迁移后需验证数据完整、功能正常、性能稳定：1. 核对表数量、行数，检查主外键、索引、字符集及时区一致性；2. 测试SQL语法兼容性，确保视图、存储过程、触发器正常运行；3. 验证应用连接配置及核心业务流程；4. 对比迁移前后查询性能，监控执行计划与系统负载，建议预发验证后灰度上线。
迁移MySQL后验证应用兼容性，核心是确保数据完整、功能正常、性能稳定。重点检查字符集、SQL语法、存储过程、连接方式等变化是否影响现有业务。
检查数据完整性与一致性
迁移完成后第一件事是核对数据是否完整无误：
- • 对比源库和目标库的表数量、行数，使用
COUNT(*)
抽查关键业务表。 • 验证主键、外键、索引是否存在且正确，特别是联合索引顺序。 • 检查特殊字段如
TEXT
、
BLOB
、时间戳是否正确转换，时区设置是否一致。 • 确认字符集（如utf8mb4）和排序规则（collation）与原库一致，避免中文乱码或排序异常。
验证SQL语法与数据库特性兼容性
不同MySQL版本或迁移到其他数据库（如MariaDB、TiDB）可能存在语法差异：
- • 运行应用中的典型SQL语句，关注
GROUP BY
、
ORDER BY
、子查询是否报错。 • 检查是否使用了已弃用的函数或语法，例如旧版的
JOIN
写法。 • 验证视图、触发器、存储过程能否正常调用，参数传递是否正确。 • 如果启用了严格模式（strict mode），确认INSERT/UPDATE不会因截断等问题失败。
测试应用连接与运行时行为
应用连接数据库的方式可能受迁移影响：
- • 更新连接字符串中的主机、端口、用户名密码后，测试能否成功建立连接。 • 使用连接池的应用要观察是否有连接泄漏或认证失败。 • 跑一遍核心业务流程：登录、查询、下单、支付等，看是否有超时或异常。 • 检查日志中是否有SQL错误、警告或性能退化提示。
进行性能基准对比
即使功能正常，性能下降也会影响用户体验：
- • 对比关键查询在迁移前后的执行时间，查看执行计划是否改变。 • 检查索引是否被正确使用，有无全表扫描出现。 • 在测试环境模拟生产流量，观察CPU、内存、I/O负载情况。 • 确认慢查询日志配置开启，并监控是否有新增慢语句。
基本上就这些。迁移后别急着切流量，先在测试或预发环境走通全流程，再灰度上线更稳妥。
mysql 端口 中文乱码 sql语句 sql mysql count 字符串 严格模式 数据库 mariadb tidb