MYSQL性能优化之数据库的分库分表

数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（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：