MySQL 实战与高可用 · 知识图谱总览

基于第 109 ~ 130 讲整理 · 四大调优案例 · 主从复制 · MHA 高可用 · 分库分表

SQL 调优实战案例(109 ~ 120 讲) 主从复制与读写分离(118 ~ 124 讲) 高可用故障转移(125 ~ 127 讲) 分库分表实战(128 ~ 130 讲) 课程脉络 · 第 109 ~ 130 讲 调优榨干单机后 数据一致才敢切 量级再涨 · 拆库拆表 单机版 MySQL 只适合开发与测试环境 生产级 MySQL 架构四件套 主从复制 → 读写分离 → 高可用 → 分库分表 SQL 调优实战案例贯穿其中 支撑亿级业务 不宕机 · 不丢数据 · 查得快 ① 半连接优化翻车 IN 子查询被改写 semi join → 全表扫描 show warnings 定位 · 改写 SQL 破局 ② 优化器选错索引 弃二级索引扫聚簇索引 → 亿级全扫 force index 强制走索引 ③ 深分页性能陷阱 几十万次回表 + filesort 磁盘排序 子查询先查 id → 只回表 20 次 ④ 删除引发慢查询 长事务删千万数据 · 删除标记被反复扫 kill 长事务 · 大批量清理放凌晨 为什么搭主从 高可用先决条件 · 读写分离基础 复制原理 binlog → IO 线程 → relay log → SQL 线程回放 三种搭建方式 异步 · 半同步(5.7 默认 AFTER_SYNC)· GTID 主从延迟治理 pt-heartbeat 监控 · 并行复制 · 强制读主 MHA 架构 Manager 单独部署 · Node 装每台 MySQL perl 编写 · 秒级探测 故障转移 Master 宕机 → VIP 漂移 → Slave 升主 check_ssh / check_repl 预检 单表多大要拆? 别超 1000 万 · 最好 100 ~ 500 万 用户表水平拆分 userid hash → 100 表 2 库 · 索引映射表 订单表三维度 orderid 主体 · userid 映射 · ES 搜索 跨库分页怎么办 映射表分页 · 拒绝内存拉全量 第 109 ~ 111 讲 案例一 运营系统 · semi join 第 112 ~ 114 讲 案例二 商品系统 · force index 第 115 讲 案例三 评论系统 · 深分页 第 116~117+120 讲 案例四 删除慢查询 · profiling 第 118 ~ 127 讲 主从复制 · 读写分离 MHA 高可用 第 128 ~ 130 讲 分库分表 用户表 · 订单表 · 跨库分页 图例 调优实战 主从 / 正确做法 高可用机制 分库分表 演进方向

四大调优案例(点击跳转)

  • • 案例一 / 二:semi join 翻车 + force index 救场
  • • 案例三 / 四:深分页优化 + 删除长事务排查
  • • 共同方法论:看懂执行计划 → 找到慢因 → 针对性改造
  • • 没有银弹:每个案例的正确解法可能完全相反

从单机到生产架构

  • • 主从复制:binlog 流水线 · 异步/半同步/GTID · 延迟治理
  • • 读写分离:写主读从 · 一主多从 · 中间件落地
  • • 高可用是必须项,读写分离按需上

高可用与分库分表

  • • MHA:Manager + Node · VIP 漂移 · 自动升主
  • • 分库分表:单表红线 · hash 路由 · 索引映射表 · ES 兜底
  • • 跨库分页正解:映射表分页,拒绝内存拉全量