1.影响性能的因素

短连接风暴

概念：正常的连接连接到数据库执行完sql后就会断开，下次需要的时候再次连接。
max-connection:同时存在的最大连接数。
解决办法：1.通过kill connection 主动踢除那些占着连接不工作的线程；2.减少连接过程中的消耗，包括跳过MySQL的权限认证（不安全）和优化查询语句等。

慢查询性能问题

原因：索引没设计好；sql语句没写好；MySQL选错了索引。

QPS突增问题

解决办法：在数据库中把他从白名单中删除；删除该用户；重写sql语句成select 1 然后返回。

数据的可靠性（日志）

保证数据不丢失的办法

只要redolog和binlog保证持久化到磁盘，就能确保MySQL重启后数据可以恢复。

binlog的写入机制

事务在执行过程中，先把日志写到binlog cache，事务提交后，再把binlog cache写到binlog文件中。

binlog的三种格式

statement：完整的记录用户操作sql的语句。（该操作可能会导致主备不一致，比如语句中含有now()等）。
row:记录真实操作的记录行的id。（常用格式，因为用户回复比较方便，但是占用表空间）。 mixed:自动判断语句是否会导致主备不一致的问题，若会则采用row，否则采用statement。

主备一致

原理：binlog可以用来归档，也可以用来做主备同步。
主备切换流程：

备库一般设置为只读，这样可以防止误操作，切换过程中的双写问题，也可以用来判断它的角色。
主库A和从库B维持了一个长连接（B中的io-thread维持），A从本地读取binlog发给B，B拿到后写到relaylog(即：本地文件，也称中转日志),sql-thread读取中转日志，解析出日志里的命令并执行。

主备延迟

主库执行完sql后再到备库执行sql完毕这中间是有时间差的。
延迟的来源：1.某些情况下，备库机器的性能比主库差；2.备库的压力大；3.使用了大事务（比如一次删除大量sql）。 主备切换策略：1.可靠性优先策略：等主备同步完后再切换；2.可用性优先策略：不等主备同步完毕，直接切换。

双主结构（互为主备）

存在问题：节点A更新了一条语句生成binlog传到节点B，节点B执行binlog更新语句也会生成binlog传到节点A，进而形成循环复制。
解决办法：1.规定两个库的server id不相同；2.一个备库接收binlog生成数据时要与原来的binlog的server ID要相同；3.收到备份日志后先判断server id是否存在，若存在就不备份。

一主多从（读写分离的基本架构）

一主多从用户读写分离，主库负责所有数据的写入和部分读，从库负责读。客户端client做负载均衡，即客户端选择哪个库来查询。
存在的问题：过期读。
解决办法：
1.强制走主库：对于必须拿到最新数据的操作；
2.sleep方案：主库更新后，读从库之前sleep一下；
3.判断主备无延迟方案：从库查询请求前，先判断seconds-behind-master是否等于0，等于0才执行；
4.配置semi-sync方案；5：等主库位点方案；6：等GTID方案