通过索引优化sql

sql语句的优化最重要的一点就是要合理使用索引,下面介绍一下使用索引的一些原则:

1.最左前缀匹配原则。
mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配。所以要尽量把“=”条件放在前面,把范围查询(>、<、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‘

使用索引:
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 子句只在以下的条件下使用索引:
ORDER BY中所有的列必须包含在相同的索引中并保持在索引中的排列顺序.
ORDER 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’ ;

14.清除不必要的排序
低效:
select count(*) from (select * from user where id > 40 order by id);

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

15.having -> where
避免使用HAVING子句, HAVING 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作. 如果能通过WHERE子句限制记录的数目,那就能减少这方面的开销.
低效:
select * from user group by id having id > 40;

高效:
select * from user where id > 40 group by id;

16.除非确实需要去掉重复的行,否则尽量使用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

原文地址:https://www.cnblogs.com/ericz2j/p/11109203.html

时间: 2024-11-03 00:27:35

通过索引优化sql的相关文章

MySQL添加索引优化SQL

在慢查询日志中有一条慢SQL,执行时间约为3秒 mysql> SELECT     -> t.total_meeting_num,     -> r.voip_user_num     -> FROM     -> (     -> SELECT     -> count(*) total_meeting_num     -> FROM     -> Conference     -> WHERE     -> isStart = 1   

SQL优化的四个方面,缓存,表结构,索引,SQL语句

一,缓存 数据库属于 IO 密集型的应用程序,其主要职责就是数据的管理及存储工作.而我们知道,从内存中读取一个数据库的时间是微秒级别,而从一块普通硬盘上读取一个IO是在毫秒级别,二者相差3个数量级.所以,要优化数据库,首先第一步需要优化的就是 IO,尽可能将磁盘IO转化为内存IO. query_cache_size/query_cache_type (global) Query cache 作用于整个 MySQL Instance,主要用来缓存 MySQL 中的 ResultSet,也就是一条S

优化的四个方面,缓存,表结构,索引,SQL语句

一,缓存 数据库属于 IO 密集型的应用程序,其主要职责就是数据的管理及存储工作.而我们知道,从内存中读取一个数据库的时间是微秒级别,而从一块普通硬盘上读取一个IO是在毫秒级别,二者相差3个数量级.所以,要优化数据库,首先第一步需要优化的就是 IO,尽可能将磁盘IO转化为内存IO. query_cache_size/query_cache_type (global) Query cache 作用于整个 MySQL Instance,主要用来缓存 MySQL 中的 ResultSet,也就是一条S

mysql优化sql语句

mysql优化sql语句 常见误区 www.2cto.com 误区1: count(1)和count(primary_key) 优于 count(*) 很多人为了统计记录条数,就使用 count(1) 和 count(primary_key) 而不是 count(*) ,他们认为这样性能更好, 其实这是一个误区.对于有些场景,这样做可能性能会更差,应为数据库对 count(*) 计数操作做了一些特别的优化. 误区2: count(column) 和 count(*) 是一样的 这个误区甚至在很多

Oracle 建立索引及SQL优化

Oracle 建立索引及SQL优化 数据库索引: 索引有单列索引 复合索引之说 如何某表的某个字段有主键约束和唯一性约束,则Oracle 则会自动在相应的约束列上建议唯一索引.数据库索引主要进行提高访问速度. 建设原则: 1.索引应该经常建在Where 子句经常用到的列上.如果某个大表经常使用某个字段进行查询,并且检索行数小于总表行数的5%.则应该考虑. 2.对于两表连接的字段,应该建立索引.如果经常在某表的一个字段进行Order By 则也经过进行索引. 3.不应该在小表上建设索引. 优缺点:

SQL通用优化方案(where优化、索引优化、分页优化、事务优化、临时表优化)

SQL通用优化方案:1. 使用参数化查询:防止SQL注入,预编译SQL命令提高效率2. 去掉不必要的查询和搜索字段:其实在项目的实际应用中,很多查询条件是可有可无的,能从源头上避免的多余功能尽量砍掉,这是最简单粗暴的解决方案.3. 选择最有效率的表名顺序: 数据库的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表放在最后,如果有3个以上的表连接查询,那就需要选择那个被其他表所引用的表放在最后.

SQL优化之索引优化

这篇文章为Qi总结,如果有不对的希望可以指出. 初级开发人员,一般是接触不到架构,大数据这样的优化方案,而初级开发人员所做的优化一般只有SQl优化.  一·举一个小例子: 在网站中,一般会设计到登录注册,但是登录方式出现了很多种,例如:用户名登录,手机登录,邮箱登陆,微信,微博,QQ,--等等很多种登录方式. 这么多登录方式如果放入一张表中,在编写SQL语句中会出现很多问题: 如果放入一张表中登录方式的SQL语句应该是这样的: select * from user where uname='zh

小蚂蚁学习mysql性能优化(1)--SQL以及索引优化

性能优化之mysql优化 可以从几个方面进行优化 硬件    系统配置    数据库表结构    SQL索引 成本从高到底,效果从低到高. 如何发现有问题的SQL? 使用mysql慢查询日志对有效率问题的sql进行监控. show variables like 'slow_query.log'; set global slow_query_log_file='/home/mysql/sql_log/mysql-slow.log';//日志存放的位置 set global log_queries_

索引与sql优化问题汇总

各位亲爱的云友, 非常感谢大家踊跃参加DBA专家门诊一期:索引与sql优化,很多云友都提出了自己的问题,门诊主任医师玄惭对大家提的问题一一作了解答.现已整理好这些问题,分享在此,欢迎来拿,绝对干货! 篇幅较长,耐心细看! 我们将赠送每位提问者每人一本凌云杂志第四期,请各位以论坛短消息形式将姓名.电话.地址发送给管理员xiaofanqie. 啊里新人(Q1):索引我一般都是只有主键,这玩意儿,是不是越少越好? 玄惭(A1):在日常的业务开发中,常见使用到索引的地方大概有两类: 第一类.做业务约束需