tip:作为程序员一定学习编程之道,一定要对代码的编写有追求,不能实现就完事了。我们应该让自己写的代码更加优雅,即使这会费时费力。
💕💕 推荐:体系化学习Java(Java面试专题)
文章目录
- 1、如何定位慢 SQL 问题
- 1.1、启用MySQL慢查询日志
- 1.2、分析慢查询日志
- 1.3、使用EXPLAIN分析查询计划
- 1.4、使用性能分析工具
- 2、如何针对慢 SQL 优化
- 3、建索引需要遵循什么原则
- 3.1、建索引需要遵循以下原则:
- 3.2 最左前缀原则
- 3.3、哪些情况会破坏最左前缀原则
- 4、Mysql 索引的原理
- 4.1、索引介绍和原理
- 4.2、磁盘 IO 与预读
- 5、详解 B+ 树
- 5.1、什么是 B+ 树
- 5.2、b+树的查找过程
- 5.3、b+树性质
1、如何定位慢 SQL 问题
定位慢SQL问题可以通过以下几种方法:
1.1、启用MySQL慢查询日志
在MySQL配置文件中开启慢查询日志功能,可以记录执行时间超过一定阈值的SQL语句。
# 开启MySQL慢查询日志可以通过以下步骤实现:
# 1. 编辑MySQL配置文件my.cnf(或my.ini),添加以下配置项:
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 2
# 其中, `slow_query_log` 表示是否开启慢查询日志, `slow_query_log_file` 表示慢查询日志保存的文件路径, `long_query_time` 表示执行时间超过多少秒的SQL语句会被记录到慢查询日志中。
# 2. 重启MySQL服务,使配置生效。
# 3. 查看慢查询日志,可以使用以下命令:
sudo tail -f /var/log/mysql/mysql-slow.log
# 该命令可以实时查看MySQL慢查询日志,可以按Ctrl+C退出。
# 4. 在慢查询日志中查找慢SQL语句,可以根据执行时间和执行次数等信息进行排序和过滤,找出执行时间较长的SQL语句,进一步分析和优化。
# 注意:开启慢查询日志会对MySQL性能产生一定的影响,因此建议在调试和优化阶段开启,调试结束后关闭。
1.2、分析慢查询日志
使用MySQL提供的工具或第三方工具,对慢查询日志进行分析,可以查看执行时间较长的SQL语句以及执行时间、执行次数等相关信息。
分析MySQL慢查询日志的工具有很多,以下是一些常用的工具:
-
mysqldumpslow:这是MySQL自带的一个工具,可以用来解析慢查询日志文件,并按照执行时间、执行次数等排序,方便查找慢SQL语句。
-
pt-query-digest:这是Percona Toolkit中的一个工具,可以对慢查询日志进行分析,并生成报告,包括执行时间、执行次数、索引使用情况等信息,帮助定位慢SQL问题。可以使用以下命令安装:
sudo apt-get install percona-toolkit -
MySQL Enterprise Monitor:这是MySQL官方提供的一款性能监控工具,可以实时监控MySQL的性能指标,包括慢查询、锁等问题,帮助发现和解决MySQL性能问题。
-
VividCortex:这是一款云端的MySQL性能监控工具,可以实时监控MySQL的性能指标,包括慢查询、锁等问题,提供可视化的报告和分析功能,帮助定位和解决MySQL性能问题。
具体哪种工具主要取决于具体需求和使用场景,可以根据实际情况选择合适的工具。
1.3、使用EXPLAIN分析查询计划
使用EXPLAIN语句可以查看MySQL执行SQL语句的查询计划,包括使用了哪些索引、表的连接方式等信息。可以通过分析查询计划,找出影响查询性能的因素。
EXPLAIN是MySQL的一个关键字,用于分析查询语句的执行计划,可以帮助我们优化查询性能。使用EXPLAIN需要在查询语句前加上EXPLAIN关键字,例如:
EXPLAIN SELECT * FROM table WHERE id = 1;
执行以上语句后,MySQL会返回一个执行计划,包括查询使用的索引、查询类型、扫描行数等信息,例如:
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+
| 1 | SIMPLE | table | const | PRIMARY | PRIMARY | 4 | const | 1 | Using index |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+
其中,各列的含义如下:
- id:查询的标识符,每个查询都有一个唯一的标识符。
- select_type:查询的类型,包括SIMPLE(简单查询)、PRIMARY(主键查询)、UNION(联合查询)等。
- table:查询的表名。
- type:查询的类型,包括const(常量查询)、eq_ref(唯一索引查询)、ref(非唯一索引查询)、range(范围查询)等。
- possible_keys:查询可能使用的索引。
- key:查询实际使用的索引。
- key_len:索引使用的长度。
- ref:索引使用的列。
- rows:扫描的行数。
- Extra:额外的信息,例如Using index表示使用了索引优化查询。
通过分析EXPLAIN的结果,可以判断查询语句的性能瓶颈所在,例如是否使用了索引、是否存在全表扫描等问题,进而优化查询语句,提高查询性能。
1.4、使用性能分析工具
MySQL提供了一些性能分析工具,例如 MySQL Performance Schema 和 MySQL Enterprise Monitor 等,可以实时监控MySQL的性能指标,帮助定位慢SQL问题。
MySQL Performance Schema 是 MySQL 5.5.3 及以上版本中的一个特性,用于收集 MySQL 实例的性能数据,包括 SQL 语句执行时间、锁等待时间、IO 操作等等。启用 Performance Schema 可以帮助我们更好地了解 MySQL 实例的性能瓶颈,从而进行优化。而 MySQL Enterprise Monitor 是 MySQL 提供的一个监控和管理工具,需要下载安装的,这里我就不做介绍了,感兴趣的同学可以去下载安装下,我这里重点介绍下 MySQL Performance Schema。
以下是在 MySQL 5.7 中启用 Performance Schema 的步骤:
- 修改 my.cnf 配置文件,添加以下配置项:
[mysqld]
performance_schema=ON
-
重启 MySQL 服务,使配置生效。
-
连接到 MySQL 实例,使用以下命令检查 Performance Schema 是否启用:c
SHOW VARIABLES LIKE 'performance_schema';
如果返回值为 ON,则表示 Performance Schema 已经启用。
- 使用以下命令查看 Performance Schema 中的事件:
SELECT * FROM performance_schema.events_statements_summary_by_digest;
以上命令将返回 Performance Schema 中所有 SQL 语句的执行时间、执行次数、平均执行时间等信息。
注意:启用 Performance Schema 后会对 MySQL 实例的性能产生一定的影响,因此在生产环境中需要谨慎使用。可以根据实际情况选择启用或禁用 Performance Schema。
2、如何针对慢 SQL 优化
优化 SQL 语句的方法包括以下几个方面:
-
添加索引:索引是提高 SQL 查询效率的重要手段。通过添加索引,可以加快查询速度,减少全表扫描的时间。但是,索引也会占用额外的磁盘空间和内存,过多的索引会影响数据库性能。因此,在添加索引时需要根据实际情况进行分析和优化。
-
修改查询条件:通过修改查询条件,可以减少查询数据的数量,从而提高查询效率。例如,可以添加限制条件、修改排序方式、合并查询语句等。
-
分解查询语句:如果查询语句比较复杂,可以考虑将查询语句分解为多个简单的查询语句。通过分解查询语句,可以减少查询数据的数量,提高查询效率。
-
优化子查询:子查询是查询效率较低的一种查询方式。如果查询中包含子查询,可以考虑将子查询转化为连接查询或者其他方式。
-
避免使用通配符:通配符查询效率较低,应该尽量避免使用通配符查询。如果必须使用通配符查询,可以通过添加索引和限制查询范围等方式来提高查询效率。
-
使用优化器:MySQL 自带的优化器可以自动优化查询语句,提高查询效率。可以通过设置优化器参数来调整优化器的行为,从而达到优化查询效率的目的。
需要注意的是,在优化 SQL 语句时,应该根据实际情况进行分析和优化,避免过度优化和不必要的优化。同时,优化 SQL 语句需要进行测试和验证,确保优化后的 SQL 语句能够正确地执行,并且性能得到了提升。
其实在生产过程中,我们通过设置一个好的索引就能解决大多数慢 SQL,如果索引也优化不了了,那就只能业务上做拆分了,通过代码去优化,在大数据场景下冗余、物化视图、预查询、缓存等等手段也可以用于解决查询慢的问题。
3、建索引需要遵循什么原则
3.1、建索引需要遵循以下原则:
- 索引应该被建立在经常用于查询的列上。通过建立索引可以加快查询速度,但是过多的索引会影响数据库的性能,因此需要根据实际情况进行分析和优化。
- 索引应该被建立在唯一性较高的列上。例如,主键列和唯一性约束列都是适合建立索引的列。
- 索引应该被建立在数据量较大的表上。对于数据量比较小的表,建立索引的效果并不明显。
- 索引应该被建立在经常被用于连接的列上。例如,连接两个表的列应该被建立索引,可以加快连接操作的速度。
- 索引应该被建立在经常被用于排序和分组的列上。通过建立索引可以加快排序和分组操作的速度。
- 避免建立过多的索引。过多的索引会占用额外的磁盘空间和内存,影响数据库的性能。因此,需要根据实际情况进行分析和优化,避免建立过多的索引。
- 避免在大文本和二进制列上建立索引。这些列的数据量比较大,建立索引会占用大量的磁盘空间和内存,影响数据库的性能。
需要注意的是,索引不是建的越多越好,也不是什么字段建索引都能有很好的效果,而且在建立索引时,需要根据实际情况进行分析和优化,避免过度索引和不必要的索引。同时,需要定期对索引进行优化和维护,确保索引的有效性和性能。
3.2 最左前缀原则
要让 SQL 能命中索引,需要遵循最左前缀原则,最左前缀原则需要遵循以下情况:
- 查询条件必须包含索引的最左前缀列,才能利用索引进行查询。
- 查询条件中可以包含索引的前缀列,但不能包含索引的后缀列。
- 查询条件中可以包含索引的非前缀列,但是会导致索引失效,无法利用索引进行查询。
下面举例说明:
假设有一个表student,包含以下列:id, name, age, gender,其中id列为主键列,同时创建了一个联合索引idx_name_age_gender(name, age, gender)。
- 查询条件包含索引的最左前缀列
例如,查询name为’张三’的学生信息,可以使用如下SQL语句:
SELECT * FROM student WHERE name = '张三';
该查询条件包含了索引的最左前缀列name,可以利用索引进行查询。
- 查询条件包含索引的前缀列,但不能包含索引的后缀列
例如,查询name为’张三’且age为18岁的学生信息,可以使用如下SQL语句:
SELECT * FROM student WHERE name = '张三' AND age = 18;
该查询条件包含了索引的前缀列name和age,可以利用索引进行查询。
但是,如果查询条件中只包含age列,不能利用索引进行查询,需要进行全表扫描。例如:
SELECT * FROM student WHERE age = 18;
- 查询条件中包含索引的非前缀列,导致索引失效
例如,查询gender为’男’的学生信息,可以使用如下SQL语句:
SELECT * FROM student WHERE gender = '男';
该查询条件包含了索引的非前缀列gender,会导致索引失效,需要进行全表扫描。
3.3、哪些情况会破坏最左前缀原则
以下情况会破坏最左前缀原则:
- 查询条件中包含了索引列的后缀列,而不是前缀列。这种情况下,索引无法被利用,需要进行全表扫描。
- 查询条件中包含了索引列的非前缀列。这种情况下,索引会失效,需要进行全表扫描。
- 查询条件中使用了函数或表达式,导致无法利用索引。例如:
SELECT * FROM table WHERE YEAR(date_column) = 2021;
这种情况下,YEAR(date_column)是一个表达式,无法利用索引。
- 查询条件中使用了通配符(如%),导致无法利用索引。例如:
SELECT * FROM table WHERE name LIKE '张%';
这种情况下,LIKE '张%'中的通配符%会导致无法利用索引。
- 查询条件中使用了OR操作符,导致无法利用索引。例如:
SELECT * FROM table WHERE col1 = 'value1' OR col2 = 'value2';
这种情况下,OR操作符会导致无法利用索引。
总之,破坏最左前缀原则的情况主要是查询条件与索引的匹配度不高,导致无法利用索引进行查询。因此,在设计索引和查询时,需要注意遵循最左前缀原则,选择合适的索引列和查询条件,以充分利用索引提高查询效率。
4、Mysql 索引的原理
4.1、索引介绍和原理
MySQL索引是一种数据结构,用于提高查询效率。它通过将索引列的值与行的物理位置关联起来,可以快速地定位满足查询条件的行。MySQL支持多种类型的索引,包括B-tree索引、哈希索引、全文索引等。
1.B-tree索引是MySQL中最常用的索引类型。它是一种平衡树结构,可以快速地定位满足查询条件的行。B-tree索引的原理是将索引列的值按照一定的顺序存储在B-tree中,每个节点包含多个索引值和对应的物理位置指针,可以通过二分查找快速定位到目标行。B-tree索引不仅可以用于等值查询,还可以用于范围查询和排序等操作。
2.哈希索引是一种基于哈希表的索引类型。它将索引列的值通过哈希函数转换为哈希值,并将哈希值与对应的物理位置关联起来。哈希索引的查询效率非常高,但是它只支持等值查询,不支持范围查询和排序等操作。此外,哈希索引的缺点是哈希冲突较多时,查询效率会降低。
3.全文索引是一种用于全文搜索的索引类型。它可以对文本类型的列进行索引,并支持全文搜索、模糊搜索等操作。全文索引的原理是将文本分词后,将每个词作为索引值存储在倒排索引中,倒排索引记录了每个词在哪些行中出现过。查询时,可以通过倒排索引快速定位到包含目标词的行。
除了以上三种常见的索引类型,MySQL还支持空间索引、前缀索引、多列索引等类型的索引。索引的使用需要根据具体的业务场景和查询需求进行选择和设计,合理的索引可以大大提高查询效率,但是过多或不合理的索引也会降低写入性能和占用存储空间。
4.2、磁盘 IO 与预读
磁盘IO是指计算机从磁盘读取或写入数据的操作。由于磁盘的读写速度比内存慢很多,因此磁盘IO通常是系统性能的瓶颈之一。为了提高磁盘IO的效率,可以使用磁盘预读技术。
磁盘预读是指在读取一个数据块时,顺便将其后续的若干个数据块也读取到内存中,以便于后续的访问。这样可以减少磁盘IO的次数,提高数据访问的效率。磁盘预读一般分为两种方式:顺序预读和随机预读。
顺序预读是指在读取一个数据块时,将其后续的若干个数据块也顺序地读取到内存中。这种方式适用于顺序访问的场景,如扫描整个表或索引。在MySQL中,InnoDB存储引擎会自动进行顺序预读,以提高查询效率。
随机预读是指在读取一个数据块时,将其后续的若干个数据块也读取到内存中,但是读取的顺序是随机的。这种方式适用于随机访问的场景,如使用索引进行查询。在MySQL中,可以通过设置innodb_read_io_threads参数来控制随机预读的线程数。
虽然磁盘预读可以提高磁盘IO的效率,但是也会占用更多的内存资源。因此,在使用磁盘预读时需要根据具体的业务场景和硬件配置进行权衡,以达到最优的性能和资源利用率。
5、详解 B+ 树
5.1、什么是 B+ 树
B+树是一种常用的数据结构,广泛应用于数据库和文件系统等领域。它是一种多路搜索树,每个节点可以存储多个关键字和对应的数据指针。B+树具有以下特点:
- 多路搜索:B+树的每个节点可以存储多个关键字和对应的数据指针,因此可以减少树的高度,提高搜索效率。
- 平衡性:B+树是一种平衡树,所有叶子节点的深度相同,因此可以保证搜索效率的稳定性。
- 顺序访问:B+树的叶子节点组成一个有序链表,可以支持范围查询和排序等操作。
- 磁盘友好:B+树的节点大小通常和磁盘块大小相同,因此可以减少磁盘IO次数,提高磁盘访问效率。
B+树的结构和操作可以分为以下几个部分:
- 根节点:B+树的根节点是一个特殊的节点,通常包含少量的关键字和指向子节点的指针。
- 叶子节点:B+树的叶子节点存储数据指针和关键字,通常按照关键字的大小顺序组成一个有序链表。
- 内部节点:B+树的内部节点存储关键字和指向子节点的指针,通常按照关键字的大小顺序组织。
- 插入操作:B+树的插入操作通常从根节点开始,沿着关键字的大小顺序找到合适的叶子节点,将新的关键字和数据指针插入到叶子节点中,并根据需要调整树的结构。
- 删除操作:B+树的删除操作通常从根节点开始,沿着关键字的大小顺序找到合适的叶子节点,删除指定的关键字和数据指针,并根据需要调整树的结构。
- 查找操作:B+树的查找操作通常从根节点开始,沿着关键字的大小顺序找到合适的叶子节点,根据关键字查找对应的数据指针。
B+树是一种高效的数据结构,可以支持快速的插入、删除和查找操作,尤其适用于需要频繁访问磁盘的场景。在数据库和文件系统等领域,B+树已经成为一种常用的数据结构,广泛应用于各种系统中。
5.2、b+树的查找过程
B+树的查找过程通常从根节点开始,根据关键字的大小顺序沿着树的分支向下查找,直到找到包含目标关键字的叶子节点。具体步骤如下:
- 从根节点开始,比较目标关键字和当前节点中的关键字,根据大小关系选择相应的子节点。
- 如果当前节点是叶子节点,则在叶子节点中查找目标关键字,如果找到则返回对应的数据指针;否则表示目标关键字不存在于树中,返回空值。
- 如果当前节点是内部节点,则重复步骤1和步骤2,直到找到包含目标关键字的叶子节点。
在B+树中,所有叶子节点按照关键字的大小顺序组成一个有序链表,因此可以支持范围查询和排序等操作。如果需要查找一个范围内的数据,则可以在有序链表中顺序遍历,直到找到范围内的所有数据为止。
5.3、b+树性质
B+树是一种常用的索引结构,具有以下性质:
- 根节点至少有两个子节点。
- 每个非叶子节点有k个子节点,其中ceil(m/2) <= k <= m,m为B+树的阶数。
- 每个节点中包含k-1个关键字,且关键字按照升序排列。
- 所有叶子节点都在同一层,且包含所有关键字的信息和指向对应数据的指针。
- 非叶子节点的关键字仅用于索引,不保存数据记录的信息。
- 所有节点的子树指针或者指向叶子节点的指针都存储在同一层中,即每个节点的子节点数相同。
- 叶子节点之间通过指针相连,形成一个有序链表,可以支持范围查询和排序等操作。
B+树的这些性质保证了B+树的高效性和可靠性,使其成为一种非常适合数据库索引的数据结构。
💕💕 本文由激流原创,首发于CSDN博客,博客主页 https://blog.csdn.net/qq_37967783?spm=1010.2135.3001.5421
💕💕喜欢的话记得点赞收藏啊