数据库的分表
这里的优化仅以mysql为例，不同的数据库可能会有出入
垂直分表
原理：
MySQL底层实际是将数据分页，保存在每一个16k（1.6万）的数据页上。每一次读取数据时，每一行数据都会有磁盘的IO操作。当进行数据的拆分时，每一行数据的列数会变少，表示单个数据页可以保存更多行的数据，关于磁盘的IO读写操作时间也会更少。
磁盘的IO操作是十分消耗性能的
简单理解就是通过把一张表的所有字段拆分成多个字段表，然后通过join 链接
with a as ( select emp_no ,birth_date ,first_name from employees limit 20 ), b as ( select emp_no ,last_name ,hire_date from employees limit 20 ) select a.emp_no ,a.birth_date ,a.first_name ,b.last_name ,b.hire_date from a join b on a.emp_no=b.emp_no;
这里我创建了临时表，让大家更好的知道
水平分表
无论是什么形式的水平分表，本质上都是将数据保存在结构相同但名称相似的表中，
原本的20条数据，可以将它横向拆分为两张表格保存，每一张小表格中只保存整体的一部分数据。
（在mysql中，这样的分表一般是保证每一张表的数据在500万至2000万的数据条数）
那怎么分表呢，上面的图片只是让大家明白分表的意思
ID取模分表
根据id进行简单的分表，分两张表， %2 ；分3张，%3、、、、
select * from employees where MOD(emp_no,2)=1 limit 10; select * from employees where MOD(emp_no,2)=0 limit 10;
到这里一些小可爱就会觉得为啥不直接跟第一图的一样呢？，原因是表的数据会增加，如果直接规定前10条数据存第一张表，后10条存第二章表，那新增的数据往哪存呢，有些小可爱就会觉得再创建一张，这个做法就很麻烦，每新增数据就创建表，这样很浪费时间，
但是上面这种方法也有缺点，就是一张表存储的数据量是有限的，如果超出了容量，就得创建表，这样也很麻烦，如果一下子就创建许多张分表，又有可能会造成性能（存储性能和读取性能）浪费
ID范围分表
简单根据数据的条数进行分表。例如每一张表只保存200万条数据，每次数据的写入都先判断表格
里数据是否已经达到限制。即为当table_1中的数据已经有200万时，则向table_2中写入数据，依次类
推。当需要读取数据时，先判断emp_no的范围，小于200万则选择table_1，在200万至400万选择
table_2，在400万至600万选择table_3。
但这样的缺点在于，可能会存在某一时刻，某一张表的IO过于频繁。因为当大量数据涌入时，对于
读写操作只会作用于最新的那张表格（这里要根据具体的业务逻辑进行判断），而其他的表格只是简单
的数据读取，同样是影响数据的操作。
结合取模和范围的分表
如果ID分表要根据一张表里面数据量有多少进行分表，范围分表是给定范围进行分表，
两种结合起来，一可以减少id分表带来的表不够用的情况解决了，也在一定程度上把范围分表的某个IO操作频繁的进行了分担了，
临时表不会写入数据库中不会参与计算
1、对于原始数据的处理。先采取范围分表的形式，设定每张表的数据量为200万，当一条数据进行写入
时，先判 断表格数据是否已经写满。如果已经达到数据保存上限，则新建表格。
2、如果数据没有达到储存上限，则进入下一步，对字段进行取模分表。仍然可以通过对ID进行是否能被
2整除的 操作，简单判断应该将实际数据保存在那一张表格中。如果反过来先id分表，在范围分表也是可以的
读扩散
在分表后，如果我们想查询一些数据，是不知道id，只知道名字或者某些字段，就会把所有的表读一遍，找出这些数据，不管这些表里面有没有都要读一遍
实际的数据查询是会遍历每一张表可能存在对应数据的表。如果分表过多，有些表中即使不存在需要的数据，仍然会被检索查询。同样会导致数据库的性能损失。
为了能够减少这样的性能损失，我们可以通过一张中间表来进行过渡。
这样就可以知道哪张表有该字段，哪张表没有该字段，
注意一下，一般适用于很频繁的数据查询的表
优点：
通过事先读取table_temp，可以获取到哪些表中存在需要的Jame数据，可以省去对多余分表的查询，提高了数据的读取速度
缺点：
加大了程序员的工作量。每次数据写入，都需要至少同步更新两张表格，加大了维护成本。而且这样的中间表只是对于特殊字段的查询处理，意味着如果这样的处理过多，同样会导致相同类型的中间表也会过多。
