本文探讨了在数据库压力增大时，如何通过分库分表来提高操作效率。针对不同业务特性，提出了自增主键哈希取模和非自增主键的分表策略，并通过具体案例分析了支付详情表和用户积分表的分表设计。同时，文章指出了分表后可能遇到的热点问题和联合查询挑战，并提供了相应的解决方案，如缓存和创建索引表。强调了数据平均拆分和减少全局扫描的重要性。
针对系统数据表日渐增长的数据量，分库分表是减少数据库压力，增加db操作效率的常见解决方案。就目前项目系统而言，数据量级基本多张表已达3kw至6kw的量级。下面对笔者针对系统db结构，结合O2O业务特性整理的分表设计思路及实践方案的讨论。
设计思路：
1、首先确定是否要分表：就一般系统而言，数据量达到kw级别，慢sql数量增多，基本就需要考虑分表操作。
2、确定分成几张表：这个根据数据增长量估算，简言之，当前数据量分成多少份，结合当前业务量，估算本次分表后，可满足多少年内稳健的数据服务。
3、拆分方案：就拆分方案而言，一般采取两种思路：
1)一是根据自增主键进行哈希取模，将数据均分到n张表中；该方案最简单，且最合适，拆分后数据分布均匀。
2)二是无自增主键，选取的分表id由特定的方式生成，则需先确定分表id生成逻辑，根据该逻辑确定取模计算的逻辑，以保证数据均分。
案例分析：
下面采用项目中两个case分表说明：
case1支付详情表：
1、数据表结构分析：6kw量级、自增主键、数据插入查询多，更新少、日增量3k条
2、方案设计：采用自增主键取模8，分为8张表。
case2 用户积分表：
1、数据表结构分析：4kw数据量级、主键 id非自增、读多写少，常根据uid进行查询
2、方案设计：
采用uid作为分表键，研究
最低0.47元/天 解锁文章
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
