MySQL中主要有4种方式可以分析数据库性能,分别是慢查询日志,profile,Com_xxx和explain。

慢查询日志

先用下面命令查询慢查询日志是否开启,

show variables like 'slow_query_log';

# 一般默认都是以下结果
+----------------+-------+
| Variable_name | Value |
+----------------+-------+
| slow_query_log | OFF |
+----------------+-------+
  • 若结果为 ON,表示慢查询日志已开启;若为 OFF,则需要手动开启。但是一般慢查询日志是默认不开启的,需要手动开启,因为需要指定指标,也就是多慢的SQL才算慢SQL。

临时开启(重启 MySQL 后失效):

# 开启慢查询日志
set global slow_query_log = 'ON';
# 设置一个时间,超过这个时间的查询都会被认为是慢查询,会记录到慢查询日志里,单位是秒(s)
set global long_query_time = 2;

永久开启:

linux环境下只需要改一下/etc/my.cnf配置文件,在里面加入如下两行配置

# 0:关闭慢查询日志 1:开启慢查询日志
slow_query_log = 1
# 指定日志文件路径(可选,不选则有默认路径)
slow_query_log_file = /var/log/mysql/slow.log
# 设置一个时间,超过这个时间的查询都会被认为是慢查询,会记录到慢查询日志里,单位是秒(s)
long_query_time = 2
# 是否记录未使用索引的查询(1表示开启,0表示关闭,默认关闭)
log_queries_not_using_indexes = 1

关键是参数【slow_query_log】和【long_query_time】一定要设置,配置完毕保存后然后使用【systemctl restart mysqld】在Linux命令行重启MySQL即可。此时慢查询的日志会记录到文件里,如果没有配置路径,使用到了默认路径,可以查询一下文件位置:

SHOW VARIABLES LIKE 'slow_query_log_file';

# 得到结果可能如下
+---------------------+-------------------------------+
| Variable_name | Value |
+---------------------+-------------------------------+
| slow_query_log_file | /var/lib/mysql/hostname-slow.log |
+---------------------+-------------------------------+

然后去指定目录直接查看log文件即可。


profile

使用下列命令查看profiling是否开启

show variables like 'profiling';

# 默认是关闭的,一般查询结果如下
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| profiling | OFF |
+---------------+-------+

需要手动开启。

临时开启profiling(重启 MySQL 后失效):

在SQL执行窗口设定参数

set profiling = 1;

永久开启:

在/etc/my.cnf文件中加入如下配置

profiling = 1

要记得修改过/etc/my.cnf文件以后要重启mysql。

此时随便执行几条sql,然后再来查询一下profile。

# 此时为了测试我创建了一个表
# 执行下面几条查询
select * from test where id = 2;
select * from test where id = 1;
select * from test; # 执行下行语句,查询Query记录
show profiles;
# 得到如下结果,Query列是查询语句,Duration是执行消耗的时间,Query_ID是记录ID
+----------+------------+------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+------------------------------------+
| 1 | 0.00029275 | select * from test where id = 2 |
| 2 | 0.00022375 | select * from test where id = 1 |
| 3 | 0.00020425 | select * from test |
+----------+------------+------------------------------------+ # 如果想要对某一条SQL进行分析,比如这里Query_ID为1的记录消耗时间最长,想要看一下具体情况,可以使用如下命令
show profile for query 1; # 得到如下结果
+--------------------------------+----------+
| Status | Duration |
+--------------------------------+----------+
| starting | 0.000115 |
| Executing hook on transaction | 0.000008 |
| starting | 0.000009 |
| checking permissions | 0.000005 |
| Opening tables | 0.000037 |
| init | 0.000004 |
| System lock | 0.000007 |
| optimizing | 0.000009 |
| statistics | 0.000045 |
| preparing | 0.000011 |
| executing | 0.000009 |
| end | 0.000002 |
| query end | 0.000002 |
| waiting for handler commit | 0.000007 |
| closing tables | 0.000007 |
| freeing items | 0.000010 |
| cleaning up | 0.000007 |
+--------------------------------+----------+ # 可以看到开始时间,执行时间,打开表的时间,优化时间,准备时间,关闭表的时间等参数
# 如果SQL查询很慢的话则可以从这里分析原因

Com_%

# 执行下列命令
show status like 'Com_%'; # 得到结果格式如下
+-------------------------------------+-------+
| Variable_name | Value |
+-------------------------------------+-------+
| Com_admin_commands | 0 |
| Com_assign_to_keycache | 0 |
| Com_alter_db | 0 |
| Com_alter_event | 0 |
| Com_alter_function | 0 |
| Com_alter_instance | 0 |
| Com_alter_procedure | 0 |
| Com_alter_resource_group | 0 |
| Com_alter_server | 0 |
| Com_alter_table | 0 |
| Com_alter_tablespace | 0 |
| Com_alter_user | 0 |
| Com_alter_user_default_role | 0 |
| Com_analyze | 0 |
| Com_begin | 0 |
| Com_binlog | 0 |
| Com_call_procedure | 0 |
| Com_change_db | 1 |
| Com_change_master | 0 |
| Com_change_repl_filter | 0 |
| Com_change_replication_source | 0 |
| Com_check | 0 |
| Com_checksum | 0 |
| Com_clone | 0 |
| Com_commit | 0 |
| Com_create_db | 0 |
| Com_create_event | 0 |
| Com_create_function | 0 |
| Com_create_index | 0 |
| Com_create_procedure | 0 |
| Com_create_role | 0 |
| Com_create_server | 0 |
| Com_create_table | 0 |
| Com_create_resource_group | 0 |
| Com_create_trigger | 0 |
| Com_create_udf | 0 |
| Com_create_user | 0 |
| Com_create_view | 0 |
| Com_create_spatial_reference_system | 0 |
| Com_dealloc_sql | 0 |
| Com_delete | 0 |
| Com_delete_multi | 0 |
| Com_do | 0 |
| Com_drop_db | 0 |
| Com_drop_event | 0 |
| Com_drop_function | 0 |
| Com_drop_index | 0 |
| Com_drop_procedure | 0 |
| Com_drop_resource_group | 0 |
| Com_drop_role | 0 |
| Com_drop_server | 0 |
| Com_drop_spatial_reference_system | 0 |
| Com_drop_table | 0 |
| Com_drop_trigger | 0 |
| Com_drop_user | 0 |
| Com_drop_view | 0 |
| Com_empty_query | 0 |
| Com_execute_sql | 0 |
| Com_explain_other | 0 |
| Com_flush | 0 |
| Com_get_diagnostics | 0 |
| Com_grant | 0 |
| Com_grant_roles | 0 |
| Com_ha_close | 0 |
| Com_ha_open | 0 |
| Com_ha_read | 0 |
| Com_help | 0 |
| Com_import | 0 |
| Com_insert | 0 |
| Com_insert_select | 0 |
| Com_install_component | 0 |
| Com_install_plugin | 0 |
| Com_kill | 0 |
| Com_load | 0 |
| Com_lock_instance | 0 |
| Com_lock_tables | 0 |
| Com_optimize | 0 |
| Com_preload_keys | 0 |
| Com_prepare_sql | 0 |
| Com_purge | 0 |
| Com_purge_before_date | 0 |
| Com_release_savepoint | 0 |
| Com_rename_table | 0 |
| Com_rename_user | 0 |
| Com_repair | 0 |
| Com_replace | 0 |
| Com_replace_select | 0 |
| Com_reset | 0 |
| Com_resignal | 0 |
| Com_restart | 0 |
| Com_revoke | 0 |
| Com_revoke_all | 0 |
| Com_revoke_roles | 0 |
| Com_rollback | 0 |
| Com_rollback_to_savepoint | 0 |
| Com_savepoint | 0 |
| Com_select | 8 |
| Com_set_option | 1 |
| Com_set_password | 0 |
| Com_set_resource_group | 0 |
| Com_set_role | 0 |
| Com_signal | 0 |
| Com_show_binlog_events | 0 |
| Com_show_binlogs | 0 |
| Com_show_charsets | 0 |
| Com_show_collations | 0 |
| Com_show_create_db | 0 |
| Com_show_create_event | 0 |
| Com_show_create_func | 0 |
| Com_show_create_proc | 0 |
| Com_show_create_table | 0 |
| Com_show_create_trigger | 0 |
| Com_show_databases | 2 |
| Com_show_engine_logs | 0 |
| Com_show_engine_mutex | 0 |
| Com_show_engine_status | 0 |
| Com_show_events | 0 |
| Com_show_errors | 0 |
| Com_show_fields | 1 |
| Com_show_function_code | 0 |
| Com_show_function_status | 0 |
| Com_show_grants | 0 |
| Com_show_keys | 0 |
| Com_show_master_status | 0 |
| Com_show_open_tables | 0 |
| Com_show_plugins | 0 |
| Com_show_privileges | 0 |
| Com_show_procedure_code | 0 |
| Com_show_procedure_status | 0 |
| Com_show_processlist | 0 |
| Com_show_profile | 5 |
| Com_show_profiles | 1 |
| Com_show_relaylog_events | 0 |
| Com_show_replicas | 0 |
| Com_show_slave_hosts | 0 |
| Com_show_replica_status | 0 |
| Com_show_slave_status | 0 |
| Com_show_status | 2 |
| Com_show_storage_engines | 0 |
| Com_show_table_status | 0 |
| Com_show_tables | 2 |
| Com_show_triggers | 0 |
| Com_show_variables | 3 |
| Com_show_warnings | 0 |
| Com_show_create_user | 0 |
| Com_shutdown | 0 |
| Com_replica_start | 0 |
| Com_slave_start | 0 |
| Com_replica_stop | 0 |
| Com_slave_stop | 0 |
| Com_group_replication_start | 0 |
| Com_group_replication_stop | 0 |
| Com_stmt_execute | 0 |
| Com_stmt_close | 0 |
| Com_stmt_fetch | 0 |
| Com_stmt_prepare | 0 |
| Com_stmt_reset | 0 |
| Com_stmt_send_long_data | 0 |
| Com_truncate | 0 |
| Com_uninstall_component | 0 |
| Com_uninstall_plugin | 0 |
| Com_unlock_instance | 0 |
| Com_unlock_tables | 0 |
| Com_update | 0 |
| Com_update_multi | 0 |
| Com_xa_commit | 0 |
| Com_xa_end | 0 |
| Com_xa_prepare | 0 |
| Com_xa_recover | 0 |
| Com_xa_rollback | 0 |
| Com_xa_start | 0 |
| Com_stmt_reprepare | 0 |
| Compression | OFF |
| Compression_algorithm | |
| Compression_level | 0 |
+-------------------------------------+-------+ # 重点查看4个参数的值,Com_insert,Com_delete,Com_update,Com_select的参数。因为我没有执行增删改操作,所以都是0,刚刚又查询了几次记录,这边的Com_select已经到8了,代表当前已经执行过8次select操作,0次insert,0次delete,0次update。

在需要分析增删改查操作到底是增删改比较多还是查询比较多的时候可以使用这个方式查询相关记录的执行情况,分析某个业务到底是查询比较多呢还是更新比较多,从而可以更好地对系统架构进行把控。


explain

# 对需要执行的sql分析执行计划,假如要分析下面这条查询语句
select * from tb_user where id=1; # 语法如下
explain select * from test where id=1;
# 其实就是在查询语句前加上explain关键字,insert,update和delete语句前也可以加上进行分析执行计划
# 得到结果格式如下 +----+-------------+---------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+---------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| 1 | SIMPLE | tb_user | NULL | const | PRIMARY | PRIMARY | 4 | const | 1 | 100.00 | NULL |
+----+-------------+---------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
# 需要关注id列
# 相同的 id 表示同一查询块。
# id 越大,执行优先级越高。
# id 为 NULL 表示是 UNION 结果的合并操作。
# -----------------------------------------------------
# 需要关注type列,其中type列的介绍和性能如下(性能从高到低排列)
# NULL:直接查询,不进行表操作,例如select 1 + 1;
# system:表中只有一行数据(系统表)。
# const:通过主键或唯一索引查找一行数据。
# eq_ref:通过唯一索引关联表(多表 JOIN 时,每行只匹配一行)。
# ref:通过非唯一索引查找数据。
# range:使用索引范围扫描。
# index:全索引扫描(扫描索引树,不访问数据行)。
# ALL:全表扫描(性能最差)。
# -----------------------------------------------------
# 需要关注possible_keys列和key列
# possible_keys代表可能用到的索引,key就是实际用到的索引,从这里可以分析索引是不是没有用到或者失效了
# 优化的时候要尽量让没有使用到索引的语句使用索引
# -----------------------------------------------------
# 需要关注key_len
# 如果用到了单列索引,则key_len是一个固定值
# 如果用到了联合索引,key_len的值可能会因为部分索引失效而导致key_len的值不一样,可以通过这一列判断联合索引是否全部生效。
# -----------------------------------------------------
# 需要关注rows列,记录的是MySQL预估需要扫描的行数。
# 行数越少,性能越好,如果值很大,可能需要优化索引或查询条件。
# -----------------------------------------------------
# 需要关注filtered列
# filtered= Server层过滤后的行数/存储引擎层返回的行数 ×100%
# 值越小,说明存储引擎层已经过滤了更多不满足条件的数据,Server 层只需处理少量数据。
# -----------------------------------------------------
# 重点关注Extra列,其中可能出现的值如下:
# Using where:使用了 WHERE 条件过滤数据。
# Using index:使用了覆盖索引(无需回表)。
# Using temporary:使用了临时表(性能较差)。
# Using filesort:使用了文件排序(性能较差)。
# Using join buffer:使用了 JOIN 缓冲区(多表 JOIN 时)。
# Impossible WHERE:WHERE 条件永远为假(无结果)。
# 需要注意尽可能避免Using temporary和Using filesort,以及Impossible WHERE。

MySQL中怎么分析性能?的更多相关文章

  1. mysql中影响数据库性能的因素讲解

    mysql中影响数据库性能的因素讲解 在本篇文章中我们给大家讲述了mysql中影响性能的因素以及相关知识点内容,有兴趣的朋友参考下 关于数据库性能的故事 面试时多多少少会讲到数据库上的事情,“你对数据 ...

  2. mysql中的SQL_CACHE(性能更优化)

    mysql中的sql_cache是个容易忽视的地方,要 使用的话,必须先设置query_cache_size, 以及设置query_cache_type ,其中 query_cache_type 这个 ...

  3. MySQL中如何分析查询语句

    Oracle中有explain for,mysql中也有同样的功能,那便是explain,举例如下: mysql> explain select (case (select count(*) f ...

  4. mysql中explain看性能

    select distinct col_name from table where a=X and b=Y and date(time)='xx-xx-xx';执行时间 27.9772 秒 expla ...

  5. mysql中正则表达式的使用

    mysql中正则表达式的性能要高于like,所以这里总结一下正则表达式的使用. 正则表达式的模式及其含义: 下面举例说明其用法: 建表student: create table student(id ...

  6. MySQL中使用SHOW PROFILE命令分析性能的用法整理(配合explain效果更好,可以作为优化周期性检查)

    这篇文章主要介绍了MySQL中使用show profile命令分析性能的用法整理,show profiles是数据库性能优化的常用命令,需要的朋友可以参考下   show profile是由Jerem ...

  7. mysql中in和exists二者的区别和性能影响

    mysql查询语句in和exists二者的区别和性能影响 还记得一次面试中被人问到in 和 exists的区别,当然只是草草做答,现在来做下分析. mysql中的in语句是把外表和内表作hash 连接 ...

  8. mysql中slow query log慢日志查询分析

    在mysql中slow query log是一个非常重要的功能,我们可以开启mysql的slow query log功能,这样就可以分析每条sql执行的状态与性能从而进行优化了. 一.慢查询日志 配置 ...

  9. [转]Mysql explain用法和性能分析

    本文转自:http://blog.csdn.net/haifu_xu/article/details/16864933  from  @幸福男孩 MySQL中EXPLAIN解释命令是显示mysql如何 ...

  10. MySQL中的latch(闩锁)详解——易产生的问题以及原因分析

    Latch 什么是latch: 锁是数据库系统区别与文件系统的一个关键特性.锁机制用于管理对共享资源的并发访问.Innodb存储引擎在行级别上对表数据上锁,这固然不错.但是Innodb也会在多个地方使 ...

随机推荐

  1. IM开发快速入门(二):什么是IM系统的实时性?

    本文在编写时参考了博客作者"鹿呦呦"和在线课程"即时消息技术剖析与实战"的相关资料,一并表示感谢. 1.引言 随着移动互联网络的发展,IM技术的应用已经不仅限于 ...

  2. 百度统一socket长连接组件从0到1的技术实践

    本文由百度消息中台团队分享,引用自百度Geek说,原题"百度iOS端长连接组件建设及应用实践",为了帮助理解,本文有修订和改动. 1.引言 在过去的十年里,移动端互联网技术飞速发展 ...

  3. 为什么在 Windows 下用 Ctrl+Z 退出 Python 而 Linux 下用 Ctrl+D 呢?

    打开我们的命令行,输入 python ,我们会进入 python 的交互模式. 当我们想退出 python ,返回我们的 shell 时,你将如何退出? 如上,两个行之有效的方法是输入 exit() ...

  4. 【Java 温故而知新系列】基础知识-02 数据基本类型

    1.Java基本数据类型 Java语言是强类型语言,对于每一种数据都定义了明确的具体的数据类型,在内存中分配了不同大小的内存空间. 基本数据类型 数值型:整数类型(byte,short,int,lon ...

  5. Python多分类Logistic回归详解与实践

    在机器学习中,Logistic回归是一种基本但非常有效的分类算法.它不仅可以用于二分类问题,还可以扩展应用于多分类问题.本文将详细介绍如何使用Python实现一个多分类的Logistic回归模型,并给 ...

  6. Solution Set - “伸手向着拉格朗日点作别”

    目录 0.「UR #9」「UOJ #133」电路手动分析 1.「UR #9」「UOJ #134」App 管理器 2.「UR #10」「UOJ #152」汉诺塔 3.「UNR #2」「UOJ #312」 ...

  7. Solution Set -「Public NOIP Round #3 (Div. 1)」

    \(\mathscr{A}\sim\) 移除石子   Tags:「A.构造」「C.细节」   "显然" 直接按 \((x,y)\) 二元组排序后两两组成正方形! 喜提 \(90\t ...

  8. python基础学习6和7

    模块类与对象 模块 内置模块 time, random, os, json 第三方模块 requests, pandas, numpy,.... 自定义模块 xxx.py 常见的内置模块 hashli ...

  9. K_V键值存储对比

    memcached-键值存储 redis-键值存储 RocksDB-键值存储 KeyDB-键值存储 DynamoDB-键值存储 levelDB-键值存储 etcd-键值存储 Redis与其他数据库对比 ...

  10. Kotlin基础语法