Mysql性能优化的理解

mysql的性能优化可以分为以下四大部分

• 硬件和操作系统层面的优化
• 架构设计层面的优化
• Mysql程序配置优化
• Sql优化

硬件层面的优化

• 从硬件层面来说，影响Mysql性能因素有，CPU、可用内存大小、磁盘读写速度、网络带宽
• 从操作系统层面来说，应用文件句柄、操作系统网络的配置都会影响到Mysql的性能。这部分优化一般都由DBA或者运维工程师去完成

架构层面的优化

Mysql是一个磁盘IO访问量非常频繁的关系型数据库
在高并发的场景中mysql的数据库必然承受巨大的并发压力，我们可以从以下几个方面去优化。

• 1，搭建主从集群。
  单个mysql服务容易单点故障，一旦服务器宕机，将会导致以来mysql数据的应用全部无法响应，主从集群可以保证服务的高可用性。
• 2，分库分表。
  通过降低单个服务器节点的IO压力，通过分库分表方式可以降低单标数据量，从而提升sql查询效率
• 3，读写分离。
  在读多写少的场景下，通过读写分离方案，可以避免读写冲突导致性能的影响。
• 4，针对热点数据，可以引入更为高效的分布式数据库。比如redis，mongdb等。

Mysql程序配置的优化

Mysql是一个经过互联网大厂验证过的生产级别的成熟的数据库，对于Mysql数据库本身的优化，一般是通过Mysql的配置文件my.cnf来完成的，比如。
Mysql5.7版本默认的最大连接数是151个，这个值可以在my.conf中修改，binlog日志默认不开启，缓存池bufferpoll的默认大小等。

SQL优化

• 慢sql的定位和排查
  我们可以通过慢查询日志和慢查询分析工具得到有问题的sql
• 执行计划分析
  通过explain来查看当前sql的执行计划，可以重点关注type key rows filterd等字段，从而定位该sql执行慢的根本原因
• 使用show profile工具
  Show profile是Mysql提供的可以用来分析当前回话中，SQL语句资源消耗的情况的工具，可用于SQL调优的测量。在当前会话中，默认情况下处于show profile是关闭状态，打开之后保存最近15次的运行结果。针对运行慢的sql，通过profile工具进行详细的分析，可以得到sql执行过程所有的资源消耗情况。
• sql的优化规则
  1，sql查询一定要基于索引来进行数据扫描
  2，使用联合索引的时候，联合索引中的列从左往右命中越多越好
  3，尽量不要使用select * 应使用具体的列，剔除不需要返回的列。减少回表
  4，尽量不要使用子表，使用联合查询的时候union all的时候不要使用UNION（这里会剔除相同的数据计算）
  5，使用like最好是%最好是在右边
  6，不要使用聚合函数，这样索引会失效
  7，排序 尽可能使用索引的字段排序，避免文件排序的方式。

Mysql和Redis如何保证数据的一致性

一般情况下，正对一些热点数据，都会通过redis中间层，减少数据库IO，提升数据的IO性能。
当应用程序需要去读取某个数据的时候，首先会先尝试去Redis里面加载，如果命中就直接返回，没有则再去数据库中获取，然后保存至redis缓存。

这样的架构存在一个问题，数据只有一份，同时保存在数据库和Redis里面，当数据发生变化的时候，需要同时更新redis和数据库，由于更新是有先后顺序的。并且他不像Mysql中的多表事务操作，满足ACID特性，所以会出现数据不一致性。

解决方案

1. 先更新数据库，在更新缓存
   这里当更新完缓存，数据库回滚的时候 就会出现数据不一致问题
2. 先删除缓存在更新数据库
   在高并发的情况下，可能删除了缓存在数据库还未更新的时候，有请求访问进来，这个时候访问数据库还是旧的历史数据
3. 最终一致性方案
   延迟双删
   监听binlog日志

聚集索引和非聚集索引

1. 定义
   聚集索引就是基于主键创建的索引，除了主键之外的其他索引称之为非聚集索引

binlog文件的三种保存格式

1. statement
   记录sql的原文。好处是，不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。因为sql执行是有上下文的，因此在保存的时候需要保存相关的信息，同时还有一些使用了函数之类的语句无法被记录复制。
2. row
   不记录sql语句上下文关系，仅保存哪条记录被修改。记录单元为每一行的改动，基本是可以全部记下来但是由于很多操作，会导致大量行的改动（比如alter table），因此这种模式的文件保存的信息量太大，日志量太大。
3. mixed
   一种折中的方案，普通操作使用statement记录，当无法使用statement的时候使用row。

Mysql 数据库cpu飙升的话，要怎么处理？

1. 排查出具体的问题
   可以使用top 命令，找到cpu占用过高的进程是否是mysqlId
   如果是mysqlId，可以在mysql中通过show processlist查看当前的会话情况，确定是否有消耗资源的sql正在运行。
   找到消耗过高的SQL，通过执行计划进行具体的分析。
2. 处理方式
   如果确定是sql问题，可以通过sql的优化手段进行调整
   重新执行sql分析确认是否有达到优化的目的。
3. 其他情况
   如果不是sql问题导致，那就要分析cpu飙高的时间段，mysql的整体并发连接数。如果有大量的请求连接进来，那我们就需要分析这个时间段业务的情况，再做出相应的调整

redolog和binlog的区别

binlog：主要是用来做数据备份的。

redolog: 主要是在mysql数据库事务的ACID特性里面，用来保证数据的持久化特性。但是其实它还有很多的作用。
数据崩溃的时候，可以通过redolog来恢复未完成的数据。保证数据的完整性

Mysql的事务隔离级别

https://blog.csdn.net/weixin_30409927/article/details/121907021

Mysql的主从同步延迟问题怎么解决

复制的主要流程

1. 主库更新事件（update,insert,delete）被写到binlog
2. 从库发起连接，连接到主库
3. 此时主库创建一个binlog dump thread，把binlog的内容发送到从库。
4. 从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容写入到relay log。
5. 从库还会创建一个sql线程。从relay log里面读取内容，从exec_master_log_pos位置开始执行读取到的更新事件，将更新内容写入到slave db。

主从数据同步涉及到网络数据传输，由于网络通信的延迟以及从库数据处理的效率问题，就会导致主从数据同步延迟的情况。

解决方案

1，从库数据要是没有的话，查询主库数据
2，在从库上执行show slave status命令获取seconds_behind_master字段的延迟时间。这里业务设置规则在多久之后才能同步数据
3，设计一主多从来分担从库压力，减少主从同步的时间
4，通过并行复制解决从库复制延迟的问题。