你们项目中用过分库分表吗？
主从解决：访问压力
分库分表的时机：
- 前提，项目业务数据逐渐增多，或业务发展比较迅速（单表的数据量达1000W或20G以后）
- 优化已解决布隆性能问题（主从读写分离、查询索引...）
- IO瓶颈（磁盘IO、网络IO）、CPU瓶颈（聚合查询、连接数太多）
分库分表解决：存储压力
拆分策略
- 垂直拆分：垂直分库、垂直分表
- 水平拆分：水平分库、水平分表
垂直分库
垂直分库：以表为依据，根据业务将不同表拆分到不同库中
特点：
- 按照业务对数据分级管理、维护、监控、扩展
- 在高并发下，提高磁盘IO和数据量连接数
垂直分表
垂直分表：以字段为依据，根据字段属性将不同字段拆分到不同表中。
拆分规则：
- 把不常用的字段单独放在一张表
- 把text、blob等大字段拆分出来放在附表中
特点：
- 冷热数据分离
- 减少IO过度争抢，两表互不影响
水平分库
水平分库：将一个库的数据拆分到多个库中
路由规则：
- 根据id节点取模
- 按照id也就是范围路由，节点1（1-100万）、节点2（100万-200万）
- ...
特点：
- 解决了单库大数据量，高并发的性能瓶颈问题
- 提高了系统的稳定性和可用性
水平分表
水平分表：将一个表的数据拆分到多个表中（可以在同一个库内）
特点：
- 优化单表数据量过大产生的性能问题
- 避免IO争抢并减少锁表的几率
分库分表之后新的问题和技术上的变化
分库之后的问题：
- 分布式事务一致性问题
- 跨节点关联查询
- 跨节点分页、排序函数
- 主键避重
分库分表中间件:
- sharding-sphere(下定斯费儿)
- mycat
