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. 注册中心如何选型?Eureka、Zookeeper、Nacos怎么选

    这是小卷对分布式系统架构学习的第9篇文章,第8篇时只回答了注册中心的工作原理的内容,面试官的第二个问题还没回答,今天再来讲讲各个注册中心的原理,以及区别,最后如何进行选型 上一篇文章:如何设计一个注册 ...

  2. Solution Set -「NOI Simu.」2022.07.21

    \(\mathscr{Summary}\)   有意思的是, 难度诈骗居然在我身上打出了暴击.   (首先还是吐槽一下 \(5\text h\) 的模拟赛因为早读和早课变成 \(4\text h\) ...

  3. 【YashanDB知识库】导入数据时报错:YAS-00008 type convert error:literal does not match format string

    本文内容来自YashanDB官网,原文内容请见 https://www.yashandb.com/newsinfo/7901522.html?templateId=1718516 现象 将数据通过SQ ...

  4. shell脚本中的逻辑判断

    shell脚本中也可以实现逻辑判断. 案例4:shell脚本中的逻辑判断 如果你学过C或者其他语言,相信你不会对if 陌生,在shell脚本中我们同样可以使用if逻辑判断.在shell中if判断的基本 ...

  5. H5移动端开发注意事项

    1.安卓浏览器看背景图片,有些设备会模糊. 用同等比例的图片在PC机上很清楚,但是手机上很模糊,原因是什么呢? 经过研究,是devicePixelRatio作怪,因为手机分辨率太小,如果按照分辨率来显 ...

  6. 文章学习:基于AVX-512指令集的同态加密算法中大整数运算性能优化与突破

    学习文章:英特尔×同态科技 | 基于AVX-512指令集的同态加密算法中大整数运算性能优化与突破 文章 人工智能的安全隐患 ChatGPT的成功大部分来源于海量的数据支撑和丰富的数据维度,基于13亿参 ...

  7. cmake-4

    cmake-4学习,参考 cmake构建c++项目快速入门2-1 cmake构建c++项目快速入门2-2 了解 cmake的工作原理: Windows下用cmake编译cmake (1)先下载cmak ...

  8. linux:redis

    查询: 链接 redis初了解 是一个 "开源.免费" 的高性能的 key - value 的数据库 安装 yum添加epel源 yum install epel-release ...

  9. 字节流:FileInputStream和FileOutputStream的使用

    /** * 测试FileInputStream和FileOutputStream的使用 * * 结论: * 1. 对于文本文件(.txt,.java,.c,.cpp),使用字符流处理 * 2. 对于非 ...

  10. Spaghetti pg walkthrough Intermediate

    nmap ┌──(root㉿kali)-[~] └─# nmap -p- -A 192.168.170.160 Starting Nmap 7.94SVN ( https://nmap.org ) a ...