MySQL数据库：参数优化 绝地灬酷狼 2022-11-06 04:48 113阅读 0赞 数据库属于 IO 密集型的应用程序，其主要职责就是数据的管理及存储工作。而我们知道，从内存中读取一个数据库的时间是微秒级别，而从一块普通硬盘上读取一个IO是在毫秒级别，二者相差3个数量级。所以，要优化数据库，首先第一步需要优化的就是 IO，尽可能将磁盘IO转化为内存IO。本文先从 MySQL 数据库IO相关缓存参数的角度来介绍可以通过哪些参数进行IO优化： ### 一、参数说明： ### **1、query\_cache\_size / query\_cache\_type （global）：** Query cache 主要用来缓存 SQL语句执行的结果集ResultSet，所以仅仅只能针对 select 语句。当我们打开了 Query Cache 功能，MySQL在接受到一条 select 语句的请求后，MySQL 会直接根据预先设定好的HASH算法将接受到的 select 语句以字符串方式进行hash，然后到Query Cache 中直接查找是否已经缓存。如果已经在缓存中，该 select 请求就会直接将数据返回，从而省略了后面所有的步骤（如 SQL语句的解析，优化器优化以及向存储引擎请求数据等），极大的提高性能。 但是 Query Cache 也有一个致命的缺陷，那就是当某个表的数据有任何任何变化，都会导致所有引用了该表的 select 语句在 Query Cache 中的缓存数据失效。所以，当我们的数据变化非常频繁的情况下，使用Query Cache 可能会得不偿失。 Query Cache的使用需要多个参数配合，其中最为关键的是 query\_cache\_size 和 query\_cache\_type，前者设置用于缓存 ResultSet 的内存大小，后者设置在何场景下使用 Query Cache。 （1）query\_cache\_size：用于缓存的大小： 在以往的经验来看，如果不是用来缓存基本不变的数据的MySQL数据库，query\_cache\_size 一般 256MB 是一个比较合适的大小。当然，这可以通过计算Query Cache的命中率（Qcache\_hits/(Qcache\_hits+Qcache\_inserts)\*100)）来进行调整。 （2）query\_cache\_type：设置使用缓存的场景： > 0（OFF）：全不使用query cache > > 1（ON）：除显式要求不使用 query cache 之外的所有的 select 都使用query cache，通过sql\_no\_cache 显示指定不使用缓存 > > 2（DEMOND）：只有显示要求才使用query cache，通过 sql\_cache 显示指定使用缓存 **2、innodb\_buffer\_pool\_size（global）：** 当使用InnoDB存储引擎时，innodb\_buffer\_pool\_size 参数可能是影响我们性能的最为关键的一个参数了，它用来设置用于缓存 InnoDB 索引及数据块的内存区域大小。当我们操作一个 InnoDB 表的时候，返回的所有数据或者去数据过程中用到的任何一个索引块，都会在这个内存区域中走一遭。innodb\_buffer\_pool\_size 设置了 InnoDB 存储引擎需求最大的一块内存区域的大小，直接关系到 InnoDB存储引擎的性能，所以如果我们有足够的内存，尽可将该参数设置到足够大，将尽可能多的 InnoDB 的索引及数据都放入到该缓存区域中，直至全部。我们可以通过 (Innodb\_buffer\_pool\_read\_requests – Innodb\_buffer\_pool\_reads) / Innodb\_buffer\_pool\_read\_requests \* 100% 计算缓存命中率，并根据命中率来调整 innodb\_buffer\_pool\_size 参数大小进行优化。 **3、innodb\_additional\_mem\_pool\_size（global）：** innodb\_additional\_mem\_pool\_size 设置了InnoDB存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小，所以当我们一个MySQL 中的数据库对象非常多的时候，是需要适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率的。这个参数大小是否足够还是比较容易知道的，因为当过小的时候，MySQL 会记录 Warning 信息到数据库的 error log 中，这时候你就知道该调整这个参数大小了。 **4、binlog\_cache\_size （global）：** Binlog Cache 用于在打开了binlog二进制日志记录功能的环境，是 MySQL 用来提高binlog的记录效率而设计的一个用于短时间内临时缓存binlog数据的内存区域。一般来说，如果我们的数据库中没有什么大事务，写入也不是特别频繁，2MB～4MB是一个合适的选择。但是如果我们的数据库大事务较多，写入量比较大，可与适当调高binlog\_cache\_size。同时，我们可以通过binlog\_cache\_use 以及 binlog\_cache\_disk\_use来分析设置的binlog\_cache\_size是否足够，是否有大量的binlog\_cache由于内存大小不够而使用临时文件（binlog\_cache\_disk\_use）来缓存了 **5、innodb\_log\_buffer\_size （global）：** 这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer，InnoDB 在写事务日志的时候，为了提高性能，也是先将信息写入 redo log buffer 中，当满足 innodb\_flush\_log\_trx\_commit 参数所设置的相应条件（或者日志缓冲区写满）之后，才会将日志写入到磁盘文件中。可以通过 innodb\_log\_buffer\_size 参数设置其可以使用的最大内存空间。 > innodb\_flush\_log\_trx\_commit 参数对 redo log 的写入性能有非常关键的影响。该参数可以设置为0，1，2，解释如下： > > * 0：每秒将 log buffer 中的数据将以写入到日志文件中，同时flush到磁盘。在机器crash并重启后，会丢失一秒的事务日志数据 > * 1：每次事务提交时，将 log buffer 中的数据写入日志文件，并同时flush到磁盘。在机器crash并重启后，不会丢失事务日志 > * 2：每次事务提交时，将 log buffer 中的数据写入日志文件，并每秒flush一次到磁盘。在机器crash并重启后，有可能丢失数据 > > 此外，MySQL文档中还提到，这几种设置中的每秒同步一次的机制，可能并不会完全确保非常准确的每秒就一定会发生同步，还取决于进程调度的问题。实际上，InnoDB 能否真正满足此参数所设置值代表的意义正常 Recovery 还是受到了不同 OS 下文件系统以及磁盘本身的限制，可能有些时候在并没有真正完成磁盘同步的情况下也会告诉 mysqld 已经完成了磁盘同步。 **6、innodb\_max\_dirty\_pages\_pct （global）：** 这个参数和上面的各个参数不同，他不是用来设置用于缓存某种数据的内存大小的，而是用来控制在 InnoDB Buffer Pool 中可以不用写入数据文件中的Dirty Page 的比例（已经被修改但还没有从内存中写入到数据文件的脏数据）。这个比例值越大，从内存到磁盘的写入操作就会相对减少，所以能够一定程度下减少写入操作的磁盘IO。但是，如果这个比例值过大，当数据库 Crash 之后重启的时间可能就会很长，因为会有大量的事务数据需要从日志文件恢复出来写入数据文件中。同时，过大的比例值同时可能也会造成在达到比例设定上限后的 flush 操作“过猛”而导致性能波动很大。 **7、key\_buffer\_size （global）：** key\_buffer\_size 参数用来设置用于缓存 MyISAM 存储引擎中索引文件的内存区域大小。如果我们有足够的内存，这个缓存区域最好是能够存放下我们所有的 MyISAM 引擎表的所有索引，以尽可能提高性能。由于 MyISAM 引擎的特性限制了他仅仅只会缓存索引块到内存中，而不会缓存表数据库块。所以，我们的 SQL 一定要尽可能让过滤条件都在索引中，以便让缓存帮助我们提高查询效率。 **8、bulk\_insert\_buffer\_size （thread）：** 和key\_buffer\_size一样，这个参数同样也仅作用于使用 MyISAM存储引擎，用来缓存批量插入数据的时候临时缓存写入数据。当我们使用如下几种数据写入语句的时候，会使用这个内存区域来缓存批量结构的数据以帮助批量写入数据文件： > * insert … select … > * insert … values (…) ,(…),(…)… > * load data infile… into… (非空表) ### 二、取值建议： ### 上面这几个参数是 MySQL 中为了减少磁盘物理IO而设计的主要参数，对 MySQL 的性能起到了至关重要的作用，下面是几个参数的建议取值： > * query\_cache\_type : 如果全部使用innodb存储引擎，建议为0，如果使用MyISAM 存储引擎，建议为2，同时在SQL语句中显式控制是否是使用query cache； > * query\_cache\_size: 根据 命中率（Qcache\_hits/(Qcache\_hits+Qcache\_inserts)\*100)）进行调整，一般不建议太大，256MB可能已经差不多了，大型的配置型静态数据可适当调大； > * binlog\_cache\_size: 一般环境2MB～4MB是一个合适的选择，事务较大且写入频繁的数据库环境可以适当调大，但不建议超过32MB； > * key\_buffer\_size: 如果不使用MyISAM存储引擎，16MB足以，用来缓存一些系统表信息等。如果使用 MyISAM存储引擎，在内存允许的情况下，尽可能将所有索引放入内存，简单来说就是“越大越好”； > * bulk\_insert\_buffer\_size: 如果经常性的需要使用批量插入的特殊语句（上面有说明）来插入数据，可以适当调大该参数至16MB～32MB，不建议继续增大； > * innodb\_buffer\_pool\_size: 如果不使用InnoDB存储引擎，可以不用调整这个参数，如果需要使用，在内存允许的情况下，尽可能将所有的InnoDB数据文件存放如内存中，同样将但来说也是“越大越好”； > * innodb\_additional\_mem\_pool\_size: 一般的数据库建议调整到8MB～16MB，如果表特别多，可以调整到32MB，可以根据error log中的信息判断是否需要增大； > * innodb\_log\_buffer\_size: 默认是1MB，写入频繁的系统可适当增大至4MB～8MB。当然如上面介绍所说，这个参数实际上还和另外的flush参数相关。一般来说不建议超过32MB； > * innodb\_max\_dirty\_pages\_pct: 根据以往的经验，重启恢复的数据如果要超过1GB的话，启动速度会比较慢，几乎难以接受，所以建议不大于 1GB/innodb\_buffer\_pool\_size(GB)\*100 这个值。当然，如果你能够忍受启动时间比较长，而且希望尽量减少内存至磁盘的flush，可以将这个值调整到90，但不建议超过90。
还没有评论，来说两句吧...