分库分表策略：宠友IM源码中的聊天数据水平扩展实践

IM系统一旦跑到千万级消息量单表设计基本都会触顶。不是“慢一点”而是索引开始失效、分页查询抖动、写入延迟明显。宠友信息在「宠友IM」源码的演进里没有一开始就做复杂分布式而是在数据量上来之后逐步引入分库分表把压力从单点拆开。这篇只讲一个主题MySQL分库分表在IM聊天数据中的落地方式。一、什么时候必须分表判断是否需要分表不看QPS而是看几个指标单表数据量超过千万索引命中率下降分页查询出现明显抖动写入出现锁等待IM系统的特点是 数据只增不减增长速度非常快宠友IM在这个阶段的处理方式不是“优化SQL”而是直接拆表二、为什么优先选择“水平分表”常见两种拆分方式垂直拆分按字段水平拆分按数据IM场景中字段变化不大瓶颈在数据量。宠友IM选择按会话做水平分表原因查询基本围绕session_id会话之间互不影响天然可以切分三、分表规则设计最简单也是最常见的一种取模分表示例// 根据session_id分表 int tableIndex Math.abs(sessionId.hashCode()) % 16; String tableName message_ tableIndex;这样可以做到数据均匀分布避免热点表表结构类似message_0 message_1 ... message_15四、为什么不用“按时间分表”很多人第一反应是按月份message_202501message_202502这种方式在IM里问题很多单个会话跨表查询复杂历史消息翻页困难热点数据集中在当前表宠友IM没有采用时间分表而是优先保证查询路径简单五、查询路由设计分表后最大的变化是 查询必须先定位表宠友IM的做法所有查询都带session_id通过同样的hash规则定位表示例// 查询某个会话的消息 int index Math.abs(sessionId.hashCode()) % 16; String table message_ index; String sql SELECT * FROM table WHERE session_id ? ORDER BY msg_id DESC LIMIT 20;关键点路由规则必须一致不能出现多种计算方式六、分页查询在分表下的处理IM聊天记录基本都是“向上翻页”分表后依然沿用基于msg_id的游标分页查询方式不使用OFFSET使用msg_id lastMsgId好处不受数据量影响索引稳定命中分表不会影响这种分页方式因为 每个会话只在一张表里七、写入路径设计写入流程根据session_id计算表插入对应表不做跨表写入不做广播写入。这样可以保证写入路径简单性能稳定八、分表后的索引策略每张子表依然需要索引(session_id, msg_id)不要因为分表就减少索引。反而更需要保证每张表查询路径清晰否则分表后依然慢。九、扩容问题当16张表不够用时怎么办常见误区直接改成32张表问题历史数据无法迁移路由规则变化宠友IM的处理思路预留扩容空间比如初期直接设计为32或64张表实际使用一部分避免后期迁移成本。十、跨表问题处理虽然大部分查询都在单表但还是会遇到全局搜索后台统计宠友IM没有强行在数据库层解决而是交给搜索引擎或离线任务数据库只负责单会话查询高性能读写避免跨表JOIN全表扫描十一、分表后的事务问题分表后一个明显变化 跨表事务很难做宠友IM的处理方式避免跨表事务通过业务保证一致性比如先写消息再更新会话状态即使失败可以补偿十二、实际踩过的几个坑1hash不均匀使用不合理字段数据集中到某几张表解决使用session_id做hash2路由规则变更不同模块用不同算法查询不到数据解决统一路由工具类3调试困难开发环境只有一张表上线后问题暴露处理本地模拟分表结构4SQL拼接错误动态表名拼接不规范SQL注入风险执行失败解决严格控制表名来源十三、这套分表策略的特点宠友信息在IM系统里的分表设计有几个很明显的工程思路不追求复杂分布式不引入中间层路由直接在业务层控制核心逻辑很简单 所有数据围绕session_id 所有路由基于同一规则IM系统的数据增长是线性的分表只是时间问题。关键不在于“分不分”而在于分完之后查询是否依然简单稳定宠友IM源码在市面上已经很成熟啦~https://www.chongyou.info/1/product/im.html