博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
利用 force index优化sql语句性能
阅读量:4609 次
发布时间:2019-06-09

本文共 1001 字,大约阅读时间需要 3 分钟。

【转自:】并进行总结

今天写了一个统计sql,在一个近亿条数据的表上执行,200s都查不出结果。SQL如下:

select customer,count(1) cfrom upv_**where created between "2015-07-06" and "2015-07-07"group by customer having c > 20order by c desc

 执行explain,发现这个sql扫描了8000W条记录到磁盘上。然后再进行筛选。type=index说明整个索引树都被扫描了,效果显然不理想。

 

 拿着这个SQL去请教项目组的数据库同事,仅仅加了一个force index,花了1s多就出结果了。修改后的SQL如下:

select customer,count(1) cfrom upv_** force index(idx_created)where created between "2015-07-06" and "2015-07-07"group by customer having c > 15order by c desc

同样执行以下explain命令,这个SQL仅仅扫描了磁盘的110W行记录。也就是上一个SQL的80分之一。大家都知道,扫描磁盘是很耗时的IO操作,比内存操作慢几个数量级。type=range,说明索引树仅仅被部分扫描,要优于前面那个SQL.

 

 

除了磁盘扫描的行数的不一样,还有采用的索引的不同,上面的sql用的是联合索引,而下面的是单纯的created字段的索引。由于用的是created的索引,驱动条件就是created的区间,需要扫描的数据就立刻变小了,因为时间区间小。后面的SQL的key_len要远远小于前面的SQL,也就意味着要扫描的磁盘上的索引数据量要远远小于前面的SQL。

    第一个sql使用的是错误的索引,带来低效的查询。然后每条SQL只可能使用一个索引。通过上面的分析就可以发现,force index()指令可以指定本次查询使用哪个索引!一条sql只会用到一个索引,mysql优化器会计算出一个合适的索引,但是这个索引不一定是最好的。force index()指令可以避免MySql优化器用到了一个低效的索引。

转载于:https://www.cnblogs.com/xuelisheng/p/11311136.html

你可能感兴趣的文章
Android API level 与version对应关系
查看>>
Team Name
查看>>
String类
查看>>
西门子_TDC_数据耦合小经验
查看>>
接口测试与postman
查看>>
LINQ To XML的一些方法
查看>>
[LeetCode] Copy List with Random Pointer
查看>>
openstack部署之nova
查看>>
JS组件系列——表格组件神器:bootstrap table
查看>>
存储过程Oracle(一)
查看>>
log4j日志归档
查看>>
Java笔记01——IO流
查看>>
mysql遇见error,1049
查看>>
NYOJ311 完全背包
查看>>
codevs——2822 爱在心中
查看>>
Python基础班---第一部分(基础)---Python基础知识---认识Python
查看>>
JAVA MAC 配置
查看>>
1134 最长上升子序列 (序列型 DP)
查看>>
js冒泡排序
查看>>
第一次作业 4班卢炳武
查看>>