大表治理（一）-常见方案
大表治理（二）-归档
大表治理（三）-分库分表
大表治理（四）-分库分表中间件Mycat 和Sharding-Jdbc简介
大表定义
- 仅从单表数据量来看大表的定义：单个表数据量大于500万~5000万行数据（若单行记录超过4KB，建议总容量范围不超过500万） 定义来源：阿里云help.aliyun.com/document_de…
- 除了从数据量层面上进行大表的定义外，我们还需要关心数据库服务器磁盘IO、CPU、内存是否达到一个比较高的阈值，如果有的话，也可能是存在大表风险。
- 说下之前我自己负责的系统，因为业务增长速度比较快，单表数据行数接近3亿条，总数据量100G，但是都是使用索引查询，且不会返回大批量的数据，读写性能也没有太大的影响。（虽然说没影响，但是不是不需要治理）
大表危害
- 读写性能变差
- 改表耗时时间较长：现在改表操作基本上都是使用gh-ost，逻辑大致是：先新建一张表，然后将老表数据复制，再rename，其中复制时间会比较长。
常见方案
-
数据归档 数据归档即通过删除历史数据的方式，减少表的数据量。
-
分库分表
- 垂直拆分
垂直拆库：垂直分库针对的是一个系统中的不同业务进行拆分（如订单一个库、商品一个库）
垂直拆表：基于列进行大表拆小表，如果一个表字段太多，就拆到扩展表中。 - 水平拆分
水平分表：和垂直分表有些相似,不过垂直分表是基于列的,而水平分表是基于全表的。
水平分库分表：将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同
- 切换存储
- 使用分布式数据库，如：TIDB
- 使用搜索引擎，如：Elasticsearch
- 使用支持大容量的KV数据库，如：阿里Tair
进行大表治理的时候，我们有可能不会使用一种方案，而是使用多种方案。如：归档后，我们还想查询历史数据，这时候我们就可以用归档加Elasticsearch的方式，最近的数据查询DB，历史数据查询Elasticsearch。
