请教 MySQL 的 LIMIT 语句的优化

G. 发布于 2010/08/12 12:21
阅读 399
收藏 2

SELECT `id` FROM  `tab_a`

    WHERE `city` = 4

    ORDER BY `id` DESC

    LIMIT 1000000 , 10 ;

==================================

`id` int(4) AUTO_INCREMENT ,  

`city` tinyint(1) 

 

假设场景如下:

表有 10000000 条记录.

city 的取值为 [1, 5] , 而且分布相对平均, 所以建立索引并不能提升性能.

满足 WHERE `city` = 4 , 的数据大约 2000000, 所以 ORDER BY `id`  DESC / ASC 并没有多大影响.

请问这种类型的 limit 有没有比较好的办法来优化?

 

现实应用的场景:

 city 取值约 [1,100] , 分布虽然不会太平均, 但比例相差也不会太大.

经常用到的  WHERE 约 3-5 个字段, 大多数是"标志性"的, 且取值大多数在 [1,  50] . 部分取值在 [1,  1000].

字段都是固定长度, 不带 text 类型.

数据表以每天 > 4 万 的速度增加...

 

 

希望大家能对 假设场景 提点建议.

谢谢.

加载中
0
G.
G.

引用来自#8楼“贱客”的帖子

不妨 EXPLAIN 一下你的 SQL 语句看看结果

另外 WHERE 中的条件可以建一个符合索引先。

EXPLAIN ,提示没有用到索引. 采用 "全表扫描",

如果对 city 建立索引.

EXPLAIN ,提示 使用了索引. 但是性能并没有提升.

0
鉴客
鉴客

性能没有提升,你这个查询耗时多少啊?

0
G.
G.

city 无索引: (20 总计, 查询花费 0.6507 秒)

city 有索引: (20 总计, 查询花费 1.2438 秒)

相信您的眼睛,上面的没有错,  建立低唯一性的字段索引,很难提升性能, 有时还会更低.

0
红薯
红薯

引用来自#4楼“linxiuxiu”的帖子

city 无索引: (20 总计, 查询花费 0.6507 秒)

city 有索引: (20 总计, 查询花费 1.2438 秒)

相信您的眼睛,上面的没有错,  建立低唯一性的字段索引,很难提升性能, 有时还会更低.

1000万记录,查询花了这么些时间,应该还算可以吧

0
G.
G.

假设场景 中, 逻辑和数据都比较简单, 实际应用的场景里面, WHERE 比较多, 数据更新快, cache 失效也快.

每天都有 1K 条以上超过 1秒的 "慢查询", 实在无法忍受啊...

0
红薯
红薯

升级数据库服务器的处理器性能吧?呵呵

0
G.
G.

老大, 对这种 "标志" 性的字段 有没有什么比较好的处理方式?

0
红薯
红薯

引用来自#8楼“linxiuxiu”的帖子

老大, 对这种 "标志" 性的字段 有没有什么比较好的处理方式?

没什么好办法,都无需建索引,如果值太少的话。

0
G.
G.

谢谢!

0
G.
G.

引用来自#9楼“红薯”的帖子

引用来自#8楼“linxiuxiu”的帖子

老大, 对这种 "标志" 性的字段 有没有什么比较好的处理方式?

没什么好办法,都无需建索引,如果值太少的话。

半年过去了,这个问题还在困扰着我,我实在找不出优化的法子.

不知道大家有没有一些建议呢?

返回顶部
顶部