数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。
说白了，就是分担写负载
分库分表一
节点：mysql数据库一主多从的数据库集群（数据一致），所以用节点表示
重新对数据库连接进行配置就行
优点：数据库拆分比较简单，尤其适合没有跨库查询的情况下
缺点：如果写操作主要在订单表，那就分库分表的作用不是很大了
分库分表二
当表所在的服务器也达到瓶颈时，无法继续升级
分库分表三：水平拆分（分片->不同物理节点）
类似分区表（不同：一个节点：数据库），分片很容易出现问题，难以维护，慎重 
分片前准备
- 不经常更新的表
- 数据量不大，字典列表
- 使用多写的方式维护一致性（表更新时，同时更新所有分片的表操作）
- 定期检查（防止业务逻辑问题）
- 第二种方式优点是数据没有冗余问题，查询效率差一些，因为要关联，合并
数据量和访问量的平均，结合业务做分析
- 第一种：分区键并不总是数值，所有要用模来转换成数值性数据
- 优点：可以比较平均的分配数据
- 缺点：很难人为控制哪个数据分配到哪个分片中
- 第二种：常用于分区键是日期类型或者是数据类型的情况
- 优点：很清楚知道数据在哪个分片中
- 缺点：数据（访问量）分配不平均
- 第三种：
- 灵活对数据在哪些分片进行控制
- 映射表会产生很大的服务压力，可以使用缓存（否则很可能成为系统的瓶颈）
- auto_increment_increment（总分片数） auto_increment_offset（不同的值）
- 只适用于一个节点保存一套分区表
- 全局节点ID->建表使用auto_increment属性，生成自增ID->性能瓶颈
- 类似第二种
演示
分片工具（演示，不是很完美）
三个节点：节点1（服务器节点），节点2（分片数据库节点），节点3（oneProxy节点）
节点1,节点2添加oneProxy连接用户 
demo.sh 启动脚本
- 修改配置
- 添加分片节点
- 通过oneProxy客户端获取加密字符串密码 ./demo.sh
- mysql -P4041 -uadmin -pOneProxy -h127.0.0.1;
- passwd “123456” （获取密码）
- 修改proxy-user-list 用户/加密密码@数据库名
- peoxy-part-template 分片方式地址
- remote-address 远程管理地址
设置分片方式
订单表，订单商品表，相互关联，分片键一致
- 表名
- 分片键
- 键类型
- 分片方式
- 分片方式（分片）
- suffix后缀
- 分片组
建表
节点1 
节点2 
节点3
ps -ef | grep oneproxy
重启oneProxy
kill -9 1164
./demo.sh
mysql -P4041 -uadmin -pOneProxy -h127.0.0.1;
list backend;
测试
通过oneproxy连接
mysql -utest -p123456 -h127.0.0.1 -p3306
节点1： 
节点2： 