博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
select * 比select column快很多奇怪案例分析
阅读量:6708 次
发布时间:2019-06-25

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

遇到MYSQL傻傻的地方,下面给个案例,大家感受下:

 注意以下两个sql只有select *和select g.id区别。

SQL1:

SELECT
g.id
FROM
table1 g
INNER JOIN table2 l ON concat('订单号:',CONVERT(g.id,char)) = l.info
WHERE LOCATE('付款操作',l.info) AND g.p = 2
LIMIT 100

查询时间:5.28s

SQL2:

SELECT
*
FROM
table1 g
INNER JOIN table2 l ON concat('订单设为付款操作成功 订单号:',CONVERT(g.id,char)) = l.info
WHERE LOCATE('付款操作成功',l.info) AND g.p = 2
LIMIT 100

查询时间:0.21s

注意以下Sending data的sql1比sql2慢,这是不是很诡异!!!!!!!!!!!!!!

SQL1:

 

SQL2:

 

分析下profile的情况:

sql1的Context_voluntary | Context_involuntary | Block_ops_in | Block_ops_out 比sql2的高很多,按理说字段少,处理数据更快啊!这里为什么反而更慢?????

Context_voluntary :这个是主动上下文切换次数

Context_involuntary :这个是被动上下文切换次数

Block_ops_in :这个是阻塞输入操作

Block_ops_out :这个是阻塞输出操作

 

下面说下原因为什么select column比select *慢:

1.select column比select *处理的数据少

2.mysql的select操作使用的是悲观锁

3.cpu对select column的处理速度要快于select *

4.导致cpu处理完一批数据,ops_in 跟不上,而使用悲观锁,cpu不会自旋,等待数据,而是切换到其它任务

5.所以数据量少的上下文切换的更频繁

6.所以select * 比select column快了很多

 

解决办法:

多加几个字段,增加数据量,这样cpu就没有等待,进行的上下文切换就会少很多,速度就会快很多。如果应用嫌获得数据太多,应用层获得数据把这些数据进行过滤掉就行了。最好的办法是拆分字段,使查询走索引。

SELECT

g.id,g.column1,g.cloumn2
FROM
table1 g
INNER JOIN table2 l ON concat('订单号:',CONVERT(g.id,char)) = l.info
WHERE LOCATE('付款操作',l.info) AND g.p = 2
LIMIT 100

转载于:https://www.cnblogs.com/katechun/p/9498231.html

你可能感兴趣的文章
Xamarin-Android_BaseAdapter 简单的复用
查看>>
快速傅里叶变换(FFT)
查看>>
在C#程序中使用ocx的方法
查看>>
C# 递归查找文件夹下所有文件和子文件夹的所有文件
查看>>
如何发布你的 Maya 应用到欧特克官方的 Exchange Store
查看>>
react之自定义react-redux的provider、connect
查看>>
JQuery中工厂函数$()初探
查看>>
网上发现的一个android UI包
查看>>
新闻源图片放到js里
查看>>
SpringBoot学习:整合Mybatis,使用HikariCP超高性能数据源
查看>>
Java--面向对象
查看>>
微信模板消息群发系统
查看>>
高内聚低耦合
查看>>
2012 chengdu现场赛 Browsing History HDU4464(简单字符串)
查看>>
Codeforces Round #239 (Div. 1) 解题报告
查看>>
R与JAVA的混合编程
查看>>
hibernate工作流程、session
查看>>
python_时间日期
查看>>
MVC架构介绍-序列化属性
查看>>
问题2017S02
查看>>