文章目录

1. 数据库调优的措施
- 1.1 调优的目标
- 1.2 定位调优问题
- 1.3 调优的维度和步骤
2. 优化MySQL服务器
- 2.1 优化服务器硬件
- 2.2 优化MySQL的参数
3. 优化数据库结构
- 3.1 拆分表：冷热数据分离
- 3.2 增加中间表
- 3.3 增加冗余字段
- 3.4 优化数据类型
- - 3.4.1 对整数类型进行优化
  - 3.4.2 既可以使用文本类型也可以使用整数类型的字段，要选择使用整数类型
  - 3.4.3 避免使用TEXT、BLOB数据类型
  - 3.4.4 避免使用ENUM类型
  - 3.4.5 使用TIMESTAMP存储时间
  - 3.4.6 用DECIMAL代替FLOAT和DOUBLE存储精确浮点数
- 3.5 优化插入记录的速度
- - 3.5.1 MyIDAM引擎
  - 3.5.2 InnoDB引擎
- 3.6 使用非空约束
- 3.7 分析表、检查表与优化表
4. 大表优化
- 4.1 限定查询的范围
- 4.2 读写分离
- 4.3 垂直拆分
- 4.4 水平拆分
5 MySQL8新特性：隐藏索引对调优的帮助

1. 数据库调优的措施

1.1 调优的目标

尽可能节省系统资源，以便系统可以提供更大负荷的服务。（吞吐量更大）
合理的结构设计和参数调整，以提高用户操作响应的速度。（响应速度更快）
减少系统的瓶颈，提高MySQL数据库整体的性能。

1.2 定位调优问题

用户反馈
日志分析
服务器资源使用监控
数据库内部状态监控

1.3 调优的维度和步骤

选择合适的DBMS（数据库管理系统）
优化表设计
优化逻辑查询
优化物理查询
使用Redis或Memcached作为缓存
库及优化

读写分离

数据分片

2. 优化MySQL服务器

2.1 优化服务器硬件

配置较大的内存。足够大的内存是提高MySQL数据库性能的方法之一。内存的速度比磁盘I/O快得多，可以通过增加系统的缓冲区容量使数据在内存中停留的时间更长，以减少磁盘I/O。
配置高速磁盘系统，以减少读盘的等待时间，提高响应速度。磁盘的I/0能力，也就是它的寻道能力，目前的SCSI高速旋转的是7200转/分钟，这样的速度，一旦访问的用户量上去，磁盘的压力就会过大，如果是每天的网站pv（page view)在150w，这样的一般的配置就无法满足这样的需求了。现在SSD盛行，在SSD上随机访问和顺序访问性能几乎差不多，使用SSD可以减少随机IO带来的性能损耗。
合理分布磁盘I/O，把磁盘I/0分散在多个设备上，以减少资源竞争，提高并行操作能力。
配置多处理器，MySQL是多线程的数据库，多处理器可同时执行多个线程。

2.2 优化MySQL的参数

MySQL服务的配置参数都在my.cnf或者my.ini文件的[mysql组中。配置完参数以后，需要重新启动MySQL服务才会生效。

innodb_buffer_pool_size：这个参数是Mysql数据库最重要的参数之一，表示InnoDB类型的表和索引的最大缓存。它不仅仅缓存索引数据，还会缓存表的数据。这个值越大，查询的速度就会越快。但是这个值太大会影响操作系统的性能。
key_buffer_size：表示索引缓冲区的大小。索引缓冲区是所有的线程共享。增加索引缓冲区可以得到更好处理的索引（对所有读和多重写）。当然，这个值不是越大越好，它的大小取决于内存的大小。如果这个值太大，就会导致操作系统频繁换页，也会降低系统性能。对于内存在4GB左右的服务器该参数可设置为256M或384M。
table_cache：表示同时打开的表的个数。这个值越大，能够同时打开的表的个数越多。物理内存越大，设置就越大。默认为2402，调到512-1024最佳。这个值不是越大越好，因为同时打开的表太多会影响操作系统的性能。
query_cache_size：表示查询缓冲区的大小。可以通过在MySQL控制台观察，如果Qcache_lowmem_prunes的值非常大,则表明经常出现缓冲不够的情况,就要增加Query_cache_size的值；如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓存；Qcache_free_blocks,如果该值非常大,则表明缓冲区中碎片很多MysQL8.0之后失效。该参数需要和query_cache_type配合使用。
query_cache_type的值是o时,所有的查询都不使用查询缓存区。但是query_cache_type=o并不会导致MysQL释放query_cache_size所配置的缓存区内存。

当query_cache_type=1时,所有的查询都将使用查询缓存区,除非在查询语句中指定SQL_NO_CACHE，如 SELECT SQL_NO_CACHE * FROM tbl_name。

当query_cache_type=2时,只有在查询语句中使用SQL_CACHE关键字,查询才会使用查询缓存区。使用查询缓存区可以提高查询的速度，这种方式只适用于修改操作少且经常执行相同的查询操作的情况。

sort_buffer_size：表示每个需要进行排序的线程分配的缓冲区的大小。增加这个参数的值可以提高ORPERBY或GROUP BY操作的速度。默认数值是2097144字节（约2MB）。对于内存在4GB左右的服务器推荐设置为6-8M，如果有100个连接，那么实际分配的总共排序缓冲区大小为100×6=600MB。
join_buffer_size =8M：表示联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样,该参数对应的分配内存也是每个连接独享。
read_buffer_size：表示每个线程连续扫描时为扫描的每个表分配的缓冲区的大小(字节）。当线程从表中连续读取记录时需要用到这个缓冲区。SET SESSION read_buffer_size=n可以临时设置该参数的值。默认为64K，可以设置为4M。
innodb_flush_log_at_trx_commit：表示何时将缓冲区的数据写入日志文件，并且将日志文件写入磁盘中。该参数对于innoDB引擎非常重要。该参数有3个值，分别为0、1和2。该参数的默认值为1。
innodb_log_buffer_size：这是InnoDB存储引擎的事务日志所使用的缓冲区。为了提高性能,也是先将信息写入Innodb Log Buffer中,当满足 innodb_flush_log_trx_commit参数所设置的相应条件(或者日志缓冲区写满）之后，才会将日志写到文件（或者同步到磁盘）中。
max_connections：表示允许连接到MySQL数据库的最大数量，默认值是151。如果状态变量connection_errors_max_connections不为零，并且一直增长,则说明不断有连接请求因数据库连接数已达到允许最大值而失败，这是可以考虑增大max_connections的值。在Linux平台下，性能好的服器，支持500-1000个连接不是难事，需要根据服务器性能进行评估设定。|这个连接数不是越大越好，因为这些连接会浪费内存的资源。过多的连接可能会导致MySQL服务器僵死。
back_log：用于控制MySQL监听TCP端口时设置的积压请求栈大小。如果MySql的连接数达到max_connections时，新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即back_log,如果等待连接的数量超过back_log，将不被授予连接资源，将会报错。5.6.6版本之前默认值为50，之后的版本默认为50+（max_connections/5），对于Linux系统推荐设置为小于512的整数，但最大不超过900。
thread_cache_size：线程池缓存线程数量的大小，当客户端断开连接后将当前线程缓存起来，当在接到新的连接请求时快速响应无需创建新的线程。这尤其对那些使用短连接的应用程序来说可以极大的提高创建连接的效率。那么为了提高性能可以增大该参数的值。默认为60，可以设置为120。
wait_timeout：指定一个请求的最大连接时间，对于4GB左右内存的服务器可以设置为5-10。
interactive_timeout：表示服务器在关闭连接前等待行动的秒数。

3. 优化数据库结构

3.1 拆分表：冷热数据分离

拆分表的思路是，把1个包含很多字段的表拆分成2个或者多个相对较小的表。这样做的原因是，这些表中某些字段的操作频率很高（热数据），经常要进行查询或者更新操作，而另外一些字段的使用频率却很低（冷数据），冷热数据分离，可以减小表的宽度。如果放在一个表里面，每次查询都要读取大记录，会消耗较多的资源。

MySQL限制每个表最多存储4096列，并且每一行数据的大小不能超过65535字节。表越宽，把表装载进内存缓冲池时所占用的内存也就越大，也会消耗更多的IO。冷热数据分离的目的是：①减少磁盘IO，保证热数据的内存缓存命中率。②更有效的利用缓存，避免读入无用的冷数据。

3.2 增加中间表

对于需要经常联合查询的表，可以建立中间表以提高查询效率。通过建立中间表，把需要经常联合查询的数据插入中间表中，然后将原来的联合查询改为对中间表的查询，以此来提高查询效率。

首先，分析经常联合查询表中的字段；然后，使用这些字段建立一个中间表，并将原来联合查询的表的数据插入中间表中；最后，使用中间表来进行查询。

3.3 增加冗余字段

设计数据库表时应尽量遵循范式理论的规约，尽可能减少冗余字段，让数据库设计看起来精致、优雅。但是，合理地加入冗余字段可以提高查询速度。

表的规范化程度越高，表与表之间的关系就越多，需要连接查询的情况也就越多。尤其在数据量大，而且需要频繁进行连接的时候，为了提升效率，我们也可以考虑增加冗余字段来减少连接。

3.4 优化数据类型

改进表的设计时，可以考虑优化字段的数据类型。这个问题在大家刚从事开发时基本不算是问题。但是，随着你的经验越来越丰富，参与的项目越来越大，数据量也越来越多的时候，你就不能只从系统稳定性的角度来思考问题了，还要考虑到系统整体的稳定性和效率。此时，优先选择符合存储需要的最小的数据类型。

列的字段越大，建立索引时所需要的空间也就越大，这样一页中所能存储的索引节点的数量也就越少，在遍历时所需要的IO次数也就越多，索引的性能也就越差。

3.4.1 对整数类型进行优化

遇到整数类型的字段可以用INT型。这样做的理由是，INT型数据有足够大的取值范围，不用担心数据超出取值范围的问题。刚开始做项目的时候，首先要保证系统的稳定性，这样设计字段类型是可以的。但在数据量很大的时候，数据类型的定义，在很大程度上会影响到系统整体的执行效率。

对于非负型的数据（如自增ID、整型IP）来说，要优先使用无符号整型UNSIGNED来存储。因为无符号相对于有符号，同样的字节数，存储的数值范围更大。如tinyint有符号为-128-127，无符号为0-255，多出一倍的存储空间。

3.4.2 既可以使用文本类型也可以使用整数类型的字段，要选择使用整数类型

跟文本类型数据相比，大整数往往占用更少的存储空间，因此，在存取和比对的时候，可以占用更少的内存空间。所以，在二者皆可用的情况下，尽量使用整数类型，这样可以提高查询的效率。如：将IP地址转换成整型数据。

3.4.3 避免使用TEXT、BLOB数据类型

MySQL内存临时表不支持TEXT、BLOB这样的大数据类型，如果查询中包含这样的数据，在排序等操作时，就不能使用内存临时表，必须使用磁盘临时表进行。并且对于这种数据，MySQL还是要进行二次查询，会使SQL性能变得很差，但是不是说一定不能使用这样的数据类型。

如果一定要使用，建议把BLOB或是TEXT列分离到单独的扩展表中，查询时一定不要使用select*，而只需要取出必要的列，不需要TEXT列的数据时不要对该列进行查询。

3.4.4 避免使用ENUM类型

修改ENUM值需要使用ALTER语句。

ENUM类型的ORDER BY操作效率低，需要额外操作。使用TINYINT来代替ENUM类型。

3.4.5 使用TIMESTAMP存储时间

TIMESTAMP 存储的时间范围1970-01-01 00:00:01~2038-01-19-03:14:07。TIMESTAMP使用4字节，DATETIME使用8个字节，同时TIMESTAMP具有自动赋值以及自动更新的特性。

3.4.6 用DECIMAL代替FLOAT和DOUBLE存储精确浮点数

非精准浮点：float,double
精准浮点：decimal（不会丢失精度）

3.5 优化插入记录的速度

3.5.1 MyIDAM引擎

禁用索引
禁用唯一性检查
使用批量插入
使用LOAD DATA INFILE批量导入

3.5.2 InnoDB引擎

禁用唯一性检查
禁用外键检查
禁止自动提交

3.6 使用非空约束

在设计字段的时候，如果业务允许，建议尽量使用非空约束。这样做的好处是：

进行比较和计算时，省去要对NULL值的字段判断是否为空的开销，提高存储效率。
非空字段也容易创建索引。因为索引NULL列需要额外的空间来保存，所以要占用更多的空间。使用非空约束，就可以节省存储空间（每个字段1个bit）。

3.7 分析表、检查表与优化表

MySQL提供了分析表、检查表和优化表的语句。分析表主要是分析关键字的分布，检查表主要是检查表是否存在错误，优化表主要是消除删除或者更新造成的空间浪费。

4. 大表优化

4.1 限定查询的范围

禁止不带任何限制数据范围条件的查询语句。比如：我们当用户在查询订单历史的时候，我们可以控制在一个月的范围内；

4.2 读写分离

经典的数据库拆分方案，主库负责写，从库负责读。

4.3 垂直拆分

当数据量级达到千万级以上时，有时候我们需要把一个数据库切成多份，放到不同的数据库服务器上，减少对单一数据库服务器的访问压力。

垂直拆分的优点：可以使得列数据变小，在查询时减少读取的Block数，减少I/O次数。此外，垂直分区可以简化表的结构，易于维护。

垂直拆分的缺点：主键会出现冗余，需要管理冗余列，并会引起JOIN操作。此外，垂直拆分会让事务变得更加复杂。

4.4 水平拆分

尽量控制单表数据量的大小，建议控制在1000万以内。1000万并不是MySQL数据库的限制，过大会造成修改表结构、备份、恢复都会有很大的问题。此时可以用历史数据归档（应用于日志数据），水平分表（应用于业务数据）等手段来控制数据量大小。
这里我们主要考虑业务数据的水平分表策略。将大的数据表按照某个属性维度分拆成不同的小表，每张小表
保持相同的表结构。比如你可以按照年份来划分，把不同年份的数据放到不同的数据表中。2017年、2018年
和2019年的数据就可以分别放到三张数据表中。水平分表仅是解决了单一表数据过大的问题，但由于表的数据还是在同一台机器上，其实对于提升MySQL并发
能力没有什么意义，所以水平拆分最好分库，从而达到分布式的目的。

5 MySQL8新特性：隐藏索引对调优的帮助

不可见索引的特性对于性能调试非常有用。在MySQL8.0中，索引可以被“隐藏”和“显示”。当一个索引被隐藏时，它不会被查询优化器所使用。也就是说，管理员可以隐藏一个索引，然后观察对数据库的影响。如果数据库性能
有所下降，就说明这个索引是有用的，于是将其“恢复显示”即可；如果数据库性能看不出变化，就说明这个索引
是多余的，可以删掉了。

需要注意的是当索引被隐藏时，它的内容仍然是和正常索引一样实时更新的。如果一个索引需要长期被隐藏，那
么可以将其删除，因为索引的存在会影响插入、更新和删除的性能。

数据表中的主键不能被设置为invisible。

数据库调优策略：优化MySQL服务器、优化数据库结构、大表优化、隐藏索引对调优的帮助相关推荐

记录一次MySQL两千万数据的大表优化解决过程，提供三种解决方案
问题概述使用阿里云rds for MySQL数据库(就是MySQL5.6版本),有个用户上网记录表6个月的数据量近2000万,保留最近一年的数据量达到4000万,查询速度极慢,日常卡死.严重影响业务 ...
记录一次MySQL两千万数据的大表优化解决过程，提供三种解决方案 1
点击上方"方志朋",选择"设为星标" 回复"666"获取新整理的面试资料作者:王帅来源地址:https://yq.aliyun.com/ ...
干 MySQL 两千万数据的大表优化解决过程，三种厉害的解决方案
问题概述使用阿里云rds for MySQL数据库(就是MySQL5.6版本),有个用户上网记录表6个月的数据量近2000万,保留最近一年的数据量达到4000万,查询速度极慢,日常卡死.严重影响业务 ...
【转载文章】记录一次MySQL两千万数据的大表优化解决过程，提供三种解决方案...
问题概述使用阿里云rds for MySQL数据库(就是MySQL5.6版本),有个用户上网记录表6个月的数据量近2000万,保留最近一年的数据量达到4000万,查询速度极慢,日常卡死.严重影响业务 ...
mysql：数据库调优策略，sql调优
mysql:数据库调优策略. 硬件,系统配置,数据库表结构,sql及索引通过这些方面来优化项目的数据库层面. 越往后成本越低,但是效果确实越好. 第1步:选择适合的 DBMS 第2步:优化表设计第3 ...
5、优化MySQL服务器
MySQL 中,可以通过两个方面来优化服务器,即硬件和配置参数的优化.通过这些优化方式,可以提高 MySQL 的运行速度. 本节内容需要较全面的知识,可能很难理解,一般只有专业的数据库管理员才能进行这 ...
MySQL8.0优化 - 优化MySQL服务器、优化MySQL的参数、优化数据类型
文章目录学习资料优化MySQL服务器优化服务器硬件配置较大的内存配置高速磁盘系统合理分布磁盘I/O 配置多处理器优化MySQL的参数 innodb_buffer_pool_size ke ...
史上最全MySQL 大表优化方案（长文）
转载自史上最全MySQL 大表优化方案(长文) 当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 一.单表优化除非单表数据未来会一直不断上涨,否则不要一开始就考虑 ...
MySQL 大表优化方案（1）
转载自干货!!!MySQL 大表优化方案(1) 当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分 ...

数据库调优策略：优化MySQL服务器、优化数据库结构、大表优化、隐藏索引对调优的帮助