扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
这些项的解释如表 1 所示。
表 1. MySQL 查询缓存变量
变量名 | 说明 |
---|---|
Qcache_free_blocks |
缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE 会对缓存中的碎片进行整理,从而得到一个空闲块。 |
Qcache_free_memory |
缓存中的空闲内存。 |
Qcache_hits |
每次查询在缓存中命中时就增大。 |
Qcache_inserts |
每次插入一个查询时就增大。命中次数除以插入次数就是不中比率;用 1 减去这个值就是命中率。在上面这个例子中,大约有 87% 的查询都在缓存中命中。 |
Qcache_lowmem_prunes |
缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看;如果这个数字在不断增长,就表示可能碎片非常严重,或者内存很少。(上面的 free_blocks 和 free_memory 可以告诉您属于哪种情况)。 |
Qcache_not_cached |
不适合进行缓存的查询的数量,通常是由于这些查询不是 SELECT 语句。 |
Qcache_queries_in_cache |
当前缓存的查询(和响应)的数量。 |
Qcache_total_blocks |
缓存中块的数量。 |
通常,间隔几秒显示这些变量就可以看出区别,这可以帮助确定缓存是否正在有效地使用。运行 FLUSH STATUS
可以重置一些计数器,如果服务器已经运行了一段时间,这会非常有帮助。
使用非常大的查询缓存,期望可以缓存所有东西,这种想法非常诱人。由于 mysqld
必须要对缓存进行维护,例如当内存变得很低时执行剪除,因此服务器可能会在试图管理缓存时而陷入困境。作为一条规则,如果 FLUSH QUERY CACHE
占用了很长时间,那就说明缓存太大了。
强制限制
您可以在 mysqld
中强制一些限制来确保系统负载不会导致资源耗尽的情况出现。清单 3 给出了 my.cnf 中与资源有关的一些重要设置。
清单 3. MySQL 资源设置
set-variable=max_connections=500 |
MaxClients
类似,其想法是确保只建立服务允许数目的连接。要确定服务器上目前建立过的最大连接数,请执行 SHOW STATUS LIKE 'max_used_connections'
。
第 2 行告诉 mysqld
终止所有空闲时间超过 10 秒的连接。在 LAMP 应用程序中,连接数据库的时间通常就是 Web 服务器处理请求所花费的时间。有时候,如果负载过重,连接会挂起,并且会占用连接表空间。如果有多个交互用户或使用了到数据库的持久连接,那么将这个值设低一点并不可取!
最后一行是一个安全的方法。如果一个主机在连接到服务器时有问题,并重试很多次后放弃,那么这个主机就会被锁定,直到 FLUSH HOSTS
之后才能运行。默认情况下,10 次失败就足以导致锁定了。将这个值修改为 100 会给服务器足够的时间来从问题中恢复。如果重试 100 次都无法建立连接,那么使用再高的值也不会有太多帮助,可能它根本就无法连接。
缓冲区和缓存
MySQL 支持超过 100 个的可调节设置;但是幸运的是,掌握少数几个就可以满足大部分需要。查找这些设置的正确值可以通过 SHOW STATUS
命令查看状态变量,从中可以确定 mysqld
的运作情况是否符合我们的预期。给缓冲区和缓存分配的内存不能超过系统中的现有内存,因此调优通常都需要进行一些妥协。
MySQL 可调节设置可以应用于整个 mysqld
进程,也可以应用于单个客户机会话。
服务器端的设置
每个表都可以表示为磁盘上的一个文件,必须先打开,后读取。为了加快从文件中读取数据的过程,mysqld
对这些打开文件进行了缓存,其最大数目由 /etc/mysqld.conf 中的 table_cache
指定。清单 4 给出了显示与打开表有关的活动的方式。
清单 4. 显示打开表的活动
|
Opened_tables
随着重新运行 SHOW STATUS
命令快速增加,就说明缓存命中率不够。如果 Open_tables
比 table_cache
设置小很多,就说明该值太大了(不过有空间可以增长总不是什么坏事)。例如,使用 table_cache = 5000
可以调整表的缓存。
与表的缓存类似,对于线程来说也有一个缓存。 mysqld
在接收连接时会根据需要生成线程。在一个连接变化很快的繁忙服务器上,对线程进行缓存便于以后使用可以加快最初的连接。
清单 5 显示如何确定是否缓存了足够的线程。
清单 5. 显示线程使用统计信息
|
Threads_created
,每次 mysqld
需要创建一个新线程时,这个值都会增加。如果这个数字在连续执行 SHOW STATUS
命令时快速增加,就应该尝试增大线程缓存。例如,可以在 my.cnf 中使用 thread_cache = 40
来实现此目的。
关键字缓冲区保存了 MyISAM 表的索引块。理想情况下,对于这些块的请求应该来自于内存,而不是来自于磁盘。清单 6 显示了如何确定有多少块是从磁盘中读取的,以及有多少块是从内存中读取的。
清单 6. 确定关键字效率
|
Key_reads
代表命中磁盘的请求个数, Key_read_requests
是总数。命中磁盘的读请求数除以读请求总数就是不中比率 —— 在本例中每 1,000 个请求,大约有 0.6 个没有命中内存。如果每 1,000 个请求中命中磁盘的数目超过 1 个,就应该考虑增大关键字缓冲区了。例如,key_buffer = 384M
会将缓冲区设置为 384MB。
临时表可以在更高级的查询中使用,其中数据在进一步进行处理(例如 GROUP BY
字句)之前,都必须先保存到临时表中;理想情况下,在内存中创建临时表。但是如果临时表变得太大,就需要写入磁盘中。清单 7 给出了与临时表创建有关的统计信息。
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者