总结大数据量数据库的性能优化方案

本篇文章主要讲解数据库的优化方案以及如何配置主从复制，读写分离等。

数据库性能瓶颈的主要原因

数据库连接量
2.表数据量
命中索引
未命中则会全表扫描
硬盘级索引，存储在硬盘中。
3.硬盘资源限制(QPS/TPS)

数据库优化的方案

sql优化
缓存
设计好的索引
读写分离
分库分表
水平拆分(数据量按照一定规则拆分，同一张表)
能够解决数据库连接量问题，数据表量大的问题，提高QPS与TPS
垂直拆分(按照业务规则拆分，分拆不同的库)
解决数据库连接问题，硬件资源限制。

读写分离与分库分表

1、读写分离
区别读、写多数据源方式进行数据的存储和加载。
数据的存储（增删改）一般指定写数据源，数据的读取查询指定
读数据源
(读写分离会基于主从复制)

2、分库分表
对数据的库表进行拆分，用分片的方式对数据进行管理。

1.垂直拆分

单库按照业务规则进行拆分。

2.水平拆分
单表的数据量很大的时候，按照一定的规则进行拆分。

主从复制的原理

如下图，左边是主库(Master)，右边是从库(Slave)，从主库中每执行一次新增、修改、删除之外的非查询语句，就写入到一个binlog的日志文件中，然后从库有一个线程，每一段时间，就从主库中的binlog日志中取日志数据，并一个线程去执行sql语句。到达复制的效果。

考虑的问题:数据会有延迟，不同步的存在。

为什么会产生？
1，当master tps高于slave的sql线程所能承受的范围
2，网络原因
3，磁盘读写耗时

怎么判断延迟？
1，show slave status \G; sends_behind_master 0(也是mycat的判断方式)
2, mk-heartbeat timestamp 进行主从复制两个表数据的时间搓的判断

怎么解决延时问题？

1，配置更高的硬件资源
2，把IOthread 改变成多线程的方式
mysql5.6 库进行多线程的方式
GTID进行多线程的方式
3，应用程序自己去判断（mycat有这么方案）

mysql如何配置主从复制？

Msater主数据库设置:

Master操作：
1.接入mysql并创建主从复制的用户
create user m2ssync identified by 'Qq123!@#';
2.给新建的用户赋权
GRANT REPLICATION SLAVE ON *.* TO 'm2ssync'@'%' IDENTIFIED BY 'Qq123!@#';
3.指定服务ID，开启binlog日志记录(y因为默认不开启的)，在my.cnf中加入
server-id=137    
log-bin=dbstore_binlog  //设置binlog的文件名
binlog-do-db=db_store  //做binlog日志记录的时候，只做该数据库的。要做多个，在后面加逗号分隔。

4.通过SHOW MASTER STATUS;查看Master db状态.

slave从数据库配置

Slave操作：
1.指定服务器ID，指定同步的binlog存储位置，在my.cnf中加入
server-id=101
relay-log=slave-relay-bin  //指定中期日志文件存储位置
relay-log-index=slave-relay-bin.index  //指定索引的位置
read_only=1   //只读模式
replicate_do_db=db_store  //只做该db相关的事情
2.接入slave的mysql服务，并配置change master to
master_host='192.168.8.137',
master_port=3306,master_user='m2ssync',master_p
assword='Qq123!@#',master_log_file='db_stoere_bi
nlog',master_log_pos=0;
3.start slave;
4. show slave status\G ;查看slave服务器状态

判断是否有配置好，可以看图中: Slave_IO_Running以及Slave_SQL_Running是否为yes。

关于binlog日志的详细使用与介绍:
https://www.cnblogs.com/Presley-lpc/p/9619571.html