mysql处理大表的方法个人总结

场景描述：停车记录表过大，需要归档处理（不是备份），偶有少量应用查询。

针对insert、update热表+数据量大的问题，果断分库分表。

以下讨论针对仅是数据量大，不易维护，没有热表问题。
综合评估，
1、研发工作量最小，推荐3，支持本地join操作。不支持海量数据，使用前需计算。

2、研发工作量第二小，推荐4.1。drds支持夸实例查询。不支持海量数据，使用前需计算。
3、单表海量数据：推荐6，不支持join操作，但彻底解决问题。其次推荐8，需要查询固定。

4、分库分表替代方案：推荐9。工作量第二大。

5、分库分表：推荐7。工作量最大。

 

7工作量巨大。
1、2有硬伤。
4复杂度高，不易维护。

缺点编号：
1、单实例内数据量过大无法解决。（不可容忍）
2、分区键需要添加进主键，改造大。
3、需要程序改写sql，通过关键字判断或者union
4、配置双数据源

 

针对大表解决方法对比：
1,分区表
优点：时间分区、关键字分区，能提高索引和数据热度。
缺点：1、2

2、手动本地设置历史表。
优点：能提高索引和数据热度。
缺点：1、３

2.1、手动本地设置历史表TokuDB引擎。
优点：能提高索引和数据热度。历史表空间会变小到可接受范围。
缺点：缺点1长远来讲，未得到彻底解决。３。数据迁移时CPU增高。逻辑备份时间和资源不可控。表结构变更不可控。潜在风险很大，商用环境不宜推广。

3、设置dblink，关联历史表
优点：能提高索引和数据热度。
缺点：缺点1长远来讲，未得到彻底解决。３、阿里云不支持

４、DTS实现主从差异化
优点：本地能提高索引和数据热度。
缺点：缺点1长远来讲，未得到彻底解决。4、主库删除数据时需要停止DTS，操作复杂不智能，维护成本高。从库配置不宜过低，但使用率不高。

４.1、DTS的订阅+JDK实现主从差异化+DRDS跨实例查询
优点：本地能提高索引和数据热度。
缺点：缺点1长远来讲，未得到彻底解决。数据订阅JDK需要自己完成并配置成服务。表结构修改，不需要人工介入。3、4

5、添加历史实例，存储历史表，无关联查询。
优点：能提高索引和数据热度。历史库低频访问，成本低。
缺点：3、4,添加调度任务、定期迁移数据。

6、单表分库分表，无关联查询
优点：彻底解决问题。
缺点：drds分析构建表。数据迁移。4

7、整库分库分表，需要研发积极配合。
优点：彻底解决问题。
缺点：重构表结构(大）；数据迁移（大）；应用重新评估与测试（大）；一般会涉及到核心业务多个查询，周期长、风险高。

8、采用Hbase+RDS数据订阅（阿里原生支持）
优点：可屏蔽delete操作，支持海量数据查询。
缺点：因hbase无二级索引，只能处理查询条件规定的表。表结构修改，需要人工介入。2、3、4

9、采用Hbase分析数据库+DTS数据订阅(最灵活)
优点：可屏蔽delete操作。可设置各种数据源，支持海量数据查询。
缺点：数据订阅JDK需要自己完成并配置成服务。表结构修改，需要人工介入。3、4