mysql 修改前30条_30条书写高质量SQL的建议，太有用了！

原标题：30条书写高质量SQL的建议，太有用了！

“

本文将结合实例 demo，阐述 30 条有关于优化 SQL 的建议，多数是实际开发中总结出来的，希望对大家有帮助。

1

查询 SQL 尽量不要使用 select *，而是 select 具体字段

反例子：

select* fromemployee;

正例子：

selectid， namefromemployee;

理由如下：

只取需要的字段，节省资源、减少网络开销。

select * 进行查询时，很可能就不会使用到覆盖索引了，就会造成回表查询。

2

如果知道查询结果只有一条或者只要最大/最小一条记录，建议用 limit 1

假设现在有 employee 员工表，要找出一个名字叫 jay 的人：

CREATETABLE`employee`(

`id`int( 11) NOTNULL,

`name`varchar( 255) DEFAULTNULL,

`age`int( 11) DEFAULTNULL,

`date`datetime DEFAULTNULL,

`sex`int( 1) DEFAULTNULL,

PRIMARY KEY( `id`)

) ENGINE= InnoDBDEFAULTCHARSET=utf8;

反例：

selectid， namefromemployee wherename= 'jay'

正例：

selectid， namefromemployee wherename= 'jay'limit1;

理由如下：

加上 limit 1 后，只要找到了对应的一条记录,就不会继续向下扫描了，效率将会大大提高。

当然，如果 name 是唯一索引的话，是不必要加上 limit 1 了，因为 limit 的存在主要就是为了防止全表扫描，从而提高性能，如果一个语句本身可以预知不用全表扫描，有没有 limit ，性能的差别并不大。

3

应尽量避免在 where 子句中使用 or 来连接条件

新建一个 user 表，它有一个普通索引 userId，表结构如下：

CREATETABLE`user`(

`id`int( 11) NOTNULLAUTO_INCREMENT,

`userId`int( 11) NOTNULL,

`age`int( 11) NOTNULL,

`name`varchar( 255) NOTNULL,

PRIMARY KEY( `id`),

KEY`idx_userId`( `userId`)

) ENGINE= InnoDBDEFAULTCHARSET=utf8;

假设现在需要查询 userid 为 1 或者年龄为 18 岁的用户，很容易有以下 SQL。

反例：

select* fromuserwhereuserid= 1orage = 18

正例：

//使用union all

select* fromuserwhereuserid= 1

unionall

select* fromuserwhereage = 18

//或者分开两条 sql写：

select* fromuserwhereuserid= 1

select* fromuserwhereage = 18

理由：使用 or 可能会使索引失效，从而全表扫描。

对于 or+没有索引的 age 这种情况，假设它走了 userId 的索引，但是走到 age 查询条件时，它还得全表扫描，也就是需要三步过程：全表扫描+索引扫描+合并，如果它一开始就走全表扫描，直接一遍扫描就完事。

MySQL 是有优化器的，处于效率与成本考虑，遇到 or 条件，索引可能失效，看起来也合情合理。

4

优化 limit 分页

我们日常做分页需求时，一般会用 limit 实现，但是当偏移量特别大的时候，查询效率就变得低下。

反例：

selectid， name，age fromemployee limit10000， 10

正例：

//方案一 ：返回上次查询的最大记录(偏移量)

selectid， namefromemployee whereid> 10000limit10.

//方案二： orderby+ 索引

selectid， namefromemployee orderbyidlimit10000， 10

//方案三：在业务允许的情况下限制页数：

理由如下：

当偏移量最大的时候，查询效率就会越低，因为 MySQL 并非是跳过偏移量直接去取后面的数据，而是先把偏移量+要取的条数，然后再把前面偏移量这一段的数据抛弃掉再返回的。

如果使用优化方案一，返回上次最大查询记录(偏移量)，这样可以跳过偏移量，效率提升不少。

方案二使用 order by+索引，也是可以提高查询效率的。

方案三的话，建议跟业务讨论，有没有必要查这么后的分页啦。因为绝大多数用户都不会往后翻太多页。

5

优化你的 like 语句

日常开发中，如果用到模糊关键字查询，很容易想到 like，但是 like 很可能让你的索引失效。

反例：