Mysql 简单SELECT，第一次很慢，以后很快，这是什么问题

myeverything · 发表于 2013-1-11 14:47

我仍然怀疑索引没有在内存中，你试下不使用索引多少时间？ignore index(INDEX_LOGIN,INDEX_CLOSETIME)。

gyjohn · 发表于 2013-1-11 16:34

本帖最后由 gyjohn 于 2013-1-11 17:00 编辑

myeverything 发表于 2013-1-11 14:47
我仍然怀疑索引没有在内存中，你试下不使用索引多少时间？ignore index(INDEX_LOGIN,INDEX_CLOSETIME)。

靠，ignore index竟然更快，不相信，重启跑了几次，结果都是走Index更慢。怎么办？

不用索引 10秒左右
用索引 10几秒-20几秒
Load cache然后用索引 3秒 + 10几秒

gyjohn · 发表于 2013-1-11 16:40

本帖最后由 gyjohn 于 2013-1-11 16:42 编辑

EXPLAIN --不用索引
select count(*) from table_name N0 ignore index(INDEX_LOGIN,INDEX_CLOSETIME)
where (N0.`CLOSE_TIME` >= '2012/11/21') and (N0.`CLOSE_TIME` < '2012/11/22') and N0.`Login` = 3000

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	N0	ALL	(null)	(null)	(null)	(null)	3877541	Using where

EXPLAIN --用索引
select count(*) from table_name N0
where (N0.`CLOSE_TIME` >= '2012/11/21') and (N0.`CLOSE_TIME` < '2012/11/22') and N0.`Login` = 3000

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	N0	range	INDEX_LOGIN,INDEX_CLOSETIME	INDEX_CLOSETIME	8	(null)	61590	Using where

icer_repls · 发表于 2013-1-11 17:23

肯定是缓存的影响啊，第一次select count(*)后很多数据都会cache在buffer pool里面，以后就会快很多了。事实上很多时候都用select count(*) 或者 select max(id)这种类似的方法来做buffer pool的预热

it_kevinshaw · 发表于 2013-1-11 17:35

gyjohn 发表于 2013-1-8 22:56
slow log也是记录这些sql, Explain结果里的key是INDEX_CLOSETIME，不单止possible_keys里有。

query_cac ...

query_cache_size 0

查询缓存区域大小是0，开启了也没用

gyjohn · 发表于 2013-1-11 18:34

icer_repls 发表于 2013-1-11 17:23
肯定是缓存的影响啊，第一次select count(*)后很多数据都会cache在buffer pool里面，以后就会快很多了。事实 ...

问题是同样第一次运行，SQLServer只要2秒，Mysql要2分钟

icer_repls · 发表于 2013-1-12 13:01

gyjohn 发表于 2013-1-11 18:34
问题是同样第一次运行，SQLServer只要2秒，Mysql要2分钟

不同的数据库对select count(*)做了优化的，所以你最后去查一下SQL SERVER的文档确定一下，我个人觉得是这个原因。

wolfyuan · 发表于 2013-1-18 10:05

要使第二次不受query cache的影响, 可以在SQL的某个地方加几个空格, 或者跑第二次之前, FLUSH QUERY CACHE

mchdba · 发表于 2013-1-18 23:40

可以在select后面加no_sql_cache来试试不用缓存的，再看看2个sql执行结果如何？