1. 负向条件查询不能使用索引

select * from order where status!=0 and stauts!=1

not in/not exists都不是好习惯

可以优化为in查询:

select * from order where status in(2,3)

2. 前导模糊查询不能使用索引

select * from order where desc like '%XX'

而非前导模糊查询则可以:

select * from order where desc like 'XX%'

3. 数据区分度不大的字段不宜使用索引

select * from user where sex=1

原因:性别只有男,女,每次过滤掉的数据很少,不宜使用索引。

经验上,能过滤80%数据时就可以使用索引。对于订单状态,如果状态值很少,不宜使用索引,如果状态值很多,能够过滤大量数据,则应该建立索引。

4. 在属性上进行计算不能命中索引

select * from order where YEAR(date) < = '2017'

即使date上建立了索引,也会全表扫描,可优化为值计算:

select * from order where date < = CURDATE()

或者:

select * from order where date < = '2017-01-01'

5. 如果业务大部分是单条查询,使用Hash索引性能更好,例如用户中心

select * from user where uid=?

select * from user where login_name=?

原因:

B-Tree索引的时间复杂度是O(log(n))

Hash索引的时间复杂度是O(1)

6. 允许为null的列,查询有潜在大坑

列索引不存null值,复合索引不存全为null的值,如果列允许为null,可能会得到“不符合预期”的结果集

select * from user where name != 'shenjian'

如果name允许为null,索引不存储null值,结果集中不会包含这些记录。

所以,请使用not null约束以及默认值。

7. 复合索引最左前缀,并不是值SQL语句的where顺序要和复合索引一致

用户中心建立了(login_name, passwd)的复合索引

select * from user where login_name=? and passwd=?

select * from user where passwd=? and login_name=?

都能够命中索引

select * from user where login_name=?

也能命中索引,满足复合索引最左前缀

select * from user where passwd=?

不能命中索引,不满足复合索引最左前缀

8. 如果明确知道只有一条结果返回,limit 1能够提高效率

select * from user where login_name=?

可以优化为:

select * from user where login_name=? limit 1

原因:

你知道只有一条结果,但数据库并不知道,明确告诉它,让它主动停止游标移动

9. 把计算放到业务层而不是数据库层,除了节省数据的CPU,还有意想不到的查询缓存优化效果

select * from order where date < = CURDATE()

这不是一个好的SQL实践,应该优化为:

$curDate = date('Y-m-d');

$res = mysql_query('select * from order where date < = $curDate');

原因:

释放了数据库的CPU

多次调用,传入的SQL相同,才可以利用查询缓存

10. 强制类型转换会全表扫描

select * from user where phone=13800001234

优化:

phone字段为字符串类型,给phone值加上引号,变为:‘13800001234’

11. MySQL的or/in/union与索引优化

1).union all 肯定是能够命中索引的

2).简单的in能够命中索引

3).对于or,新版的MySQL能够命中索引

4).对于!=,负向查询肯定不能命中索引

12. 禁止使用SELECT *,只获取必要的字段,需要显示说明列属性

解读:

1).读取不需要的列会增加CPU、IO、NET消耗

2).不能有效的利用覆盖索引

3).使用SELECT *容易在增加或者删除字段后出现程序BUG

13. 禁止使用INSERT INTO t_xxx VALUES(xxx),必须显示指定插入的列属性

解读:容易在增加或者删除字段后出现程序BUG

14. 禁止使用属性隐式转换

解读:SELECT uid FROM t_user WHERE phone=13812345678 会导致全表扫描,而不能命中phone索引

15. 禁止在WHERE条件的属性上使用函数或者表达式

解读:SELECT uid FROM t_user WHERE from_unixtime(day)>='2017-02-15' 会导致全表扫描

正确的写法是:SELECT uid FROM t_user WHERE day>= unix_timestamp('2017-02-15 00:00:00')

16. 禁止负向查询,以及%开头的模糊查询

解读:

1).负向查询条件:NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等,会导致全表扫描

2).%开头的模糊查询,会导致全表扫描

17. 禁止大表使用JOIN查询,禁止大表使用子查询

解读:会产生临时表,消耗较多内存与CPU,极大影响数据库性能

18. 禁止使用OR条件,必须改为IN查询

解读:旧版本Mysql的OR查询是不能命中索引的,即使能命中索引,为何要让数据库耗费更多的CPU帮助实施查询优化呢?

19. 应用程序必须捕获SQL异常,并有相应处理

20. sql语句尽可能简单: 一条sql只能在一个cpu运算;大语句拆小语句,减少锁时间;一条大sql可以堵死整个库

21. 简单的事务:事务时间尽可能短

22. OR改写为IN();OR改写为UNION (画外音:最新的mysql内核已经进行了相关优化)

23. limit高效分页:limit越大,效率越低  select id from t limit 10000, 10;  应该改为 =>  select id from t where id > 10000 limit 10;

24. 使用union all替代union,union有去重开销

25. 尽量不用连接join

26. 打散批量更新

27. 使用新能分析工具: explain;show slow log;

28. 在Join表的时候使用相当类型的例,并将其索引:如果你的应用程序有很多 JOIN 查询,你应该确认两个表中Join的字段是被建过索引的。这样,MySQL内部会启动为你优化Join的SQL语句的机制。

29. 永远为每张表设置一个ID:我们应该为数据库里的每张表都设置一个ID做为其主键,而且最好的是一个INT型的(推荐使用UNSIGNED),并设置上自动增加的AUTO_INCREMENT标志。

内容转自 微信公众号:架构师之路

转自:MYSQL性能优化的最佳20+条经验:https://coolshell.cn/articles/1846.html

SQL优化(转)的更多相关文章

  1. SQL优化案例—— RowNumber分页

    将业务语句翻译成SQL语句不仅是一门技术,还是一门艺术. 下面拿我们程序开发工程师最常用的ROW_NUMBER()分页作为一个典型案例来说明. 先来看看我们最常见的分页的样子: WITH CTE AS ...

  2. sql 优化

    1.选择最有效率的表名顺序(只在基于规则的优化器中有效): oracle的解析器按照从右到左的顺序处理 from 子句中的表名,from子句中写在最后的表(基础表driving table)将被最先处 ...

  3. SQL 优化总结

    SQL 优化总结 (一)SQL Server 关键的内置表.视图 1. sysobjects         SELECT name as '函数名称',xtype as XType  FROM  s ...

  4. (转)SQL 优化原则

    一.问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用 系统提交实际应用后,随着数据库中数据的增加,系 ...

  5. sql优化阶段性总结以及反思

    Sql优化思路阶段性心得: 这段时间的优化做了好几个案例,其实有很多的类似点,都是好几张大表的相互连接,然后执行长达好几个小时,甚至都跑不出来. 自己差不多的思路就是Parallel full tab ...

  6. mysql sql优化实例

    mysql sql优化实例 优化前: pt-query-degist分析结果: # Query 3: 0.00 QPS, 0.00x concurrency, ID 0xDC6E62FA021C85B ...

  7. SQL优化技巧

    我们开发的大部分软件,其基本业务流程都是:采集数据→将数据存储到数据库中→根据业务需求查询相应数据→对数据进行处理→传给前台展示.对整个流程进行分析,可以发现软件大部分的操作时间消耗都花在了数据库相关 ...

  8. ORACLE常用SQL优化hint语句

    在SQL语句优化过程中,我们经常会用到hint,现总结一下在SQL优化过程中常见Oracle HINT的用法: 1. /*+ALL_ROWS*/ 表明对语句块选择基于开销的优化方法,并获得最佳吞吐量, ...

  9. SQL优化有偿服务

    本人目前经营MySQL数据库的SQL优化服务,100块钱一条.具体操作模式 其中第一条,可以通过在微信朋友圈转发链接中的信息(http://www.yougemysqldba.com/discuz/v ...

  10. 【MySQL】SQL优化系列之 in与range 查询

    首先我们来说下in()这种方式的查询 在<高性能MySQL>里面提及用in这种方式可以有效的替代一定的range查询,提升查询效率,因为在一条索引里面,range字段后面的部分是不生效的. ...

随机推荐

  1. JavaScript学习(七)

  2. wps去广告

    彻底解决WPS弹出热点广告.WPS购物图标的办法 方法一:(一定有效) https://www.cnblogs.com/ytaozhao/p/5654149.html 一直用WPS,但一直有一个问题迟 ...

  3. 20171018 在小程序页面去获取用户的OpenID

    1. 在小程序的.js 文件中增加代码 //加载页面时到后台服务去获取openID onLoad: function (options) { //OpenId wx.login({ //获取code ...

  4. MySQL 从库down机

    MySQL 从库down机中午突然down机,重启后,从库同步报主键重复的错误. Could not execute Write_rows event on table operation_maste ...

  5. python类型错误:can only concatenate list (not "str") to list

    TypeError:can only concatenate list (not "str") to list: 类型错误:只能将list类型和list类型联系起来,而不是str类 ...

  6. warning: LF will be replaced by CRLF in 解决办法

    今天用Git bash遇到的问题,看了几个回答之后发现一个比较有价值的,给大家分享一下,其他很多的回答都有很或多或少存在一些弊端. 原回答地址在stackoverflow上,附上链接--http:// ...

  7. spring框架中的注解

  8. Django基础之MTV模型

    一.Django基础 一.Django简介 Django是一个开放源代码的Web应用框架,由Python写成.采用了MVC的软件设计模式,即模型(Model).视图(View)和控制器(Control ...

  9. centos 打包报错Can't connect to X11 window server using ':0.0' as the value of the DISPLAY variable.

    参考: https://blog.csdn.net/salonzhou/article/details/8990237https://stackoverflow.com/questions/23358 ...

  10. git 不区分文件大小写的处理