MySQL调优
参考博客
MySQL调优篇：单机数据库如何在高并发场景下健步如飞？
优化类型大概分类三个类型
- 结构/架构优化：读写分离、集群热备、分布式架构、引入缓存/消息/搜索中间件、分库分表、中台架构（大数据中台、基础设施中台）等
- 配置/参数优化：调整应用系统中各层面的配置文件、启动参数达到优化性能的目标
- 代码/操作优化：从代码、操作方面进行调节，达到效率更高的初衷
优化思想
单个节点调优核心思想
CPU，内存，磁盘三者任何一个达到一个瓶颈都会影响 线程越多，需要的CPU调度能就越强，需要的内存也越大，磁盘IO速率也会要求越快
在考虑性能优化时，必然不能让CPU、内存、磁盘等资源的使用率达到95%+，一般而言，最大利用率控制在80-85%左右的最佳状态
优秀且适用的系统架构胜千万次调优
一台正常部署的MySQL极致调优也很难做到一秒5000+的QPS
读写参半：项目集群，双主热备
写大于读：消息中间件，DB分库分表，项目集群
读大于写：缓存/搜素中间件，动静分离，读写分离
预防大于一切，调优并非“临时抱佛脚”
提前防范问题主要在两个阶段
- 项目初期预测未来的流量压力，提前根据业务设计出合适的架构，确保上线后可以承载业务的正常增长
- 项目上线后，配备完善的监控系统，在性能瓶颈来临前设好警报线，确保能够在真正的性能瓶颈到来之前解决问题
- 不要“卡点”设计，也不能过度设计造成性能过剩
- 监控系统的作用并不是用来提醒你项目“嗝屁”了的，而是用来提醒你：线上部署的应用系统可能会“嗝屁”或快“嗝屁”了
- 通常情况下，在监控系统上面设置的性能阈值都会比最大极限值要低5~15%
- 最大极限值是85%，那设置告警值一般是75%左右就会告警，不会真达到85%才告警，只有这样做才能留有足够的时间让运维和开发人员介入排查
无需追求完美，理性权衡利弊
在处理棘手问题或优化性能时，无需刻意追求完美，理性权衡利弊后，适当的做出一些决断，抛弃掉一部分不重要的，起码比整个系统挂掉要好，何况之后也同样可以恢复
性能调优通用步骤
性能优化永远是建立在性能瓶颈之上的，如果你的系统没有出现瓶颈，那则无需调优，过早的调优是一个很错误的选择，调优之前需要牢记的一点是：不要为了调优而调优，而是需要调优时才调
发现瓶颈有两种方式
- 你的应用中具备完善的监控系统，能够提前感知性能瓶颈的出现
- 应用中没有搭载监控系统，性能瓶颈已经发生，从而导致应用频繁宕机
性能优化步骤如下
- 发现性能瓶颈：如有监控系统，那它会主动发出警报；如若没有，那出现瓶颈时应用肯定会出问题，如：无响应、响应缓慢、频繁宕机等。
- 排查瓶颈原因：排查瓶颈是由于故障问题导致的，还是真的存在性能瓶颈。
- 定位瓶颈位置：往往一个系统都会由多个层面协同工作，然后对外提供服务，当发现性能瓶颈时，应当确定瓶颈的范围，如：网络带宽瓶颈、Java应用瓶颈、数据库瓶颈等。
- 解决性能瓶颈：定位到具体的瓶颈后对症下药，从结构、配置、操作等方面出发，着手解决瓶颈问题
MySQL性能优化实践
MySQL调优的五个维度
- 客户端与连接层的优化：调整客户端DB连接池的参数和DB连接层的参数。
- MySQL结构的优化：合理的设计库表结构，表中字段根据业务选择合适的数据类型、索引。
- MySQL参数优化：调整参数的默认值，根据业务将各类参数调整到合适的大小。
- 整体架构优化：引入中间件减轻数据库压力，优化MySQL架构提高可用性。
- 编码层优化：根据库表结构、索引结构优化业务SQL语句，提高索引命中率
五个性能优化项中，通常情况下，带来的性能收益排序为4 > 2 > 5 > 3 > 1
MySQL连接层优化策略
一个用户最终请求会在Java程序中分配一条线程处理, 最终变成一条SQL发往MySQL
首先明确, 理想情况下是数据库连接数越大越好, 当实际上硬件的性能有限, 没有满足, 所以这个命题就改成在一定的条件的情况下, 数据库的连接数越大越好
数据库连接数越大，也就意味着内部创建出的工作线程会越多，线程越多代表需要的CPU配置得更高，比如现在有300个客户端连接，内部创建了300条工作线程处理，但服务器的CPU仅有32个核心，那当前服务器最多只能支持32条线程同时工作，那其他268条线程怎么办呢？为了其他线程能够正常执行，CPU就会以时间片调度的模式工作，不同核心在不同线程间反复切换执行，但由于线程数远超核心数，因此会导致线程上下文切换的开销，远大于线程执行的开销
如果这里的时间片和线程上下文开销不理解, 那么请去借助AI获取其他的博客了解
由于硬件的资源限制, 所以数据库连接数如何配置成一个合适的值有讲究
连接池的种类
- 客户端连接池: 指Java自身维护的数据库连接对象, 例如Druid, C3P0等
- 服务端连接池: MySQL-Server的连接层中，自身维护的一个连接池，用来实现线程复用的目的
面试题: 为什么MySQL要设计两个连接池?
客户端连接池: 为了减少应用程序与MySQL服务器之间建立连接和断开连接开销 服务端连接池: 限制同时能连接的客户端数量
todo
优化点
服务端连接池通常不关心, 一般来说优化的客户端连接池的连接数
面试题: 为什么不将应用程序的连接数设置成MySQL连接数一样大?
通常来说数据库实例不只为单体项目提供服务(特别是在这个微服务泛滥的时代), 而且平常我们使用navcate连接到数据库也是会占用连接数的
如果两个相等的情况, 如果此时还有一些其他的连接加入, 那么就可能导致MySQL连接数爆满, 然后就会出现那么连接不上数据库的现象
对于Linux的连接也是同理, 如果同时的连接人数太多, 那么后续的人就可能连接到Linix服务器
如何优化
公式: 最大连接数 = (CPU核心数 * 2) + 有效磁盘数
这里的有效磁盘数指的是SSD固态硬盘个数, SSD固态硬盘没有磁片, 没有旋转磁面寻址, 发生磁盘IO时通常不会阻塞, 所以有SSD磁盘情况下该数值可以+1
通常来说一颗CPU在2-3线程之间的切换不会存在太大的开销, 如果大于这个值, 那么线程切换的开销就会超过线程的本身的开销
场景描述
比如目前服务器的硬件配置为CPU：16core、硬盘类型：SSD，此时最佳的最大连接数则为16*2+1=33，而常驻连接数可以调整到30左右，这组配置绝对是当前场景下的最佳配置，如若再调大连接数，这反而会让性能更慢，因为会造成线程上下文切换的额外开销
需要说明的是, 上述的公式不适用所有场景, 实际中还需要考虑很多因素, SQL执行时长, 大事务等
场景调优
偶发性高峰业务的连接数配置
- 公式: 最大连接数 = (CPU核心数 * 2) + 有效磁盘数，常驻连接数 = CPU核数 + 1
- 缩短连接的存活时长
- 及时释放空闲数据库连接
分库分表的连接数配置
- 根据节点的硬件配置, 硬件的不同就会导致所能承受的压力也不同
连接数优化注意事项
对于最佳连接数的计算，首先要把CPU核数放首位考虑，紧接着是磁盘，最后是网络带宽，因为带宽会影响SQL执行时间，综合考虑后才能计算出最合适的连接数大小
MySQL结构优化方案
这里对B+树一定熟悉, 不然是云里雾里, 如果不熟悉的, 那么请去了解后再来, 该文不会进行细致的讲解
结构优化指的是
- 表结构
- 字段结构
- 索引结构
表结构
- 表的字段不要太多(重中之重)
- 原因: InnoDB会将部分数据加载到内存中再操作, 如果一个表的字段很多, 那么能加载的数据就少
- 一张表最多最多只能允许设计30个字段左右，否则会导致查询时的性能明显下降
- 实际中一个表的字段通常由冷热字段之分, 可以考虑划分成两张表, 一个热字段的表, 一个冷字段的表(冷热数据思想)
- 如果某个字段连表查询很频繁, 那么可以考虑冗余该字段
- 减少了连表查询次数(空间换时间思想), 查询数据提高了, 但是需要额外的维护成本, 适用查多改的表
- 不能无法冗余, 否则会造成之前提到的表字段过多的情况
- 必须要有主键, 并且是顺序递增, 主键必须和业务无关系
- 实时性要求不过的建立中间表
- 例如统计数据(通常连表并且数据量不小), 提前查询好, 然后定时更新数据即可, 减少频繁连表查询开销
- 根据业务特性为每张不同的表选择合适的存储引擎
- 查多该少的使用MyISAM, 例如字典表, 权限表等
- 其余表使用InnoDB
字段结构
- 在保证足够使用的范围内，选择最小数据类型, 因为它们会占用更少的磁盘、内存和CPU缓存，同时在处理速度也会更快
- 对于姓名字段，一般都会限制用户名长度，这时不要无脑用varchar，使用char类型更好。
- 对于一些显然不会拥有太多数据的表，主键ID的类型可以从int换成tinyint、smallint、mediumit, 减少聚簇索引的大小, 二级索引的大小
- 对于日期字段，不要使用字符串类型，而更应该选择datetime、timestamp，一般情况下最好为后者。
- datetime: 8字节, 表示范围'1000-01-01 00:00:00'到'9999-12-31 23:59:59'
- timestamp: 4字节, 表示范围'1970-01-01 00:00:01'到'2038-01-19 03:14:07'
- 对于一些固定值的字段，如性别、状态、省份、国籍等字段，可以选择使用数值型代替字符串，如果必须使用字符串类型，最好使用enum枚举类型代替varchar类型。
- 尽量避免索引字段值为NULL，定义字段时应尽可能使用NOT NULL关键字，因为字段空值过多会影响索引性能
- 在条件允许的情况下，尽量使用最简单的类型代替复杂的类型，如IP的存储可以使用int而并非varchar，因为简单的数据类型，操作时通常需要的CPU资源更少
索引优化
- 索引字段组成尽量选择多个, 当有多个索引时考虑合并成联合索引
- 减少磁盘空间, 以及利用索引覆盖减少回表操作
- 较长字符串建立索引时, 可以去前N个字符建立前缀索引
- 注意了这个N个字符区分度一定要高
- 经常模糊查询的索引可以建立全文索引代替普通索引
- 某些不做范围查询的字段上建立所以可以采取hash结构
MySQL参数调优选项
调整InnoDB缓存区(buffer pool)
InnoDB缓冲区的最佳大小比例应该控制在70~75%
当InnoDB缓冲区大于1G的时, 会将缓冲区划分为多个实例空间, 多线程并发执行时, 减少并发冲突
MySQL官方的建议是每个缓冲区实例必须大于1GB
如果是8/16G, 那么建议设置1G大小
如果是32GB/64GB甚至更高, 那么建议设置成2GB或者更大
缓冲实例个数建议设置成物理内存的总量的1/3或1/2之间
调整工作线程的缓冲区
- sort_buffer, read_buffer, join_buffer都属于线程私有区域, 每一条线程都有这么一片区域
- sort_buffer_size：排序缓冲区大小，影响**group by、order by...**等排序操作
- read_buffer_size：读取缓冲区大小，影响**select...**查询操作的性能
- join_buffer_size：联查缓冲区大小，影响join多表联查的性能
对于这些区域，最好根据机器内存来设置为一到两倍MB，啥意思呢？比如4GB的内存，建议将其调整为4/8MB、8GB的内存，建议将其调整为8/16MB.....，但这些区域的大小最好控制在64MB以下，因为线程每次执行完一条SQL后，就会将这些区域释放，所以再调大也没有必要了。
文件排序触发的阈值: max_length_for_sort_data, 排序字段值的最大长度小于该值，则会将所有要排序的字段值载入内存排序，但如果大于该值时，则会一批一批的加载排序字段值进内存，然后一边加载一边做排序, 可以适当调高该值
调整临时表空间
tmp_table_size: 当创建的临时表空间占用超过tmp_table_size时，就会将其他新创建的临时表转到磁盘中创建
max_heap_table_size: : 当创建的临时表空间占用超过max_heap_table_size时, MySQL将会将该临时表转换为磁盘上的MyISAM表。这个转换过程会导致性能下降，因为磁盘I/O通常比内存访问慢得多
那么这两个参数该设置多大呢？这要根据show global status like 'created_tmp%';的统计信息来决定，用统计出来的信息：Created_tmp_disk_tables / Created_tmp_tables * 100% = 120%，达到这个标准就比较合适，但调整这个区域的值需要反复重启MySQL以及压测，因此比较费时间，如果你在项目中很少使用临时表，哪也可以不关心这块参数的调整。
调整空闲线程的存活时间
wait_timeout: 命令行或脚本链接的超时时间, 默认8小时
interactive_timeout: 交互式链接超时时间, 默认8小时
这两个参数必须同时设置, 否则不生效
手动调低连接时间, 可以让性能及时释放, 减少资源占用
其他调优
引入缓存中间件解决读压力
在项目中引入Redis作为缓存后，在缓存Key设计合理的情况下，至少能够为MySQL分担**70%**以上的读压力，查询MySQL之前先查询一次Redis，Redis中有缓存数据则直接返回，没有数据时再将请求交给MySQL处理，从MySQL查询到数据后，再次将数据写入Redis，后续有相同请求再来读取数据时，直接从Redis返回数据即可。
引入MQ中间件解决写压力
将实行要求没有这高的写请求放入MQ中, 其他线程按需拉去消费, 减少写压力
主从读写分离
架构模式
- 主从: 主负责读写, 从负责读, 适用于读多写少
- 主从复制基于的是bin-log日志实现
- 双主双写热备: 两个节点互为主从, 双节点都具有读写能力, 并且都可以互相同步数据
- 麻烦之处: 但是为了兼容两者之间的数据，对于每张表的主键要处理好，如果表的主键是int自增类型的，请一定要手动设置一下自增步长和起始值, 否则出现两条相同主键的数据情况, 通常可以设置一台只使用计数, 一台只使用偶数
- 分库分表
- 垂直分库
- 水平分表