SQL: select 1 from tb_table where type = 10 and time = 20180207 limit 1;
该SQL的查询计划不走任何索引。全表扫瞄。
表结构较为简单,大约10个字段左右。
造成这个问题的可能原因:在这次100s的查询之前,曾经发生过一次数据归档的操作,从这个表中删除了大约2700万条数据,之后该表还剩余大约6000万数据。之后在100s 的查询之前,并无这样的查询执行过。
猜测:是不是MySQL在一次查询之后会有数据的缓存?
7 个解决方案
#1
另外,这个表中的数据就time 这个字段而言,是每天都会有的,但是type字段,目前只有10个左右。
#2
既然不走索引,又有时间条件,建议采用时间范围进行表分区。
同时你可以分析下原因:
set profiling=1;
select 1 from tb_table where type = 10 and time = 20180207 limit 1;
show profiles; #记录刚刚SQL的ID
show profile for query id;
查看到底是哪儿耗时
同时你可以分析下原因:
set profiling=1;
select 1 from tb_table where type = 10 and time = 20180207 limit 1;
show profiles; #记录刚刚SQL的ID
show profile for query id;
查看到底是哪儿耗时
#3
单位的数据库,没权限执行 set操作。
#4
你放心,数据库有缓存也不会造成你的结果错误。
结果不一致的原因是:你要取1条,但是你又不排序(或者排序值不唯一),符合你条件的数据展示哪条都行。
结果不一致的原因是:你要取1条,但是你又不排序(或者排序值不唯一),符合你条件的数据展示哪条都行。
#5
其实我的重点是,为什么同样的查询,时间不一致。差距那么大
#6
对的。数据库是有缓存。
在每次查询或修改之前,得先加载到内存中,再做相关操作。
不过,你的时间相差 原因不好判断。
在每次查询或修改之前,得先加载到内存中,再做相关操作。
不过,你的时间相差 原因不好判断。
#7
我的两次查询之间的时间差大约在 10分钟
#1
另外,这个表中的数据就time 这个字段而言,是每天都会有的,但是type字段,目前只有10个左右。
#2
既然不走索引,又有时间条件,建议采用时间范围进行表分区。
同时你可以分析下原因:
set profiling=1;
select 1 from tb_table where type = 10 and time = 20180207 limit 1;
show profiles; #记录刚刚SQL的ID
show profile for query id;
查看到底是哪儿耗时
同时你可以分析下原因:
set profiling=1;
select 1 from tb_table where type = 10 and time = 20180207 limit 1;
show profiles; #记录刚刚SQL的ID
show profile for query id;
查看到底是哪儿耗时
#3
单位的数据库,没权限执行 set操作。
#4
你放心,数据库有缓存也不会造成你的结果错误。
结果不一致的原因是:你要取1条,但是你又不排序(或者排序值不唯一),符合你条件的数据展示哪条都行。
结果不一致的原因是:你要取1条,但是你又不排序(或者排序值不唯一),符合你条件的数据展示哪条都行。
#5
其实我的重点是,为什么同样的查询,时间不一致。差距那么大
#6
对的。数据库是有缓存。
在每次查询或修改之前,得先加载到内存中,再做相关操作。
不过,你的时间相差 原因不好判断。
在每次查询或修改之前,得先加载到内存中,再做相关操作。
不过,你的时间相差 原因不好判断。
#7
我的两次查询之间的时间差大约在 10分钟