前言我们在使用MySQL查询数据的时候,总会遇见没有正确使用到索引的情况。 这里我们列举几种常见的,搜索条件使用了索引列却没有走索引的场景。 (以下测试均在MySQL8.0.28中完成,且所有数据均为脚本随机生成)数据表结构CREATE TABLE `student_info` ( `id` bigint UNSIGNED NOT NULL AUTO_INCREMENT, `school
因为优化器还不够强大,还有很多限制,或者因为一些逻辑原因,分析认为SQL走索引比较好,但是事实却无法正确利用索引。这时候,除了给ORACLE需要的统计信息之外,写的SQL必须要能够给优化器足够多的额外有效信息,让优化器能够选择更好的执行计划。要让给优化器正确使用上需要的索引,要考虑两点:1).如何避免优化器的限制 2).根据业务数据特点改写SQL语句     &nb
转载 2023-07-22 20:08:29
142阅读
 分析案例:1.走rule很快,但是收集了执行计划后却很慢SQL> create table test(id int); 表已创建。 SQL> insert into test select 1 from dba_objects; 已创建49883行。 SQL> commit; 提交完成。 SQL> insert into test select 2 from u
转载 2024-03-14 09:38:23
71阅读
字段说明: type列,连接类型。一个好的SQL语句至少要达到range级别。杜绝出现all级别。 possible_keys: 表示查询时可能使用的索引。 key列,使用到的索引名。如果没有选择索引,值是NULL。可以采取强制索引方式。 key_len列,索引长度。 rows列,扫描行数。估算的找到所需的记录所需要读取的行数。 extra列,详细说明。注意,常见的不太友好的值,如下:Using
转载 2023-07-05 10:51:06
131阅读
说明在MySQL中,并不是你建立了索引,并且你在SQL中使用到了该列,MySQL就肯定会使用到那些索引的,有一些情况很可能在你知不觉中,你就“成功的避开了”MySQL的所有索引索引列参与计算如果where条件中age列中使用了计算,则不会使用该索引。如果需要计算,千万不要计算到索引列,想方设法让其计算到表达式的另一边去。SELECT `sname` FROM `t_stu` WHERE `ag
mysql in走索引可能的情况 在MySQL 5.7.3以及之前的版本中,eq_range_index_dive_limit的默认值为10,之 后的版本默认值为200。所以如果大家采用的是5.7.3以及之前的版本的话,很容易采用索引统计数据而 不是index dive的方式来计算查询成本。当你的查询中使用到了IN查询,但是却实际没有
转载 2023-06-10 21:21:47
278阅读
工作中,经常遇到这样的问题,我明明在MySQL表上面加了索引,为什么执行SQL查询的时候却没有用到索引?同一条SQL有时候查询用到了索引,有时候却没用到索引,这是咋回事?原因可能是索引失效了,失效的原因有以下几种,看你有没有踩过类似的坑?1. 数据准备:有这么一张用户表,在name字段上建个索引:CREATE TABLE `user` ( `id` int NOT NULL AUTO_INCR
      今天早上查看网站,发现非常慢!进linux 用top查看,发现MySQL cpu到了100%。开始怀疑是mysql性能的问题,不会10万条数据就卡成这样吧?虽然我的linux是在服务器上放了个虚拟机,但也不至于10万条记录挂啊? 网上找了一大把文章,my.cnf也设置了,我虚拟机内存是2G,将key_buf设置成512M 还是卡。非常郁
转载 2024-03-21 21:33:11
45阅读
生命无罪,健康万岁,我是laity。我曾七次鄙视自己的灵魂:第一次,当它本可进取时,却故作谦卑;第二次,当它在空虚时,用爱欲来填充;第三次,在困难和容易之间,它选择了容易;第四次,它犯了错,却借由别人也会犯错来宽慰自己;第五次,它自由软弱,却把它认为是生命的坚韧;第六次,当它鄙夷一张丑恶的嘴脸时,却不知那正是自己面具中的一副;第七次,它侧身于生活的污泥中,虽不甘心,却又畏首畏尾。SQL语句优化1
转载 2023-10-27 02:42:46
85阅读
在一些营业场景中,会运用NOT EXISTS语句确保返回数据不存在于特定鸠合,部份同事会发明NOT EXISTS有些场景机能较差,以至有些网上谣言说”NOT EXISTS走索引”,哪关于NOT EXISTS语句,我们怎样优化呢?以本日优化的SQL为例,优化前SQL为:SELECT count(1) FROM t_monitor m WHERE NOT exists ( SELECT 1 FROM
Mysql索引的作用 以及 走索引的情况写一下mysql索引吧,提及索引失效的原因的时候,当初只记得两个,虽然笔记有,当时的脑子可能是这样的。温故而知新,看一遍不如写一遍 1. 为什么要创建索引没有加索引的表就像 一本 没有目录的字典,而索引相当于目录, 能大大加速查询的速度。1.1 如何创建索引可以看到索引的类型有B-Tree 和 Hash Hash索引先说Hash, 若是对Java的
转载 2023-10-22 17:55:45
145阅读
一、 条件字段使用函数select count(*) from tradelog where ABS(a)=7;如果对字段做了函数计算,就用不上索引了,这是MySQL的规定。为什么会失效呢?对索引字段做函数操作,可能会破坏索引值的有序性,因此优化器就决定放弃走树搜索功能。1.1 隐式类型转换假设id类型为varchar(10),且建立了索引select * from tradelog where
转载 2023-09-28 19:51:39
443阅读
“ 我是小羊同学,一个兢兢业业的程序员”背景:有一天同事突然问我为什么加了in查询就突然变慢了、小羊脱口而出:“in走索引!” 于是就炸开了锅:in走索引!怎么可能? 但是在小羊同学脑子里、in走索引为什么早就根深固体了?原因暂且不说,我们来探索真像。环境:Windows10、MySQL5.7、可视化工具navicat。场景1:当IN中的取值只有一个主键时我们只
背景有客户提出一个问题。 一个类似这样的SQL语句,select count(id) from 为什么执行计划用全表扫,不用索引。id列上有主键。分析test=# explain (analyze, buffers ) select count(id) from t1; QUERY PLAN --
【问题场景】有个30多行的大SQL执行效率特别慢,问题集中在一个子查询上,开始没有建索引,可是发现索引都创建了,还是走索引ql语句描述:有三张表需要关联查询,关联关系如下A表B表 关联 A.col = B.idC表 关联 B.col = C.id问题出在 B表 关联 A.col = B.id,为啥?执行计划就是走id主键,C表 关联 B.col = C.id都可以正常走【解决思路】1、尝试单表
转载 2023-05-23 13:12:52
869阅读
在自己测试索引成功场景时,可能出现符合索引规则,但是却不走索引的情况,这是因为mysql有自己的优化规则,比如数据量很少的时候,走索引反而更快,具体可自行百度,全值匹配(索引最佳)explain select * from user where name = 'zhangsan' and age = 20 and pos = 'cxy' and phone = '18730658760';和索引
查询在什么时候走索引参考回答主要三种情况1 >不满足走索引的条件, 常见的情况有1.1 >不满足最左匹配原则1.2 >查询条件使用了函数1.3>or 操作有一个字段没有索引1.4 >使用 like 条件以 % 开头2 >走索引效率低于全表扫描, 常见的情况有2.1 >查询条件对 null 做判断, 而 null 的值很多2.2 >一个字段区分度很小
转载 2023-09-01 11:48:59
182阅读
SQL优化器简介 基于规则的优化器 。总是使用索引 。总是从驱动表开始(from子句最右边的表) 。只有在不可避免的情况下,才使用全表扫描 。任何索引都可以 基于成本的优化器 。需要表、索引统计资料 Analyze table customer compute statistics; Analyze table customer estimate statistics sample 5000 r
因为优化器还不够强大,还有很多限制,或者因为一些逻辑原因,分析认为SQL走索引比较好,但是事实却无法正确利用索引。这时候,除了给ORACLE需要的统计信息之外,写的SQL必须要能够给优化器足够多的额外有效信息,让优化器能够选择更好的执行计划。 要让给优化器正确使用上需要的索引,要考虑两点: 1).如何避免优化器的限制 2).根据业务数据特点改写SQL语句
转载 2024-05-12 15:29:37
60阅读
在一些业务场景中,会使用NOT EXISTS语句确保返回数据不存在于特定集合,部分同事会发现NOT EXISTS有些场景性能较差,甚至有些网上谣言说”NOT EXISTS走索引”,哪对于NOT EXISTS语句,我们如何优化呢?以今天优化的SQL为例,优化前SQL为:SELECT count(1) FROM t_monitor m WHERE NOT exists ( SELECT 1 FROM
  • 1
  • 2
  • 3
  • 4
  • 5