MySQL查询优化:LIMIT 1避免全表扫描提高查询效率_Mysql

在某些情况下,如果明知道查询结果只有一个,SQL语句中使用LIMIT 1会提高查询效率。
例如下面的用户表(主键id,邮箱,密码):

复制代码 代码如下:

create table t_user(
id int primary key auto_increment,
email varchar(255),
password varchar(255)
);

每个用户的email是唯一的,如果用户使用email作为用户名登陆的话,就需要查询出email对应的一条记录。
SELECT * FROM t_user WHERE email=?;
上面的语句实现了查询email对应的一条用户信息,但是由于email这一列没有加索引,会导致全表扫描,效率会很低。
SELECT * FROM t_user WHERE email=? LIMIT 1;
加上LIMIT 1,只要找到了对应的一条记录,就不会继续向下扫描了,效率会大大提高。
LIMIT 1适用于查询结果为1条(也可能为0)会导致全表扫描的的SQL语句。
如果email是索引的话,就不需要加上LIMIT 1,如果是根据主键查询一条记录也不需要LIMIT 1,主键也是索引。
例如:
SELECT * FROM t_user WHERE id=?;
就不需要写成:
SELECT * FROM t_user WHERE id=? LIMIT 1;
二者效率没有区别。
附上我做的实验:
存储过程生成100万条数据:

复制代码 代码如下:

BEGIN
DECLARE i INT;
START TRANSACTION;
SET i=0;
WHILE i<1000000 DO
INSERT INTO t_user VALUES(NULL,CONCAT(i+1,'@xxg.com'),i+1);
SET i=i+1;
END WHILE;
COMMIT;
END

查询语句

复制代码 代码如下:

SELECT * FROM t_user WHERE email='222@xxg.com'; 耗时0.56 s
SELECT * FROM t_user WHERE email='222@xxg.com' LIMIT 1; 耗时0.00 s

时间: 2024-08-30 14:49:27

MySQL查询优化:LIMIT 1避免全表扫描提高查询效率_Mysql的相关文章

大幅提升MySQL中InnoDB的全表扫描速度的方法_Mysql

 在 InnoDB中更加快速的全表扫描 一般来讲,大多数应用查询的时候都会用索引,查找很少的几行数据(主键查找或百行内的查询),但有时候我们需要全表查询.典型的全表扫描就是逻辑备份  (mysqldump) 和 online schema changes( 注:在线上对大表 schema 的操作,也是 facebook 的一个开源项目) (SELECT ... INTO OUTFILE).  在 Facebook我们用 mysqldump 来备份数据库. 正如你所知MySql提供两种备份方式,提

并行方式全表扫描功能已提交 PG 9.6 版主干代码

我以前建议过将并行全表扫描功能加入至PostgreSQL 9.5中,但未实现.然而,今天我很高兴地向各位通报 我已经将第一版本的并行扫描功能提交至PostgreSQL的开发主分支中,我们确认它将会包含在将要发布的9.6版本中. 为PostgreSQL增加并行查询功能,目前这只是第一步,它也是我长久以来的一个梦想,我已为此工作了好几年了, 最早真正开发时是在9.4版本的开发期间,那时我主要是开发了一些后台动态进程和动态共享内存:接着在9.5版本 期间,我又增加了很多有关并行机制的底层基本加松的开发

Mysql如何避免全表扫描的方法_Mysql

在以下几种条件下,MySQL就会做全表扫描: 1>数据表是在太小了,做一次全表扫描比做索引键的查找来得快多了.当表的记录总数小于10且记录长度比较短时通常这么做. 2>没有合适用于 ON 或 WHERE 分句的索引字段. 3>让索引字段和常量值比较,MySQL已经计算(基于索引树)到常量覆盖了数据表的很大部分,因此做全表扫描应该会来得更快. 4>通过其他字段使用了一个基数很小(很多记录匹配索引键值)的索引键.这种情况下,MySQL认为使用索引键需要大量查找,还不如全表扫描来得更快.

库表字符集不一致导致的全表扫描问题

背景: 当数据库的建库字符集和表不一样时,在库下针对表创建存储过程可能导致全表扫描 如下例: drop database if exists xx1; drop database if exists xx2; create database xx1 character set utf8; create database xx2 character set gbk;   然后分别在xx1 和 xx2下执行: CREATE TABLE t1 ( `col1` varchar(10) NOT NULL

浅析Oracle全表扫描下的逻辑读

T1表全表扫描产生逻辑读的分析 做个实验给你演示一下:以表t1为例,对段t1做dump 1.t1表就一条数据 gyj@OCM> select * from t1;      ID NAME ---------- ----------       1 AAAAA 2.找t1段的段头块 gyj@OCM> select  header_file,header_block from dba_segments where segment_name='T1' and owner='GYJ'; HEADER

MongoDB Primary 为何持续出现 oplog 全表扫描?

线上某 MongoDB 复制集实例(包含 Primary.Secondary.Hidden 3个节点 ),Primary 节点突然 IOPS 很高,调查后发现,其中 Hidden 处于 RECOVERING 状态,同时 Priamry 上持续有一全表扫描 oplog 的操作,正是这个 oplog 的 COLLSCAN 导致IO很高. 2017-10-23T17:48:01.845+0800 I COMMAND [conn8766752] query local.oplog.rs query: {

SQL SERVER中关于OR会导致索引扫描或全表扫描的浅析

在SQL SERVER的查询语句中使用OR是否会导致不走索引查找(Index Seek)或索引失效(堆表走全表扫描 (Table Scan).聚集索引表走聚集索引扫描(Clustered Index Scan))呢?是否所有情况都是如此?又该如何优化呢? 下面我们通过一些简单的例子来分析理解这些现象.下面的实验环境为SQL SERVER 2008,如果在不同版本有所区别,欢迎指正.   堆表单索引 首先我们构建我们测试需要实验环境,具体情况如下所示: DROP TABLE TEST    CRE

高水位线和全表扫描

   高水位线好比水库中储水的水位线,用于描述数据库中段的扩展方式.高水位线对全表扫描方式有着至关重要的影响.当使用delete 操作 表记录时,高水位线并不会下降,随之导致的是全表扫描的实际开销并没有任何减少.本文给出高水位线的描述,如何降低高水位线,以及高水 位线对全表扫描的影响.   一.何谓高水位线    如前所述,类似于水库中储水的水位线.只不过在数据库中用于描述段的扩展方式.     可以将数据段或索引段等想象为一个从左到右依次排开的一系列块.当这些块中未填充任何数据时,高水位线位于

SQL中WHERE变量IS NULL条件导致全表扫描问题的解决方法_MsSql

复制代码 代码如下: SET @SQL = 'SELECT * FROM Comment with(nolock) WHERE 1=1    And (@ProjectIds Is Null or ProjectId = @ProjectIds)    And (@Scores is null or Score =@Scores)' 印象中记得,以前在做Oracle开发时,这种写法是会导致全表扫描的,用不上索引,不知道Sql Server里是否也是一样呢,于是做一个简单的测试1.建立测试用的表结