项目运行了三年了，流水表主表数据已经达到4kw以上
所以最近项目开始时不时的出现问题，主要体现在以下方面：
1.客户端经常出现查询超时。
1.1 mybatis分页查询出现问题。
对于这个情况，我在这篇博客中做了描述，可以移步查看下。
https://mp.csdn.net/mp_blog/creation/editor/134708058
1.2 项目里面一些统计或者趋势图开始出现问题
这种情况看到后基本情况就是sql中常出现count()、sum()等等聚合函数。查了一下午资料，发现还是对于mysql没有理解透彻，本来以为聚合函数就是简单的累加等操作，结果发现mysql会一条条的取出来然后进行累计或其他操作。
2.高峰期有时候日志会报锁表。
这个情况的出现是因为，我最近看到主表数据量太大了，所以就开始分表操作。按月进行分表，主要逻辑是每三分钟从主表中取出最早一小时的数据（大概在3k-5k条），然后插入到月表，然后根据id批量删除主表。
但是就是这个简单的操作，看似没什么问题，今天高峰期的时候，CPU直接飙升到200%。然后仔细分析后，就是高峰期的时候对数据库的读写频率本就高，再加上我这个批量操作，直接导致锁表。
针对以上情况，开始跟同事讨论解决方案：
1.读写分离很有必要
为了不让数据库频繁读写导致锁表，必须要把读写分离开启。（之前没有打开）。这样才能保证数据同步到月表中。
2.针对分页的问题已经描述了 请移步，地址在上方
3.分库分表
数据量太大，分库的操作是必须要做的。对于count等聚合函数的操作，只能在数据同步完成后，在月份表里面进行统计。
4.一定要对于经常做统计的数据进行报表处理
具体来讲就是。如果我系统中经常有要查询3天内、7天内...这样的情况，那就要做日报表，每天把数据统计好，这样后面直接从日报表中取数据。如果出现当天每小时的查询，那就要进行时段报表的统计，记录每天每小时的统计数据，这样才能保证不是所有的数据都从主表里面进行查询。因为主表的数据只要慢慢累加，总有一天会达到mysql的瓶颈。目前4KW已经事故频发，迫使我们不得不改造项目。
只是一些经验，当然每个人的情况不一样，因为项目在我们主导，所以可操作空间比较大，但是如果是一些已经运行了很久的项目，最好的方式就是根据上方第四条做拓展，这样不会对原有业务影响太大。