表分库分区

分区

作用：提高查询性能，删除数据也很方便，删除分区就好了

最好是建表时就建好分区，如果建的分区用完了，后面可以再扩展

写、查询的时候无感，数据库自动根据分区字段查找对应的分区数据

如果是中途再建分区，一种生产验证过的方案是：新建一张和源表A结构相同的表A1，把表A1建好分区，并且把表A作为A1的一个分区，然后再把表A1重命名为A。表A大概1~2亿的数据，处理完花了3~4个小时，没有出现生产问题

一般不要把源表直接做分区，因为源表数据量很大的话做分区可能会把表卡死
一般新建张表，将新表提前做好分区，如果老表数据不再使用了，可以将业务数据写新表(写操作是无感的，就是新表表名)，
select/update/delete时如果Where后面的限制条件包含分区字段id时会自动去对应分区中查找，否则还是全表扫描

对已经有很多数据的表建索引会卡死吗？多少数据量耗时多久呢?

目前生产有实践效果是tidb，一两亿的数据，建分区，两三个小时没出问题，会影响生产业务，生产现有业务会变慢

分库分表的选择：点击此处查看详情

• 水平分库：系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库
• 水平分表：系统绝对并发量并没有上来，只是单表的数据量太多，影响了SQL效率，加重了CPU负担，以至于成为瓶颈
• 垂直分库：系统绝对并发量上来了，并且可以抽象出单独的业务模块，比如配置表，字典表单独拎出来
• 垂直分表：系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大。以至于数据库缓存的数据行减少，查询时会去读磁盘数据产生大量的随机读IO，产生IO瓶颈
• 基因法：把同一个用户的所有订单数据落到同一个库同一个表中，订单号中含有具体分库的信息，这样不管是通过user_id还是order_id都能准确定位到数据，解决了引入索引表的复杂性，并且解决了应用层整合数据的麻烦。详细内容请参考此博客文章

一般情况下，先考虑分区。如果一个分区中的数据量超过2000万（例如对于pg，mysql，oracle等数据库，能够承受更大的数据量级），索引的作用就不那么明显了，这时可以考虑进行分库操作。
大型电商企业的订单号通常反映了数据库的数量。例如，拼多多的订单号后4位是相同的，可以推测一个客户的数据应该存储在同一个库中，每个客户号经过哈希后对10000取模，这样可以根据订单号快速定位存储在哪个库中。
误区：
客户型数据应该分表，订单型数据应该分区。如果按照这种方式分表，那么按商家号进行查询就需要跨表操作。实际操作中，通过数据同步的方式建立数仓来实现不同维度的查询。