OpenDBWorks

MySQL

MySQL 设计 · 高可用 · 调优 · 升级

MySQL 是 Web、电商与企业内部系统的标准 RDBMS。我们提供基于 InnoDB Cluster 与 ProxySQL 的高可用、基于 binlog 的时间点恢复、慢查询调优，以及 8.0 停止支持后向 8.4 LTS 的迁移。

MySQL 咨询8.4 LTS 升级

Architecture

推荐的高可用架构

根据需求，在官方 InnoDB Cluster（Group Replication + MySQL Router + MySQL Shell）与 异步复制 + ProxySQL 之间选择。

InnoDB Cluster 通过 Group Replication 以共识（法定人数）方式复制事务，主节点故障时自动选出新主。MySQL Router 将应用连接路由到当前主节点与从节点。

ProxySQL 提供基于规则的读写分离、连接复用、查询缓存与拦截规则，常用于大流量环境。

  • Group Replication 建议至少 3 个（奇数）成员
  • 默认使用单主模式，多主模式需评估冲突特性
  • 灾备通过 InnoDB ClusterSet 或异步复制建立异地站点
  • Aurora 等托管服务在其功能范围内设计
图：MySQL InnoDB Cluster 参考架构（Router 与 ProxySQL 可二选一或并用）

Scope

MySQL 服务范围

安装与设计

LTS/Innovation 版本选择、字符集与排序规则标准、InnoDB 文件与日志布局、账户标准。

高可用与复制

基于 GTID 的异步/半同步复制、Group Replication、InnoDB Cluster/ClusterSet、ProxySQL。

备份与 PITR

Percona XtraBackup 物理备份、MySQL Shell 导出工具、基于 binlog 的时间点恢复。

调优

缓冲池、redo 日志与刷盘设置，慢查询与执行计划，索引与分区。

监控

PMM、Performance Schema 与 sys 库、复制延迟与锁等待、Grafana 告警。

升级

用 MySQL Shell Upgrade Checker 预检查，8.0 → 8.4 LTS 滚动升级。

安全

caching_sha2_password、基于角色的权限、TLS、审计日志、密码策略。

迁移

Oracle、Tibero 或其他 MySQL 系 → MySQL；本地 ↔ 云（Aurora/RDS 等）。

Replication

高可用方式比较

MySQL 复制与高可用选项
方式特点适用场景注意事项
异步复制（GTID）副本应用源库 binlog读扩展、灾备、简单架构故障时可能丢数据 → 考虑半同步
半同步复制至少一个副本确认接收后才返回提交改善 RPO网络延迟影响写响应
Group Replication / InnoDB Cluster共识复制 + 自动故障切换 + Router生产高可用标准需评估大事务与写冲突
ProxySQL查询路由、读写分离、连接复用大流量、读扩展需设计路由规则与健康检查

Backup & PITR

备份与时间点恢复

先用物理备份快速还原，再应用 binlog 回到所需时间点。

XtraBackup 全量备份与恢复准备
# 备份（在线、非阻塞物理备份）
xtrabackup --backup --target-dir=/backup/full_20261020 \
           --user=bkuser --password='***'
# 恢复前准备（prepare）
xtrabackup --prepare --target-dir=/backup/full_20261020
# 复制回空的数据目录并设置属主
xtrabackup --copy-back --target-dir=/backup/full_20261020
chown -R mysql:mysql /var/lib/mysql
用 binlog 应用到目标时间
# 从 xtrabackup_binlog_info 中的位置重放到事故发生前
mysqlbinlog --start-position=157 \
            --stop-datetime="2026-10-20 13:55:00" \
            binlog.000123 binlog.000124 | mysql -u root -p
XtraBackup 需与 MySQL 版本匹配（如 MySQL 8.4 使用 XtraBackup 8.4）。文件名与位置为示例。

Tuning

性能调优要点

InnoDB 与服务器

  • innodb_buffer_pool_size 与实例数对比工作集
  • redo 日志容量（innodb_redo_log_capacity）与刷盘方式
  • max_connections 与线程/连接池策略
  • 避免过大的临时表与排序缓冲
  • 并行复制应用（replica_parallel_workers）

查询与结构

  • 用慢查询日志 + pt-query-digest / PMM Query Analytics 选出重点查询
  • 用 EXPLAIN ANALYZE 确认实际执行路径
  • 复合索引列顺序与覆盖索引
  • 大型日志类表的分区与保留策略
  • 锁等待与死锁分析（performance_schema、sys 库）

Upgrade

MySQL 8.0 → 8.4 LTS 升级

Oracle 已公告 MySQL 8.0 于 2026 年 4 月 EOL（转入 Sustaining Support）。建议有计划地迁移到 8.4 LTS（或 9.7 LTS）。

  1. 预检查

    MySQL Shell util.checkForServerUpgrade()、mysqlcheck --check-upgrade

  2. 兼容性整理

    处理 mysql_native_password 账户、新保留字、已移除的变量与选项

  3. 预发验证

    用生产副本进行升级、回归测试与性能对比

  4. 滚动切换

    先升级副本 → 主动切换 → 升级原主库

不能从 8.0 直接升级到 9.x，必须经过 8.4 LTS。不支持降级，升级前必须备份。（来源：MySQL 8.4 Reference Manual、MySQL EOL 公告 —— 实施前请确认最新文档）

Migration

Oracle · Tibero → MySQL 迁移

  • 数据类型、字符集（utf8mb4）与排序规则映射
  • 序列 → AUTO_INCREMENT 或序列表设计
  • PL/SQL 包 → 存储过程或迁移到应用逻辑
  • 确定全量加载 + 增量同步方案
  • 比对行数、校验和与业务查询结果
  • 切换演练与回滚计划
迁移上云时，还会评估目标服务迁移工具（如 AWS DMS 等）的支持范围。

FAQ

常见问题

还能继续使用 MySQL 8.0 吗？

2026 年 4 月后 8.0 处于不再提供新补丁的 Sustaining Support 阶段。若要继续获得安全与缺陷修复，应规划迁移到 8.4 LTS 等受支持版本。

InnoDB Cluster 和 ProxySQL 选哪个？

以自动故障切换为核心时，InnoDB Cluster（+Router）是标准方案；需要精细的查询路由或连接复用时，可与 ProxySQL 并用或单独使用 ProxySQL。

支持 Aurora MySQL 吗？

支持。会结合托管服务特性（参数组、存储架构、可用功能）进行调优、监控与迁移。

慢查询调优需要多长时间？

取决于目标查询数量与可变更范围（仅索引/改写 SQL/修改结构）。诊断后我们会给出优先级与预计范围。

从现状开始，一起检查您的云与数据库？

告诉我们您使用的云、数据库版本、架构与困扰，我们将提出评估范围与实施方式。

咨询khy061473@gmail.com