2021-07-26 20:06:49 晓掌柜 版权声明:本文为站长原创文章,转载请写明出处
在开发中,很多时候我们会选用Mysql数据库,但是往往会因为这样或那样的问题(慢sql、cup跟不上、io性能孱弱等)导致我们的数据库性能跟不上。
甚至很多时候在自己配置Mysql服务器时都没有办法得出一个统一的标准值。这个时候我们最好是等待数据库稳定运行一段时间后,根据实际的运行状态来
进行相关的优化工作。
这里我们就MySql的一些常用的性能查询的语句作为切入点,来深入了解你的数据库性能及服务状态。
show global status;
查询MySql的全局状态,其中有474条结果项,设计数据库状态的各个方面。我们后面一点点介绍。
show variables;
查询MySql的相关配置属性,返回结果项607,是数据库的各项配置属性。这个同样我们在后面一点点介绍。
show variables like '%slow%';
上述配置显示信息:
① 执行时间查出2s即为慢查询
② 慢查询日志配置
③ 慢查询功能开启
show global status like '%slow%';
上述信息显示:
① 当前共有28个mansql
show variables like 'max_connections';
上述信息显示:
① 当前最大连接数配置为151
PS: 超出这个链接数量后,数据库服务器就扛不住了!
show global status like 'Max_used_connections';
上述信息显示:
① 本次运行期间,最大的连接数为43(尚有余力哈)
show variables like 'key_buffer_size';
上述信息显示:
① 当前配置的索引缓冲区大小为:8388608 bit
show global status like 'key_read%';
上述信息显示:
① 共有多少的索引请求过来
② 索引的读取数量是多少
PS: 可以查看索引的命中率
show global status like 'created_tmp%';
上述信息显示:
① 在磁盘上创建了多少个临时表
② 创建了多少个临时文件
③ 创建的临时表数量
PS: 三者比较理想的配比为: Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%
show variables where Variable_name in ('tmp_table_size', 'max_heap_table_size');
上述信息显示:
① 只有16777216 bit的临时表才会被放置到内存中
② 超出16777216 bit的临时表就会用到硬盘临时表
show global status like 'open%tables%';
上述信息显示:
① 当前一共打开了1713张数据表
② 历史打开过的数据表的数量值
如果opened_tables的数值过大,则可能是table_cache配置过小
show variables like 'table_cache';
比较理想的配比为:
Open_tables / Opened_tables * 100% >= 85%
Open_tables / table_cache * 100% <= 95%
show global status like 'Thread%';
上述信息显示:
① 历史创建了多少的进程
② 有多少被缓存的进程
③ 有多少进程正在运行
④ 历史连接的进程数量
如果历史创建的进程数量过大,可以试着增加进程缓存大小。
show variables like 'thread_cache_size';
show global status like 'qcache%';
相关参数解释:
Qcache_free_blocks:缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理,从而得到
一个空闲块。
Qcache_free_memory:缓存中的空闲内存。
Qcache_hits:每次查询在缓存中命中时就增大
Qcache_inserts:每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。
Qcache_lowmem_prunes:缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看;
如果这个数字在不断增长,就表示可能碎片非常严重,或者内存很少。(上面的 free_blocks和free_memory可以告诉您属于哪种情况)
Qcache_not_cached:不适合进行缓存的查询的数量,通常是由于这些查询不是 SELECT 语句或者用了now()之类的函数。
Qcache_queries_in_cache:当前缓存的查询(和响应)的数量。
Qcache_total_blocks:缓存中块的数量。
show variables like 'query_cache%';
相关参数释义:
query_cache_limit:超过此大小的查询将不缓存
query_cache_min_res_unit:缓存块的最小大小
query_cache_size:查询缓存大小
query_cache_type:缓存类型,决定缓存什么样的查询,示例中表示不缓存 select sql_no_cache 查询
query_cache_wlock_invalidate:当有其他客户端正在对MyISAM表进行写操作时,如果查询在query cache中,是否返回cache结果还是
等写操作完成再读表获取结果。
query_cache_min_res_unit的配置是一柄”双刃剑”,默认是4KB,设置值大对大数据查询有好处,但如果你的查询都是小数据查询,就容易
造成内存碎片和浪费。
查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%
如果查询缓存碎片率超过20%,可以用FLUSH QUERY CACHE整理缓存碎片,或者试试减小query_cache_min_res_unit,如果你的查询都是
小数据量的话。
查询缓存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%
查询缓存利用率在25%以下的话说明query_cache_size设置的过大,可适当减小;查询缓存利用率在80%以上而且Qcache_lowmem_prunes > 50
的话说明query_cache_size可能有点小,要不就是碎片太多。
查询缓存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%
示例服务器 查询缓存碎片率 = 20.46%,查询缓存利用率 = 62.26%,查询缓存命中率 = 1.94%,命中率很差,可能写操作比较频繁吧,
而且可能有些碎片。
show global status like 'sort%';
上述信息显示:
MySQL首先会尝试在内存中做排序,使用的内存大小由系统变量 Sort_buffer_size 决定,如果它的大小不够把所有的记录都读到内存中,
MySQL 就会把每次在内存中排序的结果存到临时文件中,等 MySQL 找到所有记录之后,再把临时文件中的记录做一次排序。这再次排序就会
增加 Sort_merge_passes。实际上,MySQL 会用另一个临时文件来存再次排序的结果,所以通常会看到 Sort_merge_passes 增加的数值是
建临时文件数的两倍。因为用到了临时文件,所以速度可能会比较慢,增加 Sort_buffer_size 会减少 Sort_merge_passes 和 创建临时文件的次数。
但盲目的增加 Sort_buffer_size 并不一定能提高速度,另外,增加read_rnd_buffer_size(3.2.3是record_rnd_buffer_size)的值对排序的操作
也有一点的好处的。
show global status like 'open_files';
show variables like 'open_files_limit';
PS: 比较合适的设置:Open_files / open_files_limit * 100% <= 75%
show global status like 'handler_read%';
show global status like 'com_select';
PS: 计算表扫描率:
show global status like 'table_locks%';
上述数据显示:
① Table_locks_immediate表示立即释放表锁数
② Table_locks_waited表示需要等待的表锁数
PS: 如果Table_locks_immediate / Table_locks_waited > 5000,最好采用InnoDB引擎,因为InnoDB是行锁而MyISAM是表锁,
对于高并发写入的应用InnoDB效果会好些。示例中的服务器Table_locks_immediate / Table_locks_waited = 235,MyISAM就足够了。
本文的产出更多来源于网络,仅供学习。
附参考链接:https://blog.csdn.net/a745233700/article/details/84708157