数据倾斜解决方案
在分库分表架构中，数据倾斜是指数据在多个数据库或者多张表中分布不均匀，导致某些库和某些表的负载远远高于其他表，进而引发性能瓶颈、热点问题甚至服务不可用。
一、分库分表数据倾斜的典型表现
某些分片（shard）存储的数据量远大于其他（如 80% 数据集中在 1 个分片）。
某些数据库实例 CPU、IO、连接数持续高负载，而其他实例闲置。
查询或写入集中在少数分片，形成“热点”。
扩容/迁移成本高，因为倾斜分片难以拆分或迁移。
二、常见原因
- 分片键（Sharding Key）选择不合理
使用单调递增字段（如自增ID、时间戳）作为分片键 → 数据持续写入最后一个分片。
使用低基数字段（如性别、状态） → 仅分出几个分片，无法均匀分布。
业务热点集中在某些值（如“admin”用户、热门商品 ID）。 - 哈希分片策略缺陷
哈希函数未充分打散数据（如对连续 ID 取模，但模数与数据分布冲突）。
分片数与数据特征不匹配（如 10 个分片，但数据按 5 的倍数聚集）。 - 业务特性导致天然倾斜
某些用户/商户/区域产生远超平均的数据量（如头部主播、大客户）。
某些操作高频集中在特定维度（如“未读消息”状态集中）。
解决方案
- 优化分片键设计
- 组合分片键：将高基数字段与低基数字段组合，如 (user_id, create_time)。
- 引入随机因子：对单调字段（如时间）附加随机后缀再哈希，但需支持反查（如通过二级索引）。
- 避免使用热点字段单独分片：如不用 status 单独分片。
- 采用更智能的分片策略
- 一致性哈希（Consistent Hashing）：在增减节点时最小化数据迁移，但对热点数据帮助有限。
- 虚拟分片（Virtual Shards）：将逻辑分片数设得远大于物理节点数，便于后续 rebalance。
- 动态分片：根据数据量/访问频率自动拆分热点分片（需中间件支持，如 Vitess、TiDB）。
- 热点数据特殊处理
- 热点隔离：将已知热点数据（如大 V）单独存入专用分片或缓存。
- 读写分离 + 缓存：对高频读热点使用 Redis 缓存，减少对数据库分片的压力。
- 异步写入/队列削峰：将突发写入请求排队，避免瞬时打垮某个分片。
- 监控与自动治理
监控各分片的数据量、QPS、延迟等指标。
设置阈值告警，自动触发分片迁移或扩容（需 ShardingSphere、MyCat、或自研中间件支持）。 - 业务层配合
对超大租户（如企业客户）实施 独立分片（Tenant Isolation）。
限制单个用户/设备的写入频率（限流）。
分库分表后，查询仍然很慢
问题定位
- 确认是否真的命中了分片规则
- 分库分表的核心前提是查询条件包含分片键（sharding key）。如果查询未带分片键，会导致全表扫描（scatter-gather），性能反而比单表更差。
- ✅ 优化建议：确保高频查询都基于分片键；对于非分片键查询，考虑：
建立全局二级索引（如通过 ES、HBase 或单独的索引表）；
引入冗余字段或宽表设计，将常用查询字段聚合到一张按业务维度分片的表中。
- 检查 SQL 本身是否存在性能问题
- 即使命中分片，若 SQL 存在全表扫描、缺少索引、复杂 JOIN、子查询嵌套等问题，单个分片内仍可能慢。
- ✅ 优化建议：
使用 EXPLAIN 分析执行计划；
确保分片表上有合适的局部索引；
避免跨分片 JOIN，尽量在应用层做数据聚合。
- 评估分片策略是否合理
- 如果数据分布不均（如热点用户集中在某一分片），会导致数据倾斜，部分节点负载过高。
- ✅ 优化建议：
重新设计分片键（如从 user_id 改为 user_id + 时间哈希）；
采用动态分片扩容机制，支持热点数据迁移；
考虑读写分离 + 缓存缓解热点压力。
- 引入缓存层
- 对于高频读、低频变的数据，即使分库分表，也可用 Redis / 本地缓存拦截请求。
- ✅ 注意缓存一致性问题（如采用 Cache-Aside + 延迟双删 或 订阅 binlog）。
- 异步化 & 查询拆分
对于复杂报表类查询，可将其离线化：通过 CDC（如 Canal / Debezium）同步到数仓或 OLAP 引擎（如 Doris、ClickHouse）。
实时查询只走轻量路径，重查询走异步通道。 - 监控与可观测性
使用 APM 工具（如 SkyWalking、Arthas）追踪慢查询链路，确认瓶颈是在 DB、网络、还是应用聚合逻辑。
1 | 分库分表后查询仍然慢，通常说明查询未有效利用分片键，导致全分片扫描。我会先确认是否命中分片，再检查 SQL 执行计划和索引。如果存在数据倾斜，会优化分片策略；同时对高频查询引入缓存，对复杂查询下沉到 OLAP 引擎。最终通过监控闭环验证优化效果。” |