MySQL性能优化之key_buffer_size优化

SQL herman 1791浏览 0评论
公告:“业余草”微信公众号提供免费CSDN下载服务(只下Java资源),关注业余草微信公众号,添加作者微信:xttblog,发送下载链接帮助你免费下载!
本博客日IP超过1800,PV 2600 左右,急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包,请加博主新的微信号:xttblog,之前的微信号好友位已满,备注:返现
所有面试题(java、前端、数据库、springboot等)一网打尽,请关注文末小程序
视频教程免费领

MySQL不像Oracle一样强大方便,几万条的数据查询就很慢。因此性能优化是必不可少的,今天就为大家分享一下如何通过修改key_buffer_size对MySQL进行深入的优化。


在 MySQL 数据库中,key_buffer_size是对MyISAM表性能影响最大的一个参数(注意该参数对其他类型的表设置无效),我们可以通过以下命令查看以MyISAM为主要存储引擎的key_buffer_size配置信息:

mysql> show variables like 'key_buffer_size';
+-----------------+------------+
| Variable_name   | Value      |
+-----------------+------------+
| key_buffer_size | 536870912  |
+-----------------+------------+

我们发现key_buffer_size分配到了512MB的内存,我们再通过以下命令对key_buffer_size的使用情况进行查看:

mysql> show global status like 'key_read%';
+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_read_requests | 27813678764 |    //从缓存读取索引的请求次数。
| Key_reads | 6798830 |         //从磁盘读取索引的请求次数。
+------------------------+-------------+

一共有27813678764个索引读取请求,有6798830个请求在内存中没有找到直接从硬盘读取索引,计算索引未命中缓存的概率的公式如下:

key_cache_miss_rate = Key_reads / Key_read_requests * 100%

比如上面的数据,key_cache_miss_rate为0.0244%,4000个索引读取请求才有一个直接读硬盘,已经很BT了,key_cache_miss_rate在0.1%以下都很好(每1000个请求有一个直接读硬盘),所以理论来上来说,这个比值越小越好,但过小的话,难免造成内存浪费。
以上两个值的比率固然能一部分的说明key_buffer_size是否合理,但仅仅以此就说明该值设置的合理的话,就过于偏激和片面了。因为这里忽略了两个问题:
1、比例并不显示数量的绝对值大小
2、计数器并没有考虑时间因素

虽说Key_read_requests大比小好,但是对于系统调优而言,更有意义的应该是单位时间内的Key_reads,即:

Key_reads / Uptime

Key_reads的具体用法如下:

[root@web20 mysql]# mysqladmin ext -uroot -p -ri10 | grep Key_reads
Enter password:
| Key_reads                      | 279225     |
| Key_reads                      | 116        |
| Key_reads                      | 294        |
| Key_reads                      | 255        |
| Key_reads                      | 259        |
| Key_reads                      | 342        |
| Key_reads                      | 541        |
| Key_reads                      | 733        |
| Key_reads                      | 387        |
| Key_reads                      | 583        |

注:命令里的mysqladmin ext其实就是mysqladmin extended-status,你甚至可以简写成mysqladmin e。
其中第一行表示的是汇总数值,所以这里不必考虑,下面的每行数值都表示10秒内的数据变化,从这份数据可以看出每10秒系统大约会出现500次Key_reads访问,折合到每1秒就是50次左右,至于这个数值到底合理与否,就由服务器的磁盘能力而定了。(注:我这里之所以数据变化较大,是因为有update等语句造成了表锁而导致下个时间段内的查询数猛增。)
为啥数据按10秒取样,而不是直接按1秒取样?由于时间段过小,数据变化比较剧烈,不容易直观估计大小,所以通常数据按照10秒或者60秒之类的时间段来取样是更好的。

除些之外,我们还可以参考下key_blocks_*参数:

mysql> show global status like 'key_blocks_u%';
+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_blocks_unused | 0 |
| Key_blocks_used | 413543 |
+------------------------+-------------+

Key_blocks_unused表示未使用的缓存簇(blocks)数,Key_blocks_used表示曾经用到的最大的blocks数,比如这 台服务器,所有的缓存都用到了,要么增加key_buffer_size,要么就是过渡索引了,把缓存占满了。比较理想的设置:

Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%

mysqladmin是MySQL一个重要的客户端,最常见的是使用它来关闭数据库,除此,该命令还可以了解MySQL运行状态、进程信息、进程杀死等。本文介绍一下如何使用mysqladmin extended-status(因为没有"歧义",所以可以使用ext代替)了解MySQL的运行状态。
1. 使用-r/-i参数
使用mysqladmin extended-status命令可以获得所有MySQL性能指标,即show global status的输出,不过,因为多数这些指标都是累计值,如果想了解当前的状态,则需要进行一次差值计算,这就是mysqladmin extended-status的一个额外功能,非常实用。默认的,使用extended-status,看到也是累计值,但是,加上参数-r(–relative),就可以看到各个指标的差值,配合参数-i(–sleep)就可以指定刷新的频率,那么就有如下命令:

mysqladmin -uroot -r -i 1 -pxxx extended-status
+------------------------------------------+----------------------+
| Variable_name                            | Value                |
+------------------------------------------+----------------------+
| Aborted_clients                          | 0                    |
| Com_select                               | 336                  |
| Com_insert                               | 243                  |
......
| Threads_created                          | 0                    |
+------------------------------------------+----------------------+

2. 配合grep使用
配合grep使用,我们就有:

mysqladmin -uroot -r -i 1 -pxxx extended-status \
grep "Questions\|Queries\|Innodb_rows\|Com_select \|Com_insert \|Com_update \|Com_delete "
| Com_delete                               | 1                    |
| Com_delete_multi                         | 0                    |
| Com_insert                               | 321                  |
| Com_select                               | 286                  |
| Com_update                               | 63                   |
| Innodb_rows_deleted                      | 1                    |
| Innodb_rows_inserted                     | 207                  |
| Innodb_rows_read                         | 5211                 |
| Innodb_rows_updated                      | 65                   |
| Queries                                  | 2721                 |
| Questions                                | 2721                 |

当然,还可以配合awk等,笔者在这里就不一一介绍了,有情趣的朋友可以参考一下其它文档。

版权声明:本文为博主原创文章,未经博主允许不得转载。

业余草公众号

最后,欢迎关注我的个人微信公众号:业余草(yyucao)!可加QQ1群:135430763(2000人群已满),QQ2群:454796847(已满),QQ3群:187424846(已满)。QQ群进群密码:xttblog,想加微信群的朋友,之前的微信号好友已满,请加博主新的微信号:xttblog,备注:“xttblog”,添加博主微信拉你进群。备注错误不会同意好友申请。再次感谢您的关注!后续有精彩内容会第一时间发给您!原创文章投稿请发送至532009913@qq.com邮箱。商务合作可添加助理微信进行沟通!

本文原文出处:业余草: » MySQL性能优化之key_buffer_size优化