SQL优化(转)
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优化(转)的更多相关文章
- SQL优化案例—— RowNumber分页
将业务语句翻译成SQL语句不仅是一门技术,还是一门艺术. 下面拿我们程序开发工程师最常用的ROW_NUMBER()分页作为一个典型案例来说明. 先来看看我们最常见的分页的样子: WITH CTE AS ...
- sql 优化
1.选择最有效率的表名顺序(只在基于规则的优化器中有效): oracle的解析器按照从右到左的顺序处理 from 子句中的表名,from子句中写在最后的表(基础表driving table)将被最先处 ...
- SQL 优化总结
SQL 优化总结 (一)SQL Server 关键的内置表.视图 1. sysobjects SELECT name as '函数名称',xtype as XType FROM s ...
- (转)SQL 优化原则
一.问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用 系统提交实际应用后,随着数据库中数据的增加,系 ...
- sql优化阶段性总结以及反思
Sql优化思路阶段性心得: 这段时间的优化做了好几个案例,其实有很多的类似点,都是好几张大表的相互连接,然后执行长达好几个小时,甚至都跑不出来. 自己差不多的思路就是Parallel full tab ...
- mysql sql优化实例
mysql sql优化实例 优化前: pt-query-degist分析结果: # Query 3: 0.00 QPS, 0.00x concurrency, ID 0xDC6E62FA021C85B ...
- SQL优化技巧
我们开发的大部分软件,其基本业务流程都是:采集数据→将数据存储到数据库中→根据业务需求查询相应数据→对数据进行处理→传给前台展示.对整个流程进行分析,可以发现软件大部分的操作时间消耗都花在了数据库相关 ...
- ORACLE常用SQL优化hint语句
在SQL语句优化过程中,我们经常会用到hint,现总结一下在SQL优化过程中常见Oracle HINT的用法: 1. /*+ALL_ROWS*/ 表明对语句块选择基于开销的优化方法,并获得最佳吞吐量, ...
- SQL优化有偿服务
本人目前经营MySQL数据库的SQL优化服务,100块钱一条.具体操作模式 其中第一条,可以通过在微信朋友圈转发链接中的信息(http://www.yougemysqldba.com/discuz/v ...
- 【MySQL】SQL优化系列之 in与range 查询
首先我们来说下in()这种方式的查询 在<高性能MySQL>里面提及用in这种方式可以有效的替代一定的range查询,提升查询效率,因为在一条索引里面,range字段后面的部分是不生效的. ...
随机推荐
- JavaScript学习(七)
- wps去广告
彻底解决WPS弹出热点广告.WPS购物图标的办法 方法一:(一定有效) https://www.cnblogs.com/ytaozhao/p/5654149.html 一直用WPS,但一直有一个问题迟 ...
- 20171018 在小程序页面去获取用户的OpenID
1. 在小程序的.js 文件中增加代码 //加载页面时到后台服务去获取openID onLoad: function (options) { //OpenId wx.login({ //获取code ...
- MySQL 从库down机
MySQL 从库down机中午突然down机,重启后,从库同步报主键重复的错误. Could not execute Write_rows event on table operation_maste ...
- python类型错误:can only concatenate list (not "str") to list
TypeError:can only concatenate list (not "str") to list: 类型错误:只能将list类型和list类型联系起来,而不是str类 ...
- warning: LF will be replaced by CRLF in 解决办法
今天用Git bash遇到的问题,看了几个回答之后发现一个比较有价值的,给大家分享一下,其他很多的回答都有很或多或少存在一些弊端. 原回答地址在stackoverflow上,附上链接--http:// ...
- spring框架中的注解
- Django基础之MTV模型
一.Django基础 一.Django简介 Django是一个开放源代码的Web应用框架,由Python写成.采用了MVC的软件设计模式,即模型(Model).视图(View)和控制器(Control ...
- 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 ...
- git 不区分文件大小写的处理