Mysql语句优化的原则——让你写sql更加顺手

使用索引的原则:

1.最左前缀匹配原则。

mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配。所以要尽量把这些条件放在最后,把“=”条件放在前面。

不会用到b的索引:

where a=1 and c>0 and b=2

会用到b的索引:

where a=1 and b=2 and c>0

2.尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*),表示字段不重复的比例,比例越大我们扫描的记录数越少。

3.当取出的数据超过全表数据的20%时,不会使用索引。

4.使用like时注意:

不使用索引:

like ‘%L%’

使用索引:

like ‘L%’

5.尽量将or 转换为 union all

不使用索引:

select * from user where name=’a’ or age=’20’

使用索引:

select * from user where name=’a’ union all select * from user where age=’20’

6.字段加函数不会使用索引。所以尽量把函数放在数值上

不使用索引:

where truncate(price) = 1

使用索引:

where price > 1 and price < 2

7.如果使用数字作为字符,则数字需要加引号,否则mysql会自动在列上加数据类型转换函数

不使用索引

where mobile=18534874321

使用索引

where mobile=’18534874321’

8.字段加运算符不会使用索引。所以尽量把运算放在数值上

不使用索引:

SELECT ACCOUNT_NAME, AMOUNT

FROM TRANSACTION

WHERE AMOUNT + 3000 >5000;

使用索引:

SELECT ACCOUNT_NAME, AMOUNT

FROM TRANSACTION

WHERE AMOUNT > 2000 ;

9.使用组合索引时,必须要包括第一个列。

例如

alter table test add index(a,b,c):

不使用索引:

where b=1, c=2

where b=1

where c=2

使用索引:

where a=1, b=1, c=2

where a=1, b=1

where a=1, c=2

10.尽量避免使用is null或is not null

不使用索引:

SELECT …

FROM DEPARTMENT

WHERE DEPT_CODE IS NOT NULL;

使用索引:

SELECT …

FROM DEPARTMENT

WHERE DEPT_CODE >0;

11.不等于(!=)不会使用索引

不使用索引:

SELECT ACCOUNT_NAME

FROM TRANSACTION

WHERE AMOUNT !=0;

使用索引:

SELECT ACCOUNT_NAME

FROM TRANSACTION

WHERE AMOUNT >0;

12.ORDER BY 子句只在以下的条件下使用索引:

lORDER BY中所有的列必须包含在相同的索引中并保持在索引中的排列顺序.

lORDER BY中不能既有ASC也有DESC

例如:

alter table t1 add index(a,b);

alter table t1 add index(c);

不使用索引:

select * from t1 order by a,c; 不在一个索引中

select * from t1 order by b; 没有出现组合索引的第一列

select * from t1 order by a asc, b desc; 混合ASC和DESC

select * from t1 where a=1 order by c; where和order by用的不是同一个索引,where使用索引,order by不使用。

使用索引:

select * from t1 order by a,b;

select * from t1 order where a=1 order by b;

select * from t1 order where a=1 order by a,b;

select * from t1 order by a desc, b desc;

select * from t1 where c=1 order by c;

13.索引不是越多越好。mysql需要资源来维护索引,任何数据的变更(增删改)都会连带修改索引的值。所以,需要平衡考虑索引带来的查询加速和增删改减速。

其他注意事项

1.尽量避免使用select *

2.尽量使用表连接(join)代替子查询select * from t1 where a in (select b from t2)

3.性能方面,表连接 > (not) exists > (not) in

1)用exists代替in

低效:

SELECT *

FROM EMP

WHERE EMPNO > 0

AND DEPTNO IN (SELECT DEPTNO

FROM DEPT

WHERE LOC = ‘MELB’)

高效:

SELECT *

FROM EMP

WHERE EMPNO > 0

AND EXISTS (SELECT ‘X’

FROM DEPT

WHERE DEPT.DEPTNO = EMP.DEPTNO

AND LOC = ‘MELB’)

2)用not exists代替not in

低效:

SELECT …

FROM EMP

WHERE DEPT_NO NOT IN (SELECT DEPT_NO

FROM DEPT

WHERE DEPT_CAT=’A’);

高效:

SELECT ….

FROM EMP E

WHERE NOT EXISTS (SELECT ‘X’

FROM DEPT D

WHERE D.DEPT_NO = E.DEPT_NO

AND DEPT_CAT = ‘A’);

3)用表连接代替exists

exits:

SELECT ENAME

FROM EMP E

WHERE EXISTS (SELECT ‘X’

FROM DEPT

WHERE DEPT_NO = E.DEPT_NO

AND DEPT_CAT = ‘A’);

表连接:

SELECT ENAME

FROM DEPT D,EMP E

WHERE E.DEPT_NO = D.DEPT_NO

AND DEPT_CAT = ‘A’ ;

4.清除不必要的排序

低效:

select count(*) from (select * from user where id > 40 order by id);

高效:

select count(*) from (select * from user where id > 40);

5.having -> where

避免使用HAVING子句, HAVING 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作. 如果能通过WHERE子句限制记录的数目,那就能减少这方面的开销.

低效:

select * from user group by id having id > 40;

高效:

select * from user where id > 40 group by id;

6.除非确实需要去掉重复的行,否则尽量使用union all而不是union。因为union会自带distinct操作,代价很大

使用explain查看sql性能

1.explain用法:在select之前加上explain即可。

例如:explain select * from test;

注意:explain并不会真正运行语句,而是只返回执行计划。

怎么看执行计划?一个简单的优化原则:令sql读取尽可能少的行。

2.实战案例1:

问题语句运行超过5s:

SELECT `branch`.`id`, `branch`.`name`, `branch`.`registered_time`, `branch_region`.`region_id`, `user`.`username`, `user`.`mobile`, count(o.order_id) as order_num

FROM (`branch`)

LEFT JOIN `user` ON `user`.`branch_id` = `branch`.`id`

LEFT JOIN `branch_role` ON `branch_role`.`id` = `user`.`role_id`

LEFT JOIN `branch_region` ON `branch_region`.`branch_id` = `branch_role`.`branch_id`

LEFT JOIN `orders` o ON `branch`.`id` = `o`.`supplier_id`

WHERE branch.id NOT IN (select supplier_id from signing where seller_id=6683 and status < 6)

AND `branch`.`group` = 'SUPPLIER'

AND `branch_role`.`flag` = 'ADMINISTRATOR'

AND `branch`.`status` = 'NORMAL'

GROUP BY `branch`.`id`

ORDER BY `branch`.`registered_time` desc

LIMIT 20;

使用explain查看执行计划:

根据“读取尽可能少的数据”的原则,发现读取行数最多的步骤读取了4792行。进而发现这个步骤没有用到索引(NULL)。而这个没有用索引的表是orders的supplier_id列。

加索引试试看:

alter table orders add index(supplier_id);

再次使用explain查看执行计划:

可以看到这个步骤使用了索引,读取的行数减少到了599行。

实际执行一下,秒出。

3.explain执行计划各个字段的意义:

1)id:语句的执行顺序,倒序执行

2)select_type:主要有以下几个类型:

lsimple:表示简单的select,没有union和子查询

lprimary:最外层的select。在有子查询的语句中,最外面的select查询就是primary

lunion:union语句的第二个或者说是后面那一个

lunion result:union的结果

lsubquery: 子查询中的第一个 select

3)table:涉及的表。

4)type:连接类型。主要有以下几个:(重点查看)

lconst:说明只有一个匹配行,使用了主键或唯一性索引。通常是最优化的情况。

leq_ref,ref,ref_or_null:表示走了简单索引

lindex_merge:表示使用了多个索引的组合

lrange:表示通过索引取出了一个范围内的值。例如where a in (1,2)

lindex:表示对索引进行了全扫描

lALL:表示全表扫描

注意:以上类型从上到下性能越来越差。

5)possible_keys:可供使用的索引

6)keys:实际使用的索引

7)key_gen:索引长度

8)ref:显示使用哪个列或常数与索引一起从表中选择行

9)rows:读取的行数。(重点查看)

10)Extra:备注

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容

  • 50个常用的sql语句Student(S#,Sname,Sage,Ssex) 学生表Course(C#,Cname...
    哈哈海阅读 1,224评论 0 7
  • 对于单列索引,没有太多的话题,但是对于多列索引的建立,一个好的多列索引能使用的场景应可以涵盖很多,减少其他不必要的...
    小灰灰besty阅读 14,401评论 2 6
  • 你是精灵 是落下一地的飞花 如太阳的光辉 我飞越半个地球去看你的灯火 在你的窗前 也许寂寞但幸福的 我会偷偷的笑 ...
    拉面当阅读 361评论 0 0
  • 手机确实藏了我们太多的秘密,不应该拿手机来玩游戏。每个人也都有连自己的伴侣都不想知道的秘密,一辈子都不想让其他人知...
    成长期的黑鱼阅读 349评论 2 2