代码执行很慢但是数据库很快_为什么你的SQL执行很慢

本文分析了SQL执行慢的多种原因,包括未使用索引、索引失效(如计算操作、隐式类型转换、LIKE操作、隐式编码转换、NOT IN操作)、扫描行数过多、等待锁、刷脏页和执行undo log。提出了优化策略,如正确使用索引、控制脏页刷新和理解事务对性能的影响。此外,讨论了索引设计原则,如选择区分度高的字段、利用覆盖索引和考虑唯一性。
摘要由CSDN通过智能技术生成

SQL语句执行很慢原因分析

先来回答第一个问题,如果一条SQL语句执行会很慢,会有哪些可能的原因。为了方便说明问题,这里先给出建表语句和初始化语句:

CREATE TABLE `t` ( `id` int(10) NOT NULL AUTO_INCREMENT, `a` int(10) DEFAULT NULL, `b` varchar(16) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_a` (`a`), KEY `idx_b` (`b`)) ENGINE=InnoDB;insert into t values (null, 1,'1');insert into t values (null, 2,'2');insert into t values (null, 3,'3');

1.没走索引

首先,绝大部分人都能想到的一点就是SQL语句没有走索引。明明给相关字段加了索引,可为什么就是不走索引呢?极大概率是因为索引失效了,以下场景都有可能导致索引失效。

1.1对索引字段进行了计算操作

看这个例子:

e3b1e372e3af48214c27d312a1f44552.png

为什么对索引字段进行了计算操作之后,就不会走索引了呢?

这里我们需要明白,走索引的本质其实是利用了B+树的有序性以便进行快速定位。但是对索引字段进行计算操作之后,有可能会破坏这种有序性(非线性计算),导致无法利用B+树的这一特性,因此优化器会放弃使用B+树的树搜索功能。

注意,这里要特别强调的是,这种情况下优化器只是放弃了树搜索的能力,而并不是一定会放弃走索引。什么意思呢?请继续看这个例子:

d466d257ba575b8cc007f81a3b5f9b3e.png

你看,在这个例子中,虽然依然对索引字段a做了计算操作,但是最终优化器还是走了索引idx_a。从执行计划还可以看出,优化器对该索引做了全索引扫面,且使用了覆盖索引。之所以没有选择遍历主键索引,是因为辅助索引更小,且可以利用覆盖索引。

所以,正确的姿势应该是这样的,把函数计算放在变量上:

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值