记一次水平分表

积累知识，胜过积蓄金银！毕竟在##column_title##开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《记一次水平分表》，就带大家讲解一下MySQL、Java知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

拆表策略

常用的拆表策略有两种。

Range
根据时间去拆表，或者id去拆表，如: id data_1, 100000 data_2...，一般日志表用的较多。

Hash
像HashMap一样，采用Hash+mod的方式去获取下标。Hash是为了防止下标重复并且能够尽量的均匀。

因为我们的业务是和用户相关的，不好按照日期这些去分表，同时业务表是基于用户的Id去获取下标的，本身就是唯一的，所以直接mod了。

具体操作

旧表是分为5个，重新拆表为128个，预计重新分表后每个表的数据量在200W-400W之间。因为我们的数据是依赖第三方的数据，可以直接通过接口去获取指定时间内的数据，所以不需要考虑处理旧数据时产生的新数据。（可能会奇怪为什么通过接口就能获取到指定时间的数据，为什么本地还需要存储？一个是调用接口需要付费，如果每次都通过接口去获取，额外需要比较多的成本，第二个则是有其他功能依赖于这个数据）如果考虑到新数据，可以在原有的接口上加上对新表的操作，在处理旧数据时根据唯一键，或者一些判断去判断是否为同一数据处理。

旧的数据如何处理？直接开了四个线程把旧数据重新分表后拆入到新表(因为不是停机维护，所以旧表的数据并没有删除)，过程比较简单，就不叙述了。

迁移完成后，先上线了用户重新分表后的逻辑，以保障用户的后续操作能够全部落在新表，至此旧表的无用数据不再增加。

全部完成后，观察一段时间，线上无用户反馈，那么可以开始清理旧表的无用数据了。令人头疼的事开始了，旧表内有大量的无效数据，但同时仍然有部分用户再分表后还是落在这5个表内。一开始我选择了遍历所有用户，把再分表后不是落在这5个表的用户的数据删除。

delete from table_name WHERE user_id= #userId# limit 2000;

然而看数据库监控的时候发现，服务器资源的IOPS飙到了8000(正常是在3000左右)，我们的配置是在6000，所以已经是会影响到线上用户的正常使用。后来改为执行一次SQL就Thread.sleep(500)，IOPS是不高了，但是删除的速度也是特别的慢。而且会产生一个问题:要知道delete是不会释放删除的数据的空间的，我们需要手动的去释放这些空间。然而去释放几十个G的空间是非常慢的，这也会严重的影响用户的使用。

咨询了别人后，得到了一个解决方案。

重新创建5个临时表，把再分表后仍然落入旧表的用户数据迁入临时表，完成后直接rename临时表为旧表名，再把旧表删除就可以了。rename的效率是非常快的，几百毫秒即可。这个方案不仅大大节省了删除无效数据的时间，而且也不需要手动去释放旧表空间。

至此，这次分表就结束啦。

Tips

为什么要分为128张表？
一般建议，分表大小要为2^n,主要是有两个好处:
1.mod的时候可以使用 & 代替 %，位运算的效率要高
2.下次再分表的时候，可以保证尽可能少的数据会被迁移

统计数据库大小:

SELECT TABLE_SCHEMA,(sum(DATA_LENGTH)+sum(INDEX_LENGTH))/1024/1024/1024 FROM information_schema.TABLES group by TABLE_SCHEMA ORDER BY (sum(DATA_LENGTH)+sum(INDEX_LENGTH)) DESC;

统计一个数据库各个表大小:

select concat(round(sum(DATA_LENGTH/1024/1024/1024),2),'GB') as table_size, table_name as data from information_schema.TABLES  where table_schema='TABLE_NAME' group by table_name;

释放表空间:

optimize table table_name;

重命名表:

rename table table_name;

本篇关于《记一次水平分表》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！