MySQL 分库分表是高并发、大数据量场景下的核心优化手段，面试中常被深入考察——不仅问“怎么做”，更关注“为什么这么做”“踩过哪些坑”“如何权衡取舍”。以下是最常被问到的几类经典问题及务实回答思路。

分库分表到底解决什么问题？

本质是突破单机数据库的性能与容量瓶颈：

• 性能瓶颈：单库连接数、CPU、IO、锁竞争（尤其热点行更新）达到极限，TPS/QPS 上不去
• 容量瓶颈：单表超千万甚至亿级数据，查询变慢、DDL 阻塞严重、备份恢复耗时过长
• 可用性瓶颈：单点故障影响全局；大表迁移或修复可能引发长时间不可用

注意：不是所有系统都需要分库分表。小流量、低增长业务强行分片反而增加复杂度、降低开发效率、引入分布式事务等新问题。

垂直拆分和水平拆分怎么选？

两者目标不同，常组合使用：

• 垂直拆分：按业务维度切，把一个大库拆成多个小库（如用户库、订单库、商品库），或把宽表拆成多个窄表（如 user_base、user_profile、user_setting）。适合耦合度低、读写分离明确的场景。
• 水平拆分：按数据维度切，同一张逻辑表的数据分散到多个物理表/库中（如按 user_id 取模分 16 库，每库 32 表）。用于解决单表数据量过大或访问压力集中问题。

典型路径：先垂直拆分理清边界，再对其中增长快、压力大的核心表（如订单表、日志表）做水平分片。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

分片键怎么选？关键看三点

分片键（Sharding Key）是路由依据，选错会导致数据倾斜、跨库查询、扩容困难：

• 高频查询条件：必须是 WHERE 中最常出现的字段（如 user_id、order_no），否则大量 SQL 变成全库扫描
• 分布均匀性：避免用 status、gender 这类低基数字段，否则某些分片数据暴涨（如“待支付”订单扎堆）
• 不可变性：尽量选创建后不更新的字段（如 user_id），避免跨分片 update 带来一致性难题

常见误区：用自增主键做分片键——看似均匀，但无法支持按业务维度快速定位，且分库后主键不再全局唯一，需改用雪花算法或 UUID 等方案生成分布式 ID。

跨分片查询和分布式事务怎么处理？

这是分库分表后最棘手的两个现实问题：

• 跨分片查询：禁止在应用层 for 循环遍历所有分片。可行方案包括：冗余字段（如把 user_name 冗余进 order 表）、异步构建宽表（通过 binlog 同步到 ES 或 OLAP 引擎）、限制查询范围（如只查最近 3 个月订单，且时间字段本身可作为分片辅助条件）
• 分布式事务：优先用业务补偿（TCC）、本地消息表+定时校验、最大努力通知等最终一致性方案。强一致场景慎用 XA（性能差、运维难），也不建议依赖 Seata 等中间件掩盖设计缺陷——应从源头减少跨库更新需求（比如把关联操作收敛到同一分片内）

记住：分库分表不是银弹。它把数据库的复杂性转移给了应用层和运维体系，每一次分片决策都要有明确的监控指标支撑（如单库 CPU >70%、慢查周增幅 >50%），而不是凭感觉提前过度设计。