今天对我的数据库做压力测试
当数据量达到220万条的时候,速度非常慢
我的表结构一共6个字段,全是数字类型,有一个时间戳也是INT型
用语句
select id,saleip,ccip from sales where ccstart = 1 and cctime > 当前时间戳 order by id desc limit 1,100
其中,使用了关联索引id,ccstart,cctime
但是返回速度为28秒!!太慢了!
去掉order by id desc 以后返回时间为13秒!
还是叫人无法忍受!
请教mysql就是这样的速度吗?还是因为我是运行在windows平台下的缘故?还有其他好的优化方法吗???
数据分区就不要说了,我这个是一张日营业流水表,没的分!
13 个解决方案
#1
你的索引搞错了.
应该依次是 ccstart, cctime, id 的关联索引
你把 id 塞到最前面, 这个索引根本没起作用.
应该依次是 ccstart, cctime, id 的关联索引
你把 id 塞到最前面, 这个索引根本没起作用.
#2
你这点数据量, 如果索引正确, 当 LIMIT 数较小的时候, 执行时间最多也就 0.05 秒以内
#3
索引顺序应该为where子句的顺序
ccstart, cctime
id做为主键可以不用加入多列索引
ccstart, cctime
id做为主键可以不用加入多列索引
#4
索引顺序应为 where 子句顺序和 orderby 顺序.
至于主键出现在 orderby 内是否不用索引的问题, 楼上的确定吗 ? 我现在没装 mysql 无法测试, 按照我的理解 mysql 每次搜索只能遵循一条索引, (ccstart, cctime) 的组合索引和主键索引无法同时使用. 所以组合索引必须为 (ccstart, cctime, id)
至于主键出现在 orderby 内是否不用索引的问题, 楼上的确定吗 ? 我现在没装 mysql 无法测试, 按照我的理解 mysql 每次搜索只能遵循一条索引, (ccstart, cctime) 的组合索引和主键索引无法同时使用. 所以组合索引必须为 (ccstart, cctime, id)
#5
(ccstart, cctime) 的组合索引和主键索引无法同时使用.
事实上你的SQL语句并没有使用主键做为条件，何来同时使用？
事实上你的SQL语句并没有使用主键做为条件，何来同时使用？
#6
回楼上的, 并不只有 where 需要索引, orderby 也是要索引的啊
#7
如 SELECT * FROM table WHERE key1 = A, key2 = B order by key3 ASC, key4 ASC
这样组合索引的设计就是 (key1, key2, key3, key4), 而不是 (key1, key2)
这样组合索引的设计就是 (key1, key2, key3, key4), 而不是 (key1, key2)
#8
学习，长见识了
#9
ccstart,cctime,id
我想这个索引中的id应该是无效的。
我想这个索引中的id应该是无效的。
#10
如 SELECT * FROM table WHERE key1 = A, key2 = B order by key3 ASC, key4 ASC
这样组合索引的设计就是 (key1, key2, key3, key4), 而不是 (key1, key2)
这个可以理解。但如果改为
如 SELECT * FROM table WHERE key1 = A, key2 > B order by key3 ASC, key4 ASC
这时我就无法理解key3和key4如何工作了。你能解释一下这时的索引实际的结构吗？这种类型的索引工作原理我一直挺胡涂的。
这样组合索引的设计就是 (key1, key2, key3, key4), 而不是 (key1, key2)
这个可以理解。但如果改为
如 SELECT * FROM table WHERE key1 = A, key2 > B order by key3 ASC, key4 ASC
这时我就无法理解key3和key4如何工作了。你能解释一下这时的索引实际的结构吗？这种类型的索引工作原理我一直挺胡涂的。
#11
搜索的时候是可以用多条索引的。这个可以用EXPLAIN语句看出来。
至于楼主的实际情况，理论上应该是where的两个字段为一个组合索引，而order的id主键由于可能在其他情况下作为where条件而单独查询，应该是另外一个索引。
但我发现，好象组合索引对于where可能会有多种组合的情况下，效率不太好。所以我一般做法是每个字段单独为一个索引。
ps：我的是mysql5
至于楼主的实际情况，理论上应该是where的两个字段为一个组合索引，而order的id主键由于可能在其他情况下作为where条件而单独查询，应该是另外一个索引。
但我发现，好象组合索引对于where可能会有多种组合的情况下，效率不太好。所以我一般做法是每个字段单独为一个索引。
ps：我的是mysql5
#12
1 换平台，windows的话看看data所在盘的文件系统是不是ntfs。
2 增加内存
3 增加临时表大小
4 缓存之类的自己调调看
5 百万级数据库对于mysql来说根本不是问题，但也快到极限了
最后 索引的问题可以在一台没设缓存的机器上慢慢调试，多读mysql索引部分的文档
over
2 增加内存
3 增加临时表大小
4 缓存之类的自己调调看
5 百万级数据库对于mysql来说根本不是问题，但也快到极限了
最后 索引的问题可以在一台没设缓存的机器上慢慢调试，多读mysql索引部分的文档
over
#13
呵呵,问题解决了,确实是多了这个ID索引的缘故,删除之,速度飞快
谢谢各位:)
谢谢各位:)
#1
你的索引搞错了.
应该依次是 ccstart, cctime, id 的关联索引
你把 id 塞到最前面, 这个索引根本没起作用.
应该依次是 ccstart, cctime, id 的关联索引
你把 id 塞到最前面, 这个索引根本没起作用.
#2
你这点数据量, 如果索引正确, 当 LIMIT 数较小的时候, 执行时间最多也就 0.05 秒以内
#3
索引顺序应该为where子句的顺序
ccstart, cctime
id做为主键可以不用加入多列索引
ccstart, cctime
id做为主键可以不用加入多列索引
#4
索引顺序应为 where 子句顺序和 orderby 顺序.
至于主键出现在 orderby 内是否不用索引的问题, 楼上的确定吗 ? 我现在没装 mysql 无法测试, 按照我的理解 mysql 每次搜索只能遵循一条索引, (ccstart, cctime) 的组合索引和主键索引无法同时使用. 所以组合索引必须为 (ccstart, cctime, id)
至于主键出现在 orderby 内是否不用索引的问题, 楼上的确定吗 ? 我现在没装 mysql 无法测试, 按照我的理解 mysql 每次搜索只能遵循一条索引, (ccstart, cctime) 的组合索引和主键索引无法同时使用. 所以组合索引必须为 (ccstart, cctime, id)
#5
(ccstart, cctime) 的组合索引和主键索引无法同时使用.
事实上你的SQL语句并没有使用主键做为条件，何来同时使用？
事实上你的SQL语句并没有使用主键做为条件，何来同时使用？
#6
回楼上的, 并不只有 where 需要索引, orderby 也是要索引的啊
#7
如 SELECT * FROM table WHERE key1 = A, key2 = B order by key3 ASC, key4 ASC
这样组合索引的设计就是 (key1, key2, key3, key4), 而不是 (key1, key2)
这样组合索引的设计就是 (key1, key2, key3, key4), 而不是 (key1, key2)
#8
学习，长见识了
#9
ccstart,cctime,id
我想这个索引中的id应该是无效的。
我想这个索引中的id应该是无效的。
#10
如 SELECT * FROM table WHERE key1 = A, key2 = B order by key3 ASC, key4 ASC
这样组合索引的设计就是 (key1, key2, key3, key4), 而不是 (key1, key2)
这个可以理解。但如果改为
如 SELECT * FROM table WHERE key1 = A, key2 > B order by key3 ASC, key4 ASC
这时我就无法理解key3和key4如何工作了。你能解释一下这时的索引实际的结构吗？这种类型的索引工作原理我一直挺胡涂的。
这样组合索引的设计就是 (key1, key2, key3, key4), 而不是 (key1, key2)
这个可以理解。但如果改为
如 SELECT * FROM table WHERE key1 = A, key2 > B order by key3 ASC, key4 ASC
这时我就无法理解key3和key4如何工作了。你能解释一下这时的索引实际的结构吗？这种类型的索引工作原理我一直挺胡涂的。
#11
搜索的时候是可以用多条索引的。这个可以用EXPLAIN语句看出来。
至于楼主的实际情况，理论上应该是where的两个字段为一个组合索引，而order的id主键由于可能在其他情况下作为where条件而单独查询，应该是另外一个索引。
但我发现，好象组合索引对于where可能会有多种组合的情况下，效率不太好。所以我一般做法是每个字段单独为一个索引。
ps：我的是mysql5
至于楼主的实际情况，理论上应该是where的两个字段为一个组合索引，而order的id主键由于可能在其他情况下作为where条件而单独查询，应该是另外一个索引。
但我发现，好象组合索引对于where可能会有多种组合的情况下，效率不太好。所以我一般做法是每个字段单独为一个索引。
ps：我的是mysql5
#12
1 换平台，windows的话看看data所在盘的文件系统是不是ntfs。
2 增加内存
3 增加临时表大小
4 缓存之类的自己调调看
5 百万级数据库对于mysql来说根本不是问题，但也快到极限了
最后 索引的问题可以在一台没设缓存的机器上慢慢调试，多读mysql索引部分的文档
over
2 增加内存
3 增加临时表大小
4 缓存之类的自己调调看
5 百万级数据库对于mysql来说根本不是问题，但也快到极限了
最后 索引的问题可以在一台没设缓存的机器上慢慢调试，多读mysql索引部分的文档
over
#13
呵呵,问题解决了,确实是多了这个ID索引的缘故,删除之,速度飞快
谢谢各位:)
谢谢各位:)