sql 热点分区问题本质是数据或访问集中在少数分区，导致资源争用与延迟上升；需通过 qps/tps 突增、平均延迟飙升、锁等待或连接堆积三类指标精准识别，并采用加盐打散、独立拆分或在线重分布等针对性策略解决。
SQL热点 分区问题本质是数据或访问集中在少数分区，导致资源争用、响应延迟上升。解决它不靠“一刀切”扩容，而要结合数据特征、业务模式和系统能力做针对性拆分与再均衡。
识别真正的热点分区
不能只看数据量大就认定是热点——得区分“静态大数据量”和“高并发读写”。重点监控三类指标：
- QPS/TPS 突增：某分区单位时间请求远超其他分区（如 10 倍以上）
- 平均延迟飙升：该分区的查询 / 写入 P95 延迟明显高于均值
- 锁等待或连接堆积：出现大量行锁等待、事务回滚或连接超时日志
例如，一个按 user_id 哈希分 8 区的订单表，若某分区持续占整体写入量 60%，且延迟达 200ms（其余分区平均 20ms），基本可判定为热点分区。
热点键主动打散：加盐策略实操
当热点源于个别高频键（如大 V 用户 ID、热门商品 SKU），直接哈希无法分散，需在键值中引入随机因子——即“加盐”。
- 对热点键（如
user_id = 10001）生成带后缀的复合键：10001_07、10001_23……共 100 个变体 - 哈希函数作用于新键，使原单一请求分散到约 100 个不同分区
- 读取时需并行查多个盐值键，再合并结果；建议配合缓存层减少重复开销
注意：仅对已确认的少量热点键加盐，避免全量加盐带来索引膨胀和查询复杂度上升。
独立拆分热点分区
对极端倾斜场景（如单客户数据占表总量 40%），更稳妥的做法是将其从原分区体系中剥离，单独建表或库。
- 新建专用表
orders_hot_customer_10001，结构与主表一致 - 迁移历史数据，同时修改业务路由逻辑：当
user_id IN (10001, 20005, ……)时走专用路径 - 专用表可配更高规格资源（如 SSD 存储、独占 CPU）、定制索引与压缩策略
该方式隔离影响、便于运维，适合金融、政企等对 SLA 要求严格的系统。
在线重分布（Re-sharding）实施要点
适用于已有分布式中间件（如 ShardingSphere、MyCAT）或自研路由层的场景，目标是全局数据再平衡。
- 先扩容节点数（如从 8 分片扩至 16），保持旧路由兼容
- 启用中间件的自动重分布功能，按新哈希规则迁移存量数据
- 迁移期间采用“双写 + 校验”机制：新写入同步落旧新两套分区，后台异步比对一致性
- 完成校验后切换读路由，旧分区逐步下线
整个过程业务无感，但需预留足够磁盘与网络带宽，迁移窗口建议选在低峰期。
