说明

在MySQL中,并不是你建立了索引,并且你在SQL中使用到了该列,MySQL就肯定会使用到那些索引的,有一些情况很可能在你不知不觉中,你就“成功的避开了”MySQL的所有索引。

索引列参与计算

如果where条件中age列中使用了计算,则不会使用该索引。如果需要计算,千万不要计算到索引列,想方设法让其计算到表达式的另一边去。

    SELECT `sname` FROM `t_stu` WHERE `age`=20;       -- 会使用索引
SELECT `sname` FROM `t_stu` WHERE `age`+10=30; -- 不会使用索引!!因为所有索引列参与了计算
SELECT `sname` FROM `t_stu` WHERE `age`=30-10; -- 会使用索引

索引列使用了函数

同样的道理,索引列使用了函数,一样会导致相同的后果

SELECT `sname` FROM `stu` WHERE concat(`sname`,'abc') ='Jaskeyabc';   -- 不会使用索引,因为使用了函数运算,原理与上面相同
SELECT `sname` FROM `stu` WHERE `sname`=concat('Jaskey','abc'); -- 会使用索引

索引列使用了Like %XXX

SELECT * FROM `houdunwang` WHERE `uname` LIKE '前缀%' -- 走索引
SELECT * FROM `houdunwang` WHERE `uname` LIKE '%后缀' -- 扫描全表,不走索引

所以当需要搜索email列中.com结尾的字符串而email上希望走索引时候,可以考虑数据库存储一个反向的内容reverse_email

SELECT * FROM `table` WHERE `reverse_email` LIKE REVERSE('%.com'); -- 走索引

  注:以上如果你使用REVERSE(email) = REVERSE(’%.com’),一样得不到你想要的结果,因为你在索引列email列上使用了函数,MySQL不会使用该列索引
同样的,索引列上使用正则表达式也不会走索引。

字符串列与数字直接比较

这是一个坑,假设有一张表,里面的a列是一个字符char类型,且a上建立了索引,你用它与数字类型做比较判断的话:

CREATE TABLE `t1` (`a` char());
SELECT * FROM `t1` WHERE `a`='' -- 走索引
SELECT * FROM `t2` WHERE `a`= -- 字符串和数字比较,不走索引!

但是如果那个表那个列是一个数字类型,拿来和字符类型的做比较,则不会影响到使用索引

CREATE TABLE `t2` (`b` int);
SELECT * FROM `t2` WHERE `b`='1' -- 虽然b是数字类型,和'1'比较依然走索引

但是,无论如何,这种额外的隐式类型转换都是开销,而且由于有字符和数字比就不走索引的情况,故建议避免一切隐式类型转换

尽量避免 OR 操作

select * from dept where dname='jaskey' or loc='bj' or deptno=45
--如果条件中有or,即使其中有条件带索引也不会使用。换言之,就是要求使用的所有字段,都必须建立索引

所以除非每个列都建立了索引,否则不建议使用OR,在多列OR中,可以考虑用UNION 替换

select * from dept where dname='jaskey' union
select * from dept where loc='bj' union
select * from dept where deptno=

ORDER BY 操作

在ORDER BY操作中,排序的列同时也在WHERE中时,MYSQL将无法使用索引;

MySQL索引通常是被用于提高WHERE条件的数据行匹配或者执行联结操作时匹配其它表的数据行的搜索速度。

MySQL也能利用索引来快速地执行ORDER BY和GROUP BY语句的排序和分组操作。

通过索引优化来实现MySQL的ORDER BY语句优化:

1、ORDER BY的索引优化。如果一个SQL语句形如:

SELECT [column1],[column2],…. FROM [TABLE] ORDER BY [sort];
在[sort]这个栏位上建立索引就可以实现利用索引进行order by 优化。

2、WHERE + ORDER BY的索引优化,形如:

SELECT [column1],[column2],…. FROM [TABLE] WHERE [columnX] = [value] ORDER BY [sort];
建立一个联合索引(columnX,sort)来实现order by 优化。

注意:如果columnX对应多个值,如下面语句就无法利用索引来实现order by的优化
SELECT [column1],[column2],…. FROM [TABLE] WHERE [columnX] IN ([value1],[value2],…) ORDER BY[sort];

3、WHERE+ 多个字段ORDER BY

SELECT * FROM [table] WHERE uid=1 ORDER x,y LIMIT 0,10;
建立索引(uid,x,y)实现order by的优化,比建立(x,y,uid)索引效果要好得多。

MySQL Order By不能使用索引来优化排序的情况
* 对不同的索引键做 ORDER BY :(key1,key2分别建立索引)
SELECT * FROM t1 ORDER BY key1, key2;
* 在非连续的索引键部分上做 ORDER BY:(key_part1,key_part2建立联合索引;key2建立索引)
SELECT * FROM t1 WHERE key2=constant ORDER BY key_part2;
* 同时使用了 ASC 和 DESC:(key_part1,key_part2建立联合索引)
SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 ASC;
* 用于搜索记录的索引键和做 ORDER BY 的不是同一个:(key1,key2分别建立索引)
SELECT * FROM t1 WHERE key2=constant ORDER BY key1;
* 如果在WHERE和ORDER BY的栏位上应用表达式(函数)时,则无法利用索引来实现order by的优化
SELECT * FROM t1 ORDER BY YEAR(logindate) LIMIT 0,10;

特别提示:

1>mysql一次查询只能使用一个索引。如果要对多个字段使用索引,建立复合索引。
2>在ORDER BY操作中,MySQL只有在排序条件不是一个查询条件表达式的情况下才使用索引。

 

Offset Limit 操作

存在性能问题的方式

SELECT * FROM myTable ORDER BY `id` LIMIT 1000000, 30

写出这样SQL语句的人肯定心里是这样想的:MySQL数据库会直接定位到符合条件的第1000000位,然后再取30条数据。
然而,实际上MySQL不是这样工作的。

LIMIT 1000000, 30 的意思是:扫描满足条件的1000030行,扔掉前面的1000000行,然后返回最后的30行。

mysql 的 limit 给分页带来了极大的方便,但数据偏移量一大,limit 的性能就急剧下降。

以下是两条查询语句,都是取10条数据,但性能就相去甚远

 

所以不能简单的使用 limit 语句实现数据分页。

探究

为什么 offset 偏大之后 limit 查找会变慢?这需要了解 limit 操作是如何运作的,以下面这句查询为例:

select * from table_name limit 10000,10

这句 SQL 的执行逻辑是
1.从数据表中读取第N条数据添加到数据集中
2.重复第一步直到 N = 10000 + 10
3.根据 offset 抛弃前面 10000 条数
4.返回剩余的 10 条数据

显然,导致这句 SQL 速度慢的问题出现在第二步!这前面的 10000 条数据完全对本次查询没有意义,但是却占据了绝大部分的查询时间!如何解决?首先我们得了解为什么数据库为什么会这样查询。

首先,数据库的数据存储并不是像我们想象中那样,按表按顺序存储数据,一方面是因为计算机存储本身就是随机读写,另一方面是因为数据的操作有很大的随机性,即使一开始数据的存储是有序的,经过一系列的增删查改之后也会变得凌乱不堪。所以数据库的数据存储是随机的,使用 B+Tree, Hash 等方式组织索引。所以当你让数据库读取第 10001 条数据的时候,数据库就只能一条一条的去查去数。

第一次优化

根据数据库这种查找的特性,就有了一种想当然的方法,利用自增索引(假设为id):

select * from table_name where (id >= 10000) limit 10

 

由于普通搜索是全表搜索,适当的添加 WHERE 条件就能把搜索从全表搜索转化为范围搜索,大大缩小搜索的范围,从而提高搜索效率。

这个优化思路就是告诉数据库:「你别数了,我告诉你,第10001条数据是这样的,你直接去拿吧。」

但是!!!你可能已经注意到了,这个查询太简单了,没有任何的附加查询条件,如果我需要一些额外的查询条件,比如我只要某个用户的数据 ,这种方法就行不通了。

可以见到这种思路是有局限性的,首先必须要有自增索引列,而且数据在逻辑上必须是连续的,其次,你还必须知道特征值。

如此苛刻的要求,在实际应用中是不可能满足的。

第二次优化

说起数据库查询优化,第一时间想到的就是索引,所以便有了第二次优化:先查找出需要数据的索引列(假设为 id),再通过索引列查找出需要的数据。

Select * From table_name Where id in (Select id From table_name where ( user = xxx )) limit 10000, 10;

select * from table_name where( user = xxx ) limit 10000,10

相比较结果是(500w条数据):第一条花费平均耗时约为第二条的 1/3 左右。

同样是较大的 offset,第一条的查询更为复杂,为什么性能反而得到了提升?

这涉及到 mysql 主索引的数据结构 b+Tree ,这里不展开,基本原理就是:

  • 子查询只用到了索引列,没有取实际的数据,所以不涉及到磁盘IO,所以即使是比较大的 offset 查询速度也不会太差。
  • 利用子查询的方式,把原来的基于 user 的搜索转化为基于主键(id)的搜索,主查询因为已经获得了准确的索引值,所以查询过程也相对较快。

第三次优化

在数据量大的时候 in 操作的效率就不怎么样了,我们需要把 in 操作替换掉,使用 join 就是一个不错的选择

select * from table_name inner join ( select id from table_name where (user = xxx) limit 10000,10) b using (id)

至此 limit 在查询上的优化就告一段落了。如果还有更好的优化方式,欢迎留言告知

最终优化

技术上的优化始终是有天花板的,业务的优化效果往往更为显著。

比如在本例中,因为数据的时效性,我们最终决定,只提供最近15天内的操作日志,在这个前提下,偏移值 offset 基本不会超过一万,这样一来,即使是没有经过任何优化的 sql,其执行效率也变得可以接受了,所以优化不能局限于技术层面,有时候对需求进行一下调整,可能会达到意想不到的效果

 

mysql中走与不走索引的情况汇集(待全量实验)的更多相关文章

  1. Mysql中主键与索引

    摘自: https://www.cnblogs.com/wicub/p/5898286.html 一.什么是索引?索引用来快速地寻找那些具有特定值的记录,所有MySQL索引都以B-树的形式保存.如果没 ...

  2. MySQL优化器不使用索引的情况

    优化器选择不适用索引的情况 有时候,有乎其并没有选择索引而去查找数据,而是通过扫描聚集索引,也就是直接进行全表的扫描来得到数据.这种情况多发生于范围查找.JOIN链接操作等情况.例如 ; 通过SHOW ...

  3. mysql中id值被重置的情况

    MySQL中,如果你为一张使用了innodb引擎的表指定了一auto_increment列,那么这张表会有一个auto_increment计数器,专门记录当前auto_increment的相关值,用来 ...

  4. 谈谈MySQL中的降序索引 order by id DESC / ASC

    今天这篇主要讲order by 语句中的多个字段asc desc的问题.mysql5中,索引存储的排序方式是ASC的,没有DESC的索引.现在能够理解为啥order by 默认是按照ASC来排序的了吧 ...

  5. 在MySQL中如何使用覆盖索引优化limit分页查询

    背景 今年3月份时候,线上发生一次大事故.公司主要后端服务器发生宕机,所有接口超时.宕机半小时后,又自动恢复正常.但是过了2小时,又再次发生宕机. 通过接口日志,发现MySQL数据库无法响应服务器.在 ...

  6. MySQL中自适应哈希索引

    自适应哈希索引采用之前讨论的哈希表的方式实现,不同的是,这仅是数据库自身创建并使用的,DBA本身并不能对其进行干预.自适应哈希索引近哈希函数映射到一个哈希表中,因此对于字典类型的查找非常快速,如SEL ...

  7. mysql中包含长字段索引的优化

    不同于oracle,在mysql的Innodb存储引擎中,对索引的总长度有限制.在mysql 5.7中(https://dev.mysql.com/doc/refman/5.7/en/innodb-r ...

  8. 二十、oracle通过复合索引优化查询及不走索引的8种情况

    1. 理解ROWID ROWID是由Oracle自动加在表中每行最后的一列伪列,既然是伪列,就说明表中并不会物理存储ROWID的值:你可以像使用其它列一样使用它,只是不能对该列的值进行增.删.改操作: ...

  9. mysql中,主键与普通索引

    一.什么是索引?索引用来快速地寻找那些具有特定值的记录,所有MySQL索引都以B-树的形式保存.如果没有索引,执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录,直至找到符合要求的记录.表里 ...

随机推荐

  1. 每日一题 - 剑指 Offer 50. 第一个只出现一次的字符

    题目信息 时间: 2019-07-03 题目链接:Leetcode tag:哈希表 难易程度:简单 题目描述: 在字符串 s 中找出第一个只出现一次的字符.如果没有,返回一个单空格. s 只包含小写字 ...

  2. 【Java8新特性】冰河带你看尽Java8新特性,你想要的都在这儿了!!(文本有福利)

    写在前面 很多小伙伴留言说,冰河你能不能写一些关于Java8的文章呢,看书看不下去,看视频进度太慢.好吧,看到不少读者对Java8还是比较陌生的,那我就写一些关于Java8的文章吧,希望对大家有所帮助 ...

  3. vue页面原样导出excel表格

    github地址:https://github.com/wuzhiaite/vue-samples 1.excel导出 做过业务系统的知道,进行涉及到excel的导出,列表数据动则几十万,但是也有一部 ...

  4. abp重构登录

    a.Core层 Authorization.Users.UserStore.cs public class UserStore : AbpUserStore<Role, User> { p ...

  5. selenium 怎么查找定位鼠标移上去显示,移开鼠标就消失的内容

    场景:鼠标移动到一级菜单上二级菜单才显示,移开鼠标二级菜单就消失,如何查找定位二级菜单 操作: 1.打开F12,点击sources 2.鼠标移动到一级菜单“工单管理” 3.按下键盘“Ctrl+\”,暂 ...

  6. day03 编程语言介绍

    一.编程语言分类 目录 一.编程语言分类 1.低级语言 1.1机器语言 1.2.汇编语言 2.高级语言 2.1编译型语言(例:c语言) 2.2解释型语言(例:世界上最好的语言python) 3总结 二 ...

  7. 实现 (5).add(3).minus(2) 功能

    Number.prototype.add = function (number) { if (typeof number !== 'number') { throw new Error('请输入数字- ...

  8. 使用Xshell的rz命令上传文件失败的解决方法

    使用Xshell的rz命令上传文件失败的解决方法 第一种:在home目录下rz上传文件失败,如下: 原因:当前用户不具备权限解决:用 sudo rz 上传即可成功 第二种:对于文件大的rz上传失败的话 ...

  9. java 面向对象(十六):Object类的使用

    1.java.lang.Object类的说明: * 1.Object类是所Java类的根父类 * 2.如果在类的声明中未使用extends关键字指明其父类,则默认父类为java.lang.Object ...

  10. 数据可视化之powerBI技巧(四)使用Power BI制作帕累托图

    各种复杂现象的背后,其实都是受关键的少数因素和普通的大多数因素所影响,把主要精力放在关键的少数因素上,就能达到事半功倍的效果. 这就是大家常说的二八原则,也称为帕累托原则,最早是由意大利经济学家 V. ...