⑤ 分库分表实战：用户表、订单表与跨库分页

对应第 128 ~ 130 讲 · 单表红线 · hash 路由 · 索引映射表 · ES 兜底 · 跨库分页正解

总览 ① 案例·半连接与选错索引 ② 案例·深分页与慢查询 ③ 主从复制架构 ④ 高可用故障转移 ⑤ 分库分表实战 执行计划篇 85~108 架构与实践篇 01~20
什么时候拆？拆到多小？（128 讲） 用户表水平拆分方案（128 讲） 复杂搜索：交给 Elasticsearch（128 ~ 129 讲） 订单系统设计：三个维度（129 讲） 跨库分页怎么办（130 讲） 定了拆分粒度 映射表补齐路由 为什么拆 单表太大 → 索引树高 · 内存缓存页少 · 查询速度暴跌 单表数据量红线 别超 1000 万 · 最好 100 ~ 500 万 · 几十万最佳（建好索引） 数据量经验值 1 亿行 ≈ 1 ~ 几 GB · 存储不是瓶颈，查询性能才是 拆 100 张表 → 2 台服务器 2 个库 user_001 ~ user_100 · 每表几十万数据 路由规则 userid hash 后对表数取模 → 数据均匀分散 非 userid 查询：索引映射表 (username, userid) 映射表同样分库分表 两次查询定位：username → userid → 完整数据 场景：运营多条件组合搜索 手机号 / 住址 / 年龄 / 性别 / 职业……任意组合 分库分表后 MySQL 无法高效支持多条件查询 方案：binlog 监听 → 同步 ES 搜索字段全量同步进 ES 建搜索索引 ES 多条件搜索出 userid → 回分库分表取详情 ① 订单主体 按 orderid hash → 100~1000 表多机 每天 1w 新单 · 每年 360w 3 年必到千万级 → 必须拆 ② 用户端 (userid, orderid) 索引映射表 按 userid hash 分库分表 userid 路由查 orderid 列表（可分页） ③ 运营端 搜索条件同步进 ES ES 复杂搜索 + 分页 拿 orderid 回分库分表取详情 推荐方案 userid 路由到映射表 → 分页拿 orderid 映射表加列：order_status / 商品标题支持条件筛选 运营端直接走 ES 搜索 + 分页 坚决反对的方案 跨多库多表把数据拉到内存筛选分页 （数据库中间件本质上也是这么干） 效率极差 · 几秒级耗时 图例 拆分依据 / 经验值 推荐方案 多维度设计 反模式 / 警示 关键技巧

分库分表决策速查

  • • 单表超 1000 万就要警惕，100~500 万最佳
  • • 1 亿行 ≈ 几 GB：拆分为了查询性能，不是存储
  • • 路由：业务 id hash 后对表数取模
  • • 中间件：Sharding-Sphere 或 MyCat

订单系统的三维设计

  • • 主体按 orderid 分库分表（100~1000 张表）
  • • 用户端：(userid, orderid) 映射表按 userid 拆
  • • 运营端：搜索条件进 ES，搜出 orderid 回查
  • • 映射表可加列支撑状态筛选、标题模糊搜

分库分表万能思路

  • • 按主业务 id 分库分表，保证单实体数据落一处
  • • 其他查询维度 → 索引映射表（同样分库分表）
  • • 复杂搜索 → binlog 同步 ES 兜底
  • • 跨库分页：先映射表分页，再回表取详情

⑤ 分库分表实战 · MySQL 实战与高可用知识图谱 · 依据第 128 ~ 130 讲整理