分库是为解决单库写压力过大，分区则用于单库内高效管理大表；分库应对写瓶颈和容量上限，分区优化查询与归档，二者常组合使用。
分库不是为了“撑场面”，而是单机扛不住写压力了
当你的 INSERT 和 UPDATE 请求开始排队、主库 CPU 常年 90%+、主从延迟动辄几分钟甚至小时，说明写瓶颈已经真实存在。读写分离解决不了这个——加再多从库，写还是全压在主库上。分库的本质，是把一个数据库的写流量，切到多个物理实例上，让每台 MySQL 只承担一部分写入压力。比如按业务域拆：用户库、订单库、商品库；或按租户 ID 哈希，把不同客户的数据打散到不同库。这不是“提前优化”，而是当单库连接数超 3000、日增数据超 500 万行、慢查中 Waiting for table metadata lock 频发时，你必须面对的现实。
分区不是分库分表的替代品，而是“同一张表里划区管理”
分区对应用完全透明：SQL 还是查 orders 表，不用改一句代码。但它只在单库内生效，物理上把一张大表按规则（如 RANGE 按时间、HASH 按 ID）拆成多个子段，存为独立的 .ibd 文件。好处很实在：
• 查询带分区键（比如 WHERE created_at >= '2025-01-01'）时，MySQL 自动 分区剪枝，只扫 2025 年那个分区，不碰 2022–2024 年的数据；
• 归档旧数据极快：直接 ALTER TABLE orders DROP PARTITION p_2022，比 DELETE FROM ... WHERE year = 2022 快几个数量级；
• 但注意：分区不能跨库，不能解决连接数、磁盘 IO 瓶颈，更不能规避单库容量上限（比如单库 2TB 磁盘已满，分区再细也无用）。
什么时候该分区？什么时候必须分库？
看你的瓶颈在哪：
• 如果查询慢集中在某段时间（如最近 7 天订单查得飞快，但查历史订单就卡死），且数据量在千万级、磁盘空间充足、连接数正常 → 优先用 RANGE 分区按时间切；
• 如果写入 QPS 持续超 3000、主库 Threads_running 经常 > 50、备份一次要 6 小时以上、扩容只能换更大硬盘 → 必须分库，分区救不了；
• 如果既有冷热分离需求，又面临单库容量/连接数天花板 → 先分库，每个库内再对大表分区，这是常见组合拳；
• 别踩坑：别在没有明确查询模式的字段上分区（比如对 user_name 做 HASH 分区），会导致几乎每次查询都扫全分区；也别把分区当成索引替代品——没索引的分区表，照样慢。
分区键和分库键选错，等于白干
分区键必须是查询条件的高频字段，且最好是单调递增或可枚举的：
• 时间类字段（created_at、order_date）最稳妥，适合 RANGE；
• 主键或唯一 ID（id、user_id）适合 HASH 或 KEY，但要注意数据倾斜（比如 80% 订单来自 3 个大客户）；
• 分库键同理：选高基数、查询路由明确的字段，避免用状态类字段（如 status）——查 “全部待支付” 就得扫所有库；
• 关键提醒：一旦选定，改起来极痛苦。MySQL 不支持在线修改分区类型，分库后迁移数据更是停机窗口长、一致性难保。上线前务必用真实流量压测分区剪枝是否生效、分库路由是否均匀。
