| 类别 | 计数器 | 描述 |
| mysql | 查询缓存 | SQL：show variables like '%Query_cache%'; |
| Qcache_free_blocks | 如果Qcache_free_blocks大致等于Qcache_total_blocks/2，则说明碎片非常严重。如果Qcache_lowmem_prunes的值正在增加，并且有大量的自由块，这意味着碎片导致查询正在被从缓存中永久删除 | |
| 缓存碎片利用率 | 缓存利用率=（query_cache_size - Qcache_free_memory）/query_cache_size * 100% 如果缓存利用率在25%以下，说明query_cache_size设置值过大，可适当减小；如果缓存利用率在80%以上而且Qcache_lowmem_prunes > 50,说明query_cache_size可能有点小，要不就是碎片太多 | |
| 缓存碎片率 | 缓存碎片率=Qcache_free_blocks/Qcache_total_blocks * 100% 如果查询缓存碎片率超过20%，可以用FLUSH QUERY CACHE整理缓存碎片 | |
| thread_cache_size | SQL:show variables like '%thread%';缓存在Cache中的线程数量 | |
| DB已连接线程数 | SQL:show variables like '%Connections%'; | |
| 当前连接线程状态 | SQL：show status like '%thread%'; | |
| 索引缓存大小 | SQL：show cariables like '%key_buffer_size%'; | |
| 连接缓存命中率：Threads_Cache_Hit | Threads_Cache_Hit=(Connections-Threads_created)/Connections*100%。建议90%左右甚至更高 | |
| 索引缓存命中率 | key_buffer_read_hits=(1-Key_reads/Key_read_requests)*100% key_buffer_write_hits=(1-Key_writes/Key_write_requests)*100% 当然越大越好：SQL：show global status like 'key_%'; | |
| 索引缓存未命中率key_cache_miss_rate | key_cache_miss_rate=Key_reads/Key_read_requests*100% 1%即每100个索引中有1个在缓存中找不到，要直接从硬盘读取 SQL：show global status like 'key_read%';建议<0.1% | |
| 索引读取统计key_blocks | Key_blocks_unused表示未使用的缓存簇（blocks）数，Key_blocks_used表示曾经用到的最大的blocks数，如果缓存都用到了，要么增加key_buffer_size，要么就是过度索引了，把缓存占满了。比较理想的位置： SQL:show global status like 'key_blocks_u%'; | |
| 并发连接数 | max_connections：允许的最大连接数，一般来说值在500～800是比较合适的 SQL：show variables like 'max_connections'; | |
| Max_used_connections:服务器响应的最大连接数 SQL：show global status like 'Max_used_connections'; Max_used_connections/max_connections<=85% | ||
| Connections:当前连接数 SQL:show global status like 'Connections'; | ||
| max_user_connections:每个用户允许的最大连接数；是针对单个用户的连接限制，不常用 | ||
| back_log:类似于线程队列，当无法响应请求是，就让线程排队，这个值就是队列长度。SQL：show variables like 'back_log'越小越好 | ||
| max_connect_errors:默认值为10，如果受信账号错误连接次数达到10，则自动堵塞，需要flush hosts来解除 | ||
| 临时表 | SQL：show global status like 'created_tmp%'; 临时表比较大无法在内存中完成时就不得不使用磁盘文件。如果Created_tmp_tables 非常大，则可能是系统中排序操作过多，或者是表连接方式不是很优化，如果Created_tmp_disk_tables与Created_tmp_tables的占比过高，如超过10%，则需要考虑tmp_table_size这个系统参数数否设置的足够大。当然，如果系统内存有限，也就没有太好的解决办法了 | |
| MSYQL服务器对临时表的配置 | SQL：show variables where Variable_name in ('tmp_table_size','max_heap_table_size'); 当临时表空间小于max_heap_table_size时，才能全放入内存 | |
| 表扫描情况 | SQL:show global status like 'handler_read%'; show global status like 'com_select'; 表扫描率：=Handler_read_rnd_next/Com_select 如果表扫描率超过4000，说明进行了太多表扫描，很可能索引没有建好，增加read_buffer_size值回有一些好处，但最好不要超过8MB |
