您当前的位置:首页 > 电脑百科 > 数据库 > MYSQL

MySQL查询慢别怪索引,没准是这些原因导致的

时间:2022-07-12 16:03:52  来源:  作者:dbaplus社群

我熟练应用ctrl c和ctrl v 开发curd代码好多年了。

 

MySQL查询为什么会慢,关于这个问题,在实际开发经常会遇到,而面试中,也是个高频题。

 

遇到这种问题,我们一般也会想到是因为索引。

 

那除开索引之外,还有哪些因素会导致数据库查询变慢呢?

 

有哪些操作,可以提升mysql的查询能力呢?

 

今天这篇文章,我们就来聊聊会导致数据库查询变慢的场景有哪些,并给出原因和解决方案。

 

一、数据库查询流程

 

我们先来看下,一条查询语句下来,会经历哪些流程。

 

比如我们有一张数据库表:

 

CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `name` varchar(100) NOT NULL DEFAULT '' COMMENT '名字',
  `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄',
  `gender` int(8) NOT NULL DEFAULT '0' COMMENT '性别',
  PRIMARY KEY (`id`),
  KEY `idx_age` (`age`),
  KEY `idx_gender` (`gender`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

 

我们平常写的应用代码(go或C++之类的),这时候就叫客户端了。

 

客户端底层会带着账号密码,尝试向mysql建立一条TCP长链接。

 

mysql的连接管理模块会对这条连接进行管理。

 

建立连接后,客户端执行一条查询sql语句。比如:

 

select * from user where gender = 1 and age = 100;

 

客户端会将sql语句通过网络连接给mysql。

 

mysql收到sql语句后,会在分析器中先判断下SQL语句有没有语法错误,比如select,如果少打一个l,写成slect,则会报错You have an error in your SQL syntax; 。这个报错对于我这样的手残党来说可以说是很熟悉了。

 

接下来是优化器,在这里会根据一定的规则选择该用什么索引。

 

之后,才是通过执行器去调用存储引擎的接口函数。

MySQL查询慢别怪索引,没准是这些原因导致的

 

Mysql架构

 

存储引擎类似于一个个组件,它们才是mysql真正获取一行行数据并返回数据的地方,存储引擎是可以替换更改的,既可以用不支持事务的MyISAM,也可以替换成支持事务的Innodb。这个可以在建表的时候指定。比如:

 

CREATE TABLE `user` (
  ...
) ENGINE=InnoDB;

 

现在最常用的是InnoDB

 

我们就重点说这个。

 

InnoDB中,因为直接操作磁盘会比较慢,所以加了一层内存提提速,叫buffer pool,这里面,放了很多内存页,每一页16KB,有些内存页放的是数据库表里看到的那种一行行的数据,有些则是放的索引信息。

MySQL查询慢别怪索引,没准是这些原因导致的

 

bufferPool与磁盘

 

查询SQL到了InnoDB中。会根据前面优化器里计算得到的索引,去查询相应的索引页,如果不在buffer pool里则从磁盘里加载索引页。再通过索引页加速查询,得到数据页的具体位置。如果这些数据页不在buffer pool中,则从磁盘里加载进来。

 

这样我们就得到了我们想要的一行行数据。

MySQL查询慢别怪索引,没准是这些原因导致的

 

索引页与磁盘页的关系

 

最后将得到的数据结果返回给客户端。

 

二、慢查询分析

 

如果上面的流程比较慢的话,我们可以通过开启profiling看到流程慢在哪。

 

mysql> set profiling=ON;
Query OK, 0 rows affected, 1 warning (0.00 sec)




mysql> show variables like 'profiling';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| profiling     | ON    |
+---------------+-------+
1 row in set (0.00 sec)

 

然后正常执行sql语句。

 

这些SQL语句的执行时间都会被记录下来,此时你想查看有哪些语句被记录下来了,可以执行 show profiles;

 

mysql> show profiles;
+----------+------------+---------------------------------------------------+
| Query_ID | Duration   | Query                                             |
+----------+------------+---------------------------------------------------+
|        1 | 0.06811025 | select * from user where age>=60                  |
|        2 | 0.00151375 | select * from user where gender = 2 and age = 80  |
|        3 | 0.00230425 | select * from user where gender = 2 and age = 60  |
|        4 | 0.00070400 | select * from user where gender = 2 and age = 100 |
|        5 | 0.07797650 | select * from user where age!=60                  |
+----------+------------+---------------------------------------------------+
5 rows in set, 1 warning (0.00 sec)

 

关注下上面的query_id,比如select * from user where age>=60对应的query_id是1,如果你想查看这条SQL语句的具体耗时,那么可以执行以下的命令。

 

mysql> show profile for query 1;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000074 |
| checking permissions | 0.000010 |
| Opening tables       | 0.000034 |
| init                 | 0.000032 |
| System lock          | 0.000027 |
| optimizing           | 0.000020 |
| statistics           | 0.000058 |
| preparing            | 0.000018 |
| executing            | 0.000013 |
| Sending data         | 0.067701 |
| end                  | 0.000021 |
| query end            | 0.000015 |
| closing tables       | 0.000014 |
| freeing items        | 0.000047 |
| cleaning up          | 0.000027 |
+----------------------+----------+
15 rows in set, 1 warning (0.00 sec)

 

通过上面的各个项,大家就可以看到具体耗时在哪。比如从上面可以看出Sending data的耗时最大,这个是指执行器开始查询数据并将数据发送给客户端的耗时,因为我的这张表符合条件的数据有好几万条,所以这块耗时最大,也符合预期。

 

一般情况下,我们开发过程中,耗时大部分时候都在Sending data阶段,而这一阶段里如果慢的话,最容易想到的还是索引相关的原因。

 

三、索引相关原因

 

索引相关的问题,一般能用explAIn命令帮助分析。通过它能看到用了哪些索引,大概会扫描多少行之类的信息。

 

mysql会在优化器阶段里看下选择哪个索引,查询速度会更快。

 

一般主要考虑几个因素,比如:

 

  • 选择这个索引大概要扫描多少行(rows);

 

  • 为了把这些行取出来,需要读多少个16kb的页;

 

  • 走普通索引需要回表,主键索引则不需要,回表成本大不大?

 

回到show profile中提到的sql语句,我们使用explain select * from user where age>=60 分析一下。

MySQL查询慢别怪索引,没准是这些原因导致的

 

explain sql

 

上面的这条语句,使用的type为ALL,意味着是全表扫描possible_keys是指可能用得到的索引,这里可能使用到的索引是为age建的普通索引,但实际上数据库使用的索引是在key那一列,是NULL。也就是说这句sql不走索引,全表扫描。

 

这个是因为数据表里,符合条件的数据行数(rows)太多,如果使用age索引,那么需要将它们从age索引中读出来,并且age索引是普通索引,还需要回表找到对应的主键才能找到对应的数据页。算下来还不如直接走主键划算。于是最终选择了全表扫描。

 

当然上面只是举了个例子,实际上,mysql执行sql时,不用索引或者用的索引不符合我们预期这件事经常发生,索引失效的场景有很多,比如用了不等号,隐式转换等,这个相信大家背八股文的时候也背过不少了,我也不再赘述。

 

聊两个生产中容易遇到的问题吧。

 

1、索引不符合预期

 

实际开发中有些情况比较特殊,比如有些数据库表一开始数据量小,索引少,执行sql时,确实使用了符合你预期的索引。但随时时间边长,开发的人变多了,数据量也变大了,甚至还可能会加入一些其他重复多余的索引,就有可能出现用着用着,用到了不符合你预期的其他索引了。从而导致查询突然变慢。

 

这种问题,也好解决,可以通过force index指定索引。比如:

MySQL查询慢别怪索引,没准是这些原因导致的

 

force index指定索引

 

通过explain可以看出,加了force index之后,sql就选用了idx_age这个索引了。

 

2、走了索引还是很慢

 

有些sql,用explain命令看,明明是走索引的,但还是很慢。一般是两种情况:

 

第一种是索引区分度太低,比如网页全路径的url链接,这拿来做索引,一眼看过去全都是同一个域名,如果前缀索引的长度建得不够长,那这走索引跟走全表扫描似的,正确姿势是尽量让索引的区分度更高,比如域名去掉,只拿后面URI部分去做索引。

MySQL查询慢别怪索引,没准是这些原因导致的

 

索引前缀区分度太低

 

第二种是索引中匹配到的数据太大,这时候需要关注的是explain里的rows字段了。

 

它是用于预估这个查询语句需要查的行数的,它不一定完全准确,但可以体现个大概量级。

 

当它很大时,一般常见的是下面几种情况。

 

如果这个字段具有唯一的属性,比如电话号码等,一般是不应该有大量重复的,那可能是你代码逻辑出现了大量重复插入的操作,你需要检查下代码逻辑,或者需要加个唯一索引限制下。

 

如果这个字段下的数据就是会很大,是否需要全部拿?如果不需要,加个limit限制下。如果确实要拿全部,那也不能一次性全拿,今天你数据量小,可能一次取一两万都没啥压力,万一哪天涨到了十万级别,那一次性取就有点吃不消了。你可能需要分批次取,具体操作是先用order by id排序一下,拿到一批数据后取最大id作为下次取数据的起始位置。

 

四、连接数过小

 

索引相关的原因我们聊完了,我们来聊聊,除了索引之外,还有哪些因素会限制我们的查询速度的。

 

我们可以看到,mysql的server层里有个连接管理,它的作用是管理客户端和mysql之间的长连接。

 

正常情况下,客户端与server层如果只有一条连接,那么在执行sql查询之后,只能阻塞等待结果返回,如果有大量查询同时并发请求,那么后面的请求都需要等待前面的请求执行完成后,才能开始执行。

MySQL查询慢别怪索引,没准是这些原因导致的

 

连接过少会导致sql阻塞

 

因此很多时候我们的应用程序,比如go或JAVA这些,会打印出sql执行了几分钟的日志,但实际上你把这条语句单独拎出来执行,却又是毫秒级别的。这都是因为这些sql语句在等待前面的sql执行完成。

 

怎么解决呢?

 

如果我们能多建几条连接,那么请求就可以并发执行,后面的连接就不用等那么久了。

MySQL查询慢别怪索引,没准是这些原因导致的

 

增加连接可以加快执行sql

 

而连接数过小的问题,受数据库和客户端两侧同时限制。

 

1、数据库连接数过小

 

Mysql的最大连接数默认是100, 最大可以达到16384。

 

可以通过设置mysql的max_connections参数,更改数据库的最大连接数。

 

mysql> set global max_connections= 500;
Query OK, 0 rows affected (0.00 sec)




mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 500   |
+-----------------+-------+
1 row in set (0.00 sec)

 

上面的操作,就把最大连接数改成了500。

 

2、应用侧连接数过小

 

数据库连接大小是调整过了,但貌似问题还是没有变化?还是有很多sql执行达到了几分钟,甚至超时?

 

那有可能是因为你应用侧(go,java写的应用,也就是mysql的客户端)的连接数也过小。

 

应用侧与mysql底层的连接,是基于TCP协议的长链接,而TCP协议,需要经过三次握手和四次挥手来实现建连和释放。如果我每次执行sql都重新建立一个新的连接的话,那就要不断握手和挥手,这很耗时。所以一般会建立一个长连接池,连接用完之后,塞到连接池里,下次要执行sql的时候,再从里面捞一条连接出来用,非常环保。

MySQL查询慢别怪索引,没准是这些原因导致的

 

连接池原理

 

我们一般写代码的时候,都会通过第三方的orm库来对数据库进行操作,而成熟的orm库,百分之一千万都会有个连接池。

 

而这个连接池,一般会有个大小。这个大小就控制了你的连接数最大值,如果说你的连接池太小,都还没有数据库的大,那调了数据库的最大连接数也没啥作用。

 

一般情况下,可以翻下你使用的orm库的文档,看下怎么设置这个连接池的大小,就几行代码的事情,改改就好。比如Go语言里的gorm里是这么设置的

 

func Init() {
  db, err := gorm.Open(mysql.Open(conn), config)
    sqlDB, err := db.DB()
    // SetMaxIdleConns 设置空闲连接池中连接的最大数量
    sqlDB.SetMaxIdleConns(200)
    // SetMaxOpenConns 设置打开数据库连接的最大数量
    sqlDB.SetMaxOpenConns(1000)
}

 

五、buffer pool太小

 

连接数是上去了,速度也提升了。

 

曾经遇到过面试官会追问,有没有其他办法可以让速度更快呢?

 

那必须要眉头紧锁,假装思考,然后说:有的。

 

我们在前面的数据库查询流程里,提到了进了innodb之后,会有一层内存buffer pool,用于将磁盘数据页加载到内存页中,只要查询到buffer pool里有,就可以直接返回,否则就要走磁盘IO,那就慢了。

 

也就是说,如果我的buffer pool 越大,那我们能放的数据页就越多,相应的,sql查询时就更可能命中buffer pool,那查询速度自然就更快了。

 

可以通过下面的命令查询到buffer pool的大小,单位是Byte。

 

mysql> show global variables like 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.01 sec)

 

也就是128Mb。

 

如果想要调大一点。可以执行:

 

mysql> set global innodb_buffer_pool_size = 536870912;
Query OK, 0 rows affected (0.01 sec)




mysql> show global variables like 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 536870912 |
+-------------------------+-----------+
1 row in set (0.01 sec)

 

这样就把buffer pool增大到512Mb了。

 

但是吧,如果buffer pool大小正常,只是别的原因导致的查询变慢,那改buffer pool毫无意义。

 

但问题又来了。

 

怎么知道buffer pool是不是太小了?

 

这个我们可以看buffer pool的缓存命中率。

MySQL查询慢别怪索引,没准是这些原因导致的

 

查看buffer pool命中率

 

通过 show status like 'Innodb_buffer_pool_%';可以看到跟buffer pool有关的一些信息。

 


Innodb_buffer_pool_read_requests表示读请求的次数。

 

Innodb_buffer_pool_reads 表示从物理磁盘中读取数据的请求次数。

 

所以buffer pool的命中率就可以这样得到:

 

buffer pool 命中率 = 1 - (Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests) * 100%

 

比如我上面截图里的就是,1 - (405/2278354) = 99.98%。可以说命中率非常高了。

 

一般情况下buffer pool命中率都在99%以上,如果低于这个值,才需要考虑加大innodb buffer pool的大小。

 

当然,还可以把这个命中率做到监控里,这样半夜sql变慢了,早上上班还能定位到原因,就很舒服。

 

六、还有哪些骚操作?

 

前面提到的是在存储引擎层里加入了buffer pool用于缓存内存页,这样可以加速查询。

 

那同样的道理,server层也可以加个缓存,直接将第一次查询的结果缓存下来,这样下次查询就能立刻返回,听着挺美的。

 

按道理,如果命中缓存的话,确实是能为查询加速的。但这个功能限制很大,其中最大的问题是只要数据库表被更新过,表里面的所有缓存都会失效,数据表频繁的更新,就会带来频繁的缓存失效。所以这个功能只适合用于那些不怎么更新的数据表。

 

另外,这个功能在8.0版本之后,就被干掉了。所以这功能用来聊聊天可以,没必要真的在生产中使用啊。

MySQL查询慢别怪索引,没准是这些原因导致的

 

查询缓存被删除

 

七、总结

 

  • 数据查询过慢一般是索引问题,可能是因为选错索引,也可能是因为查询的行数太多。

 

  • 客户端和数据库连接数过小,会限制sql的查询并发数,增大连接数可以提升速度。

 

  • innodb里会有一层内存buffer pool用于提升查询速度,命中率一般>99%,如果低于这个值,可以考虑增大buffer pool的大小,这样也可以提升速度。

 

  • 查询缓存(query cache)确实能为查询提速,但一般不建议打开,因为限制比较大,并且8.0以后的Mysql里已经将这个功能干掉了。

 

作者丨小白

来源丨公众号:小白debug(ID:xiaobaidebug)

dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn



Tags:MySQL查询   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,不构成投资建议。投资者据此操作,风险自担。如有任何标注错误或版权侵犯请与我们联系,我们将及时更正、删除。
▌相关推荐
实用性极强的MySQL查询优化策略
前言在程序上线运行一段时间后,一旦数据量上去了,或多或少会感觉到系统出现延迟、卡顿等现象,出现这种问题,就需要程序员或架构师进行系统调优工作了。其中,大量的实践经验表明,调...【详细内容】
2023-12-25  Search: MySQL查询  点击:(103)  评论:(0)  加入收藏
MySQL查询语句揭秘:无限层次父子关系查询,轻松解锁数据维度!
在当今的数据驱动时代,对于处理具有层次结构的数据非常重要。例如,组织结构、分类层次、评论回复等都可以被看作是无限层次的父子关系。针对这类数据的查询通常需要一种特殊的...【详细内容】
2023-08-23  Search: MySQL查询  点击:(277)  评论:(0)  加入收藏
教你进行MySQL查询操作
大家好,我是IT共享者,人称皮皮。今天给大家讲讲MySQL中的查询操作。前言我们在以前,大概学了一下如何通过命令创建数据库,创建表等基本操作。但是实际上啊,至少在我的实际工作...【详细内容】
2023-03-29  Search: MySQL查询  点击:(187)  评论:(0)  加入收藏
MySQL查询慢别怪索引,没准是这些原因导致的
我熟练应用ctrl c和ctrl v 开发curd代码好多年了。 mysql查询为什么会慢,关于这个问题,在实际开发经常会遇到,而面试中,也是个高频题。 遇到这种问题,我们一般也会想到是因为索引...【详细内容】
2022-07-12  Search: MySQL查询  点击:(352)  评论:(0)  加入收藏
MySQL查询是否安装&删除
1、查找以前是否装有mysql命令:rpm -qa|grep -i mysql 可以看到如下图的所示:说明之前安装了: MySQL-client-5.5.25a-1.rhel5 MySQL-server-5.5.25a-1.rhel52、停止mysql服务...【详细内容】
2022-03-10  Search: MySQL查询  点击:(360)  评论:(0)  加入收藏
mysql查询小总结
SQL Select 语句完整的执行顺序:1、from 获取不同数据库表的数据;2、where 子句跟随筛选条件,对数据进行过滤;3、group by 子句可以将数据根据分组字段进行分组处理;4、可使用聚...【详细内容】
2021-04-27  Search: MySQL查询  点击:(313)  评论:(0)  加入收藏
mysql查询太慢,我们如何进行性能优化?
今天给大家分享的是MySQL性能优化,也是大数据开发指南MySQL的最后一部分。性能优化对于老刘来说,是必须掌握的一个手段,如何让自己变得更加优秀,这块内容还是好好看看!本篇内容相...【详细内容】
2021-02-07  Search: MySQL查询  点击:(340)  评论:(0)  加入收藏
MySQL查询合理使用索引(Index):别让你的数据库负重前行
在冯小刚冯导作为导演拍摄的《天下无贼》中有一句经典台词,那就是出自葛优之口:21世纪什么最贵?人才!从这句话说出到现在,已经16年过去了,那么在现在这个大数据时代,什么最贵呢?那...【详细内容】
2020-12-30  Search: MySQL查询  点击:(263)  评论:(0)  加入收藏
如何将MySQL查询性能优化到极致?
写在前面MySQL数据库在互联网行业使用的比较多,有些小伙伴可能会认为MySQL数据库比较小,存储不了很多的数据。其实,这些小伙伴是真的不了解MySQL。MySQL的小不是说使用MySQL存...【详细内容】
2020-11-05  Search: MySQL查询  点击:(325)  评论:(0)  加入收藏
mysql查询语句很慢?可以试试几种SQL优化
连接查询的优化无论什么数据库,多表连接的查询成本都是比较高的,因此对于高并发应用,应该尽量减少有连接的查询,多表连接的个数不要超过4张表。一般数据量少的时候,连接开小不...【详细内容】
2019-12-17  Search: MySQL查询  点击:(439)  评论:(0)  加入收藏
▌简易百科推荐
MySQL 核心模块揭秘
server 层会创建一个 SAVEPOINT 对象,用于存放 savepoint 信息。binlog 会把 binlog offset 写入 server 层为它分配的一块 8 字节的内存里。 InnoDB 会维护自己的 savepoint...【详细内容】
2024-04-03  爱可生开源社区    Tags:MySQL   点击:(10)  评论:(0)  加入收藏
MySQL 核心模块揭秘,你看明白了吗?
为了提升分配 undo 段的效率,事务提交过程中,InnoDB 会缓存一些 undo 段。只要同时满足两个条件,insert undo 段或 update undo 段就能被缓存。1. 关于缓存 undo 段为了提升分...【详细内容】
2024-03-27  爱可生开源社区  微信公众号  Tags:MySQL   点击:(18)  评论:(0)  加入收藏
MySQL:BUG导致DDL语句无谓的索引重建
对于5.7.23之前的版本在评估类似DDL操作的时候需要谨慎,可能评估为瞬间操作,但是实际上线的时候跑了很久,这个就容易导致超过维护窗口,甚至更大的故障。一、问题模拟使用5.7.22...【详细内容】
2024-03-26  MySQL学习  微信公众号  Tags:MySQL   点击:(14)  评论:(0)  加入收藏
从 MySQL 到 ByteHouse,抖音精准推荐存储架构重构解读
ByteHouse是一款OLAP引擎,具备查询效率高的特点,在硬件需求上相对较低,且具有良好的水平扩展性,如果数据量进一步增长,可以通过增加服务器数量来提升处理能力。本文将从兴趣圈层...【详细内容】
2024-03-22  字节跳动技术团队    Tags:ByteHouse   点击:(29)  评论:(0)  加入收藏
MySQL自增主键一定是连续的吗?
测试环境:MySQL版本:8.0数据库表:T (主键id,唯一索引c,普通字段d)如果你的业务设计依赖于自增主键的连续性,这个设计假设自增主键是连续的。但实际上,这样的假设是错的,因为自增主键不...【详细内容】
2024-03-10    dbaplus社群  Tags:MySQL   点击:(15)  评论:(0)  加入收藏
准线上事故之MySQL优化器索引选错
1 背景最近组里来了许多新的小伙伴,大家在一起聊聊技术,有小兄弟提到了MySQL的优化器的内部策略,想起了之前在公司出现的一个线上问题,今天借着这个机会,在这里分享下过程和结论...【详细内容】
2024-03-07  转转技术  微信公众号  Tags:MySQL   点击:(33)  评论:(0)  加入收藏
MySQL数据恢复,你会吗?
今天分享一下binlog2sql,它是一款比较常用的数据恢复工具,可以通过它从MySQL binlog解析出你要的SQL,并根据不同选项,可以得到原始SQL、回滚SQL、去除主键的INSERT SQL等。主要...【详细内容】
2024-02-22  数据库干货铺  微信公众号  Tags:MySQL   点击:(54)  评论:(0)  加入收藏
如何在MySQL中实现数据的版本管理和回滚操作?
实现数据的版本管理和回滚操作在MySQL中可以通过以下几种方式实现,包括使用事务、备份恢复、日志和版本控制工具等。下面将详细介绍这些方法。1.使用事务:MySQL支持事务操作,可...【详细内容】
2024-02-20  编程技术汇    Tags:MySQL   点击:(56)  评论:(0)  加入收藏
MySQL数据库如何生成分组排序的序号
经常进行数据分析的小伙伴经常会需要生成序号或进行数据分组排序并生成序号。在MySQL8.0中可以使用窗口函数来实现,可以参考历史文章有了这些函数,统计分析事半功倍进行了解。...【详细内容】
2024-01-30  数据库干货铺  微信公众号  Tags:MySQL   点击:(56)  评论:(0)  加入收藏
mysql索引失效的场景
MySQL中索引失效是指数据库查询时无法有效利用索引,这可能导致查询性能显著下降。以下是一些常见的MySQL索引失效的场景:1.使用非前导列进行查询: 假设有一个复合索引 (A, B)。...【详细内容】
2024-01-15  小王爱编程  今日头条  Tags:mysql索引   点击:(88)  评论:(0)  加入收藏
站内最新
站内热门
站内头条