我有一个包含大量记录的表。当我从特定表查询时,特别是在查询中使用ORDER BY时,它占用了太多的执行时间。
如何针对排序和Searching优化此表
下面是我的表(jobs)的示例方案:
+---+-----------------+---------------------+--+
| id| title | created_at |
+---+-----------------+---------------------+--+
| 1 | Web Developer | 2018-04-12 10:38:00 | |
| 2 | QA Engineer | 2018-04-15 11:10:00 | |
| 3 | Network Admin | 2018-04-17 11:15:00 | |
| 4 | System Analyst | 2018-04-19 11:19:00 | |
| 5 | UI/UX Developer | 2018-04-20 12:54:00 | |
+---+-----------------+---------------------+--+
我已经搜索了一段时间,我了解到创建索引可以帮助提高性能,有人能解释一下如何提高性能吗?
发布于 2018-06-07 20:47:30
在您的查询前添加“解释”一词,并检查结果
explain select ....
在这里,您可以看到需要改进的地方,然后在搜索和/或排序字段上添加索引,然后再次运行explain查询
发布于 2018-06-07 20:54:10
如果你想根据你的请求获得性能,一种方法就是对它进行分页。因此,您可以设置限制(根据需要)并指定要显示的页面。
例如SELECT * FROM your_table LIMIT 50 OFFSET 0
。
我不知道这个答案是否会帮助你解决你的问题,但你可以试试;)
发布于 2018-06-09 06:16:03
ALTER TABLE jobs
ADD INDEX(created_at);
(是的,有一种CREATE INDEX
语法可以做同样的事情。)
然后,在查询中,执行
ORDER BY created_at DESC
但是,对于15M行,可能仍然需要很长时间。您要过滤(WHERE
)吗?LIMITing
如果您真的想返回给用户15M行--嗯,这是一个很大的网络流量,这将需要很长时间。
MySQL details
无论索引声明或版本如何,都将遵循ORDER BY
中的ASC/DESC
。然而,它可能需要“文件排序”,而不是利用索引的BTree中内置的排序。
在某些情况下,WHERE
或GROUP BY
太杂乱,优化器无法使用任何索引。但如果它可以,那么..。
( MySQL 8.0之前的版本)虽然可以声明索引DESC
,但会忽略该属性。但是,ORDER BY .. DESC
是受欢迎的;它向后扫描数据。这也适用于ORDER BY a DESC, b DESC
,但如果在ORDER BY
中混合使用了ASC
和DESC
,则不适用。
DESC8.0确实创建了MySQL索引;也就是说,包含索引的BTree是“向后”存储的。
https://stackoverflow.com/questions/50741509
复制相似问题