第13节：引入分库分表路由组件

今天主要学习了分库分表

• 当前的库表结构

big_market.sql      ──→ db00 (big_market)       配置表：award、strategy、raffle_activity 等
big_market_01.sql   ──→ db01 (big_market_01)    用户数据：account + flow_000~003 + order_000~003
big_market_02.sql   ──→ db02 (big_market_02)    用户数据：同上（结构一模一样）

• 什么是分库分表

用户 userId=100  ──→  hash(100) % 8 = ?  ──→  路由到 dbXX.flow_00X
用户 userId=207  ──→  hash(207) % 8 = ?  ──→  路由到 dbYY.flow_00Y

• 为什么要分库分表

┌─────────────────────────────────────────────────────┐
│                     路由层                            │
│            userId % 8 → 决定落到哪个分片               │
├──────────────────────┬──────────────────────────────┤
│       big_market_01  │        big_market_02          │
│      ┌────────────┐  │      ┌────────────┐          │
│      │ flow_000   │  │      │ flow_000   │          │
│      │ flow_001   │  │      │ flow_001   │          │
│      │ flow_002   │  │      │ flow_002   │          │
│      │ flow_003   │  │      │ flow_003   │          │
│      └────────────┘  │      └────────────┘          │
└──────────────────────┴──────────────────────────────┘

1. 单表数据量太大 → 查询越来越慢

不分： raffle_activity_order    1 张表  1000 万行  → 查一条扫几百万行
分了： raffle_activity_order_00X 4 张表  每张 250 万行 → 定位到一张表，扫几十万行

MySQL 单表超过 500 万 ~ 2000 万行 后，索引效率断崖式下降。分表后每张表数据量变成原来的 1/4（或 1/8）。

2. 单库连接数撑不住

不分： 10000 个并发用户 → 数据库连接池打满
分了： 10000 个用户均匀分到 2 个库 → 每个库只扛 5000