46 万行的 MySQL 数据表，一个 where col='xxx'查询都要 5 秒左右，正常吗？

[kisshere]

一个 46 万行的 mysql 表，其中的 category 字段做了普通索引的： ALTER TABLE users ADD INDEX(category)， category 就三种类型：'students','teachers','workers'，现在一个 SELECT id FROM users WHERE category='students' ORDER BY id DESC LIMIT 300000,10 ，这个 query 试了好多次平均耗时都在 5 秒左右，请问有没有什么优化的办法？

[superalsrk]

扫表的话。。 40 多万条也不应该这么慢啊。。可以看一下 profile 查看一下是哪个过程比较耗时: 参考 http://stackbox.cn/2016-07-some-performance-realated-tools/

[Aluhao]

去掉这个会快很多 ORDER BY id DESC

[501956430]

主机性能不行，只能这样了，有个类似的表 50w 数据 分页查询就几百毫秒以内

[Symars]

limit 问题 先查根据 cate 查 id

[Khlieb]

MariaDB

[winglight2016]

@Khlieb MariaDB 据说和 MySQL 差距不是很明显啊？

[yuxing1171]

问题出在 LIMIT 300000 ， 换种翻页方式吧。

[firefox12]

为什么 id 不加索引呢？

[Navee]

问题不在索引，在 limit
看看这个 http://www.fienda.com/archives/110
楼主还是多学习，多问问提，少下结论

[cloudzhou]

1 试试使用 smallint 来表示 category ，使用枚举，不要用字符
2 在 1 的基础上， create index users_category_id_idx on users(category, id desc);

然后使用同样的 sql 语句，看看这时候速度是多少呢？
如果还是有问题，使用 redist 的 sortedset 来存储每个 category 的 id ，以 desc 排序

[iyaozhen]

MySQL 就不适合十万级以上的数据！
并不赞同。我刚跑了一下 1 亿条的表，差不多的 SQL 用时 2.34s 。机器上硬盘是 HDD ，不过 cpu 、内存比较大。

楼上也说了，问题不在硬盘或者索引，在 limit 上，之前就有人说过这类的优化方案，你的 SQL 应该这样写： SELECT id FROM users WHERE category='students' and id > 400000 LIMIT 1 。

大数据量下的翻页可以牺牲一些准确度换取性能。

[hao123yinlong]

顶楼上 ， 2 核 4G ， HDD ，青云提供的 mysql 服务 ，> 200 w 单个小表 ，平均 5 ms 内响应

[palfortime]

只有三类值的 column ，加索引和不加基本没有什么区别。假如三个值均匀分布， SELECT id FROM users WHERE category='students' ORDER BY id DESC LIMIT 300000,10 这条语句也是要查找 15 万条，和 46 万也是在一个级别。按楼上说的，翻页时记着上一次最后一个 id ，用 id 的索引来查更好，均匀分布的话，就查询几十条。

[nightspirit]

这么点数据应该不会这么慢的， id 肯定是要加索引，然后就是上面有提到的那种子句查询，这是一种延迟关联，这种确实可以大大提升性能，然后就是 nosql ，这种方案可行，最后就是那种翻页的时候传递 id ，这种应该是效果最好的，综合效果（包括维护优化成本），不过好像我在开发中除了做 app 有这样写过， pc 应用好像都还没这么做过。

[shaohuifan]

mysql 千万级才会有性能问题，你的问题是 limit

[Khlieb]

@winglight2016 接口应该差不多，但性能差得明显。 @livid 有个帖子做过比较。