1 读写比例:

show global status like 'com_select';  获得服务器启动到目前查询操作执行的次数;
show global status like 'com_insert';  获得服务器启动到目前插入操作执行的次数;
show global status like 'com_update';  获得服务器启动到目前更新操作执行的次数;
show global status like 'com_delete’;  获得服务器启动到目前删除操作执行的次数;

计算读百分比:
select concat(com_select / (com_select+com_insert+com_update+com_delete)* 100,'%');
计算写百分比:
select concat(com_insert+com_update+com_delete / (com_select+com_insert+com_update+com_delete) * 100,’%’);
通过检查数据库读写比例,可反映出应用是读密集型还是写密集型。

2  慢查询比例:
开启慢查询日志:
slow_query_log = 1 # 开启慢查询日志
log_output = FILE|TABLE # 指定日志存储方式,默认为 file
slow_query_log_file = slow-query.log # 指定慢查询日志文件位置
long_query_time = 1 # 执行及响应时间超过该参数设置的值记录日志

show global status like 'Slow_queries '; # 获得服务器启动到目前慢查询操作记录的次数;
注意,慢查询包括 select 、 update 以及 delete ,没有 insert 。
计算慢查询比例:
select concat(Slow_queries / (Com_select+Com_update+Com_delete) * 100,’%’);
通过计算慢查询比例,可反映出数据库运行效能。

3 连接数检查:
show global status like 'max_connections'; # 获得数据库运行的最大连接数            //允许的最大连接数

show global status like 'Max_used_connections'; # 获得最大一次的连接数            //最大突发并行连接数  
show global status like 'connections'; # 获得数据库运行到目前,总共被连接了多少次   //登陆的次数
 
show global status like 'Threads_connected'; # 获得当前连接数
show global status like 'Threads_running'; # 获得当前正在运行的连接数
mysql> show global status like 'Threads_connected';    //两次   mysql -uroot -p
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_connected | |
+-------------------+-------+
row in set (0.01 sec) mysql> show global status like 'Threads_running';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| Threads_running | |
+-----------------+-------+
row in set (0.00 sec)
mysql> show processlist;
+----+------+-----------+-------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+-------+---------+------+-------+------------------+
| | root | localhost | mysql | Sleep | | | NULL |
| | root | localhost | test | Query | | init | show processlist |
+----+------+-----------+-------+---------+------+-------+------------------+
rows in set (0.00 sec)

计算当前连接数的比例:
select concat(Threads_connected / max_connections *100,'%'); # 计算最大一次的连接数比例:
select concat(Max_used_connections / max_connections *100,'%');# 通过连接数检查,可得知数据库在不同时间段被请求的压力

4 线程缓存:
show global status like 'Connections'; # 获得数据库运行到目前,总共被连接了多少次
show global status like 'Threads_created'; # 获得数据库运行到目前,创建连接线程的次数
计算连接线程缓存命中率:
select concat((Connections-Threads_created) / Connections × 100,’%’);
通过计算连接线程缓存命中率,可反映出连接线程的命中情况,命中率越大越好。
如果命中率过低,则表示缓存连接线程的数量过少,可以考虑加大 thread_cache_size 的值。

5 表缓存:
show global status like 'Table_open_cache_misses'; # 新打开的表的次数。   不命中
show global status like 'Table_open_cache_hits'; # 从表缓存中拿已打开的表的次数,该状态变量 5.6 才开始存在  命中
show global status like 'Opened_tables'; # 打开表的总次数
通过已知自己数据库中有多少表,再观察 Opened_tables 的值,可以得知表缓存的数量是否合理,如果打开表的次数大于数据库中已有的表数
量,则表示 table_open_cache 的值不够,可以考虑加大。
计算表缓存的命中率:
select concat(Table_open_cache_hits /(Table_open_cache_misses + Table_open_cache_hits) * 100,’%’);
通过计算表缓存的命中率,可反映出表缓存的情况,该比例越大越好

mysql> create table ttt (a int);
Query OK, rows affected (0.22 sec) mysql> show global status like 'Table_open_cache_hits';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Table_open_cache_hits | |
+-----------------------+-------+
row in set (0.00 sec) mysql> show global status like 'Table_open_cache_misses';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Table_open_cache_misses | |
+-------------------------+-------+
row in set (0.00 sec) mysql> show global status like 'Opened_tables';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Opened_tables | |
+---------------+-------+
row in set (0.00 sec) mysql> select * from ttt; //第一次打开
Empty set (0.01 sec) mysql> show global status like 'Opened_tables'; //+1
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Opened_tables | |
+---------------+-------+
row in set (0.02 sec) mysql> show global status like 'Table_open_cache_misses'; //table缓存中没有表,丢失 +1
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Table_open_cache_misses | |
+-------------------------+-------+
row in set (0.01 sec) mysql> show global status like 'Table_open_cache_hits'; //缓存未命中,不变
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Table_open_cache_hits | |
+-----------------------+-------+
row in set (0.01 sec) mysql> select * from ttt; //在打开表
Empty set (0.00 sec) mysql> show global status like 'Table_open_cache_hits'; //表缓存命中
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Table_open_cache_hits | |
+-----------------------+-------+
row in set (0.01 sec)

6 临时表:
show global status like 'Created_tmp_disk_tables'; # 查看在磁盘上创建临时表的次数
show global status like 'Created_tmp_tables'; # 查看创建临时表的总次数,包括在内存中和磁盘。
如果发现在磁盘上创建临时表的次数过多,则表示临时表的缓存区内存不够,可以考虑加大 tmp_table_size 和 max_heap_table_size 的值。
计算在磁盘上创建临时表的比例:
select concat(Created_tmp_disk_tables / Created_tmp_tables * 100,’%’);
通过计算在磁盘上创建临时表的比例,可反映出数据库的使用临时表的情况,该比例越小越好。

7 额外的排序:
show global status like 'Sort_merge_passes'; # 在磁盘中进行额外排序的次数
show global status like 'Sort_scan'; # 通过表扫描进行排序的总次数,也就是额外排序的总次数
如果发现在磁盘上进行排序的次数过多,则表示排序缓冲区内存不够,可以考虑加大 sort_buffer_size 的值。
计算磁盘排序的比例:
select concat(Sort_merge_passes / Sort_scan * 100,'%');
通过计算在磁盘上进行额外排序的比例,可反映出数据库排序的情况,该比例越小越好。

8 binlog 缓冲:
show global status like 'Binlog_cache_disk_use'; # 在磁盘上创建临时文件用于保存 binlog 的次数
show global status like 'Binlog_cache_use'; # 缓冲 binlog 的总次数,包括 binlog 缓冲区和在磁盘上创建临时文件保存 binlog 的总次数
如果发现在磁盘上创建临时文件保存 binlog 的次数过多,则表示 binlog 缓冲区内存不够,可以考虑加大 binlog_cache_size 的值。
计算在磁盘上创建临时文件保存 binlog 的比例:
select concat(Binlog_cache_disk_use / Binlog_cache_use * 100,’%’);
通过计算在磁盘上创建临时文件保 binlog 的比例,可反映出数据库 binlog 的情况,该比例越小越好。

9 redo 日志:
select global status like 'Innodb_log_waits'; # 查看 innodb redo 日志等待缓冲区刷新的次数。
当 redo 缓冲区容纳不下事务产生的 redo 日志时,本次事务产生的 redo 日志在写入 redo 缓冲区之前就必须等待 redo 缓冲区有足够的空间才能写入。
如果发现 redo 日志等待刷新的次数过多,则表示 innodb redo 日志缓冲区的大小不够,可以考虑加大 innodb_log_buffer_size 的值。

10 InnoDB 缓存:
show global status like 'Innodb_buffer_pool_read_requests'; # 读取页的总次数
show global status like 'Innodb_buffer_pool_read'; # 从磁盘读取页的次数
如果发现从磁盘读取页的次数过多,则有可能是因为 innodb 缓冲池的大小不够,此时可以考虑加到 innodb_buffer_pool_size 的值。
计算 innodb 缓存命中率:
select concat((Innodb_buffer_pool_read_requests - Innodb_buffer_pool_read) / Innodb_buffer_pool_read_requests * 100,’%’);
通过计算 innodb 缓存命中率,可反映出 innodb 缓存的效率,该比例越大越好

MySQL的优化点总结---通过计算多种状态的百分比看MySQL的性能情况的更多相关文章

  1. MySQL分页优化中的“INNER JOIN方式优化分页算法”到底在什么情况下会生效?

    本文出处:http://www.cnblogs.com/wy123/p/7003157.html 最近无意间看到一个MySQL分页优化的测试案例,并没有非常具体地说明测试场景的情况下,给出了一种经典的 ...

  2. 【学习】016 MySQL数据库优化

    MySQL如何优化 表的设计合理化(符合3NF) 添加适当索引(index) [四种: 普通索引.主键索引.唯一索引unique.全文索引] SQL语句优化 分表技术(水平分割.垂直分割) 读写[写: ...

  3. mysql系列八、mysql数据库优化、慢查询优化、执行计划分析

    mysql的性能优化无法一蹴而就,必须一步一步慢慢来,从各个方面进行优化,最终性能就会有大的提升. 一.介绍 对mysql优化是一个综合性的技术,主要包括 表的设计合理化(符合3NF) 添加适当索引( ...

  4. 必须收藏的MySQL高性能优化实战总结!

    MySQL对于很多程序员来说,是一个非常棘手的问题,多数情况都是因为对数据库出现问题的情况和处理思路不清晰.在进行MySQL的优化之前必须要了解的就是MySQL的查询过程,很多的查询优化工作实际上就是 ...

  5. MySQL几点重要的性能指标计算和优化

    qps 每秒处理的查询数tps 每秒处理的事务数IOPS 每秒磁盘进行的I/O操作次数 一.TPS:Transactions Per Second(每秒传输的事物处理个数),即服务器每秒处理的事务数. ...

  6. MySQL架构优化实战系列1:数据类型与索引调优全解析

    一.数据类型优化 数据类型 整数   数字类型:整数和实数 tinyint(8).smallint(16).mediuint(24).int(32).bigint(64) 数字表示对应最大存储位数,如 ...

  7. MySQL SQL优化之in与range查询【转】

    本文来自:http://myrock.github.io/ 首先我们来说下in()这种方式的查询.在<高性能MySQL>里面提及用in这种方式可以有效的替代一定的range查询,提升查询效 ...

  8. mysql数据库优化(转)

    今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显.关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我们程序员需要去关注的事情.当我们去设计数据库表结构,对操作数据 ...

  9. MySQL Optimization 优化原理

    MySQL Optimization 优化原理 MySQL逻辑架构 如果能在头脑中构建一幅MySQL各组件之间如何协同工作的架构图,有助于深入理解MySQL服务器.下图展示了MySQL的逻辑架构图. ...

随机推荐

  1. Python 统计代码行

    正在学习 Python, 做了个统计代码行的功能, 参考了网上很多前辈的帖子,添加了感觉还是比较实用的功能, 只是windows下测试了,而且代码文件编码形式是 utf-8的. 如果使用其它编码形式的 ...

  2. PYTHON开发--面向对象基础入门

    面向对象 一:面向对象初级 1.思考:首先在python中,以前我们以前用到的几乎都是函数式编程,但是有时候函数式编程其中代码重复利用率太高,我们往往会把这些重复代码写进一个函数日后去调用,所以呢,今 ...

  3. C# Dispose Finalize

    比较值得参考的文档:http://www.jb51.net/article/37214.htm. .NET 的内存管理过程: 托管堆假设内存无限大,线性连续分配内存: 实际内存不够使用时,遍历托管堆对 ...

  4. Java语言基础(三) Java注释

    Java注释 Java提供了三种注释的方式: ①单行注释:// ②多行注释:/*  ...  */ ③归档(JavaDoc)注释: /** * 作者:heyiyong * 时间:2013年11月27日 ...

  5. 去大公司还是去小公司工作——要进大公司的核心部门(提升视野,锻炼技能),远离没真本事的小公司,要自我驱动 good

    去大公司还是小公司工作?这个问题问大多数 IT 人都会选择前者.如果换一个问法,去大公司还是去初创公司(Startup)工作?或许有极小一部分人能改变一下决定 对于 IT 人来说,选择到大公司工作的理 ...

  6. INDEX FAST FULL SCAN和INDEX FULL SCAN

    INDEX FULL SCAN 索引全扫描.单块读 .它扫描的结果是有序的,因为索引是有序的.它通常发生在 下面几种情况(注意:即使SQL满足以下情况 不一定会走索引全扫描) 1. SQL语句有ord ...

  7. Android日志框架darks-logs使用教程

    一.配置文件 在使用darks-logs之前,我们需要为它创建一个名叫logd.properties的配置文件.如果你是需要在JAVA或WEB上使用该组件,那么你可以像配置log4j一样将它放在cla ...

  8. 【HDOJ】1881 毕业bg

    01背包. #include <cstdio> #include <cstring> #include <cstdlib> #define MAXN 1005 ty ...

  9. [LeetCode#274]H-Index

    Problem: Given an array of citations (each citation is a non-negative integer) of a researcher, writ ...

  10. solr异常--Expected mime type application/octet-stream but got text/html.

    Exception in thread "main" org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrExce ...