虽然存在索引,但复杂的MySQL查询仍然使用filesort
我有一个Joomla表,有数千行内容,大约有300万行。在查询表时,我在尽可能快地重写数据库查询时遇到了一些问题 以下是我的全部疑问:虽然存在索引,但复杂的MySQL查询仍然使用filesort,mysql,optimization,indexing,filesort,Mysql,Optimization,Indexing,Filesort,我有一个Joomla表,有数千行内容,大约有300万行。在查询表时,我在尽可能快地重写数据库查询时遇到了一些问题 以下是我的全部疑问: SELECT cc.title AS category, a.id, a.title, a.alias, a.title_alias, a.introtext, a.fulltext, a.sectionid, a.state, a.catid, a.created, a.created_by, a.created_by_alias, a.modified, a
SELECT cc.title AS category, a.id, a.title, a.alias, a.title_alias, a.introtext, a.fulltext, a.sectionid, a.state, a.catid, a.created, a.created_by, a.created_by_alias, a.modified, a.modified_by, a.checked_out, a.checked_out_time, a.publish_up, a.publish_down, a.attribs, a.hits, a.images, a.urls, a.ordering, a.metakey, a.metadesc, a.access, CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(":", a.id, a.alias) ELSE a.id END AS slug, CASE WHEN CHAR_LENGTH(cc.alias) THEN CONCAT_WS(":", cc.id, cc.alias) ELSE cc.id END AS catslug, CHAR_LENGTH( a.`fulltext` ) AS readmore, u.name AS author, u.usertype, g.name AS groups, u.email AS author_email
FROM j15_content AS a
LEFT JOIN j15_categories AS cc
ON a.catid = cc.id
LEFT JOIN j15_users AS u
ON u.id = a.created_by
LEFT JOIN j15_groups AS g
ON a.access = g.id
WHERE 1
AND a.access <= 0
AND a.catid = 108
AND a.state = 1
AND ( publish_up = '0000-00-00 00:00:00' OR publish_up <= '2012-02-08 00:16:26' )
AND ( publish_down = '0000-00-00 00:00:00' OR publish_down >= '2012-02-08 00:16:26' )
ORDER BY a.title, a.created DESC
LIMIT 0, 10
要显示存在哪些索引,请显示j15_内容中的索引:
+-------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| j15_content | 0 | PRIMARY | 1 | id | A | 3228356 | NULL | NULL | | BTREE | |
| j15_content | 1 | idx_section | 1 | sectionid | A | 2 | NULL | NULL | | BTREE | |
| j15_content | 1 | idx_access | 1 | access | A | 1 | NULL | NULL | | BTREE | |
| j15_content | 1 | idx_checkout | 1 | checked_out | A | 2 | NULL | NULL | | BTREE | |
| j15_content | 1 | idx_state | 1 | state | A | 2 | NULL | NULL | | BTREE | |
| j15_content | 1 | idx_catid | 1 | catid | A | 6 | NULL | NULL | | BTREE | |
| j15_content | 1 | idx_createdby | 1 | created_by | A | 1 | NULL | NULL | | BTREE | |
| j15_content | 1 | title | 1 | title | A | 201772 | 4 | NULL | | BTREE | |
| j15_content | 1 | idx_access_state_catid | 1 | access | A | 1 | NULL | NULL | | BTREE | |
| j15_content | 1 | idx_access_state_catid | 2 | state | A | 2 | NULL | NULL | | BTREE | |
| j15_content | 1 | idx_access_state_catid | 3 | catid | A | 7 | NULL | NULL | | BTREE | |
| j15_content | 1 | idx_title_created | 1 | title | A | 3228356 | 8 | NULL | | BTREE | |
| j15_content | 1 | idx_title_created | 2 | created | A | 3228356 | NULL | NULL | | BTREE | |
+-------------+------------+------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
正如您所看到的,有一些数据是从数据库中获取的。现在我通过简化查询来测试,真正的问题在于ORDERBY子句。如果不对结果排序,查询的响应性很强,下面是一个解释:
+----+-------------+-------+--------+-------------------------------------------------------+-----------+---------+---------------------------+---------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+-------------------------------------------------------+-----------+---------+---------------------------+---------+-------------+
| 1 | SIMPLE | a | ref | idx_access,idx_state,idx_catid,idx_access_state_catid | idx_catid | 4 | const | 3108187 | Using where |
| 1 | SIMPLE | cc | const | PRIMARY | PRIMARY | 4 | const | 1 | |
| 1 | SIMPLE | u | eq_ref | PRIMARY | PRIMARY | 4 | database.a.created_by | 1 | |
| 1 | SIMPLE | g | eq_ref | PRIMARY | PRIMARY | 1 | database.a.access | 1 | |
+----+-------------+-------+--------+-------------------------------------------------------+-----------+---------+---------------------------+---------+-------------+
正如您所看到的,是致命的文件排序杀死了服务器。有这么多行,我正在尽我最大的努力通过索引来优化所有内容,但这仍然有点不对劲。如有任何意见,将不胜感激
尝试使用强制索引但无效:
explain SELECT cc.title AS category, a.id, a.title, a.alias, a.title_alias, a.introtext, a.fulltext, a.sectionid, a.state, a.catid, a.created, a.created_by, a.created_by_alias, a.modified, a.modified_by, a.checked_out, a.checked_out_time, a.publish_up, a.publish_down, a.attribs, a.hits, a.images, a.urls, a.ordering, a.metakey, a.metadesc, a.access, CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(":", a.id, a.alias) ELSE a.id END AS slug, CASE WHEN CHAR_LENGTH(cc.alias) THEN CONCAT_WS(":", cc.id, cc.alias) ELSE cc.id END AS catslug, CHAR_LENGTH( a.`fulltext` ) AS readmore, u.name AS author, u.usertype, g.name AS groups, u.email AS author_email
-> FROM bak_content AS a
-> FORCE INDEX (idx_title_created)
-> LEFT JOIN bak_categories AS cc
-> ON a.catid = cc.id
-> LEFT JOIN bak_users AS u
-> ON u.id = a.created_by
-> LEFT JOIN bak_groups AS g
-> ON a.access = g.id
-> WHERE 1
-> AND a.access <= 0
-> AND a.catid = 108
-> AND a.state = 1
-> AND ( publish_up = '0000-00-00 00:00:00' OR publish_up <= '2012-02-08
-> AND ( publish_down = '0000-00-00 00:00:00' OR publish_down >= '2012-0
-> ORDER BY a.title, a.created DESC
-> LIMIT 0, 10;
有时MySQL很难找到合适的索引。您可以通过暗示正确的索引来解决此问题 提示语法: 确保你有正确的索引,并通过实验来调整它的性能
干杯 你能试试这个变化吗:
SELECT cc.title AS category, ...
FROM
( SELECT *
FROM j15_content AS a
USE INDEX (title) --- with and without the hint
WHERE 1
AND a.access <= 0
AND a.catid = 108
AND a.state = 1
AND ( publish_up = '0000-00-00 00:00:00'
OR publish_up <= '2012-02-08 00:16:26' )
AND ( publish_down = '0000-00-00 00:00:00'
OR publish_down >= '2012-02-08 00:16:26' )
ORDER BY a.title, a.created DESC
LIMIT 0, 10
) AS a
LEFT JOIN j15_categories AS cc
ON a.catid = cc.id
LEFT JOIN j15_users AS u
ON u.id = a.created_by
LEFT JOIN j15_groups AS g
ON a.access = g.id
我认为在catid、state、title上建立索引会更好。也许尝试一下这一点可能会有所帮助: 创建索引idx_catid_title_,在j15_内容catid上创建,标题8,已创建; j15_内容上的下降指数idx_catid;
恐怕这不能用索引、提示或查询本身的重组来合理地解决 这样做很慢的原因是它需要一个2M行的文件排序,这实际上需要很长时间。如果按顺序放大,则会将其指定为order by a.title,a.created DESC。问题是排序超过1列和具有DESC部分的组合。Mysql不支持降序索引。中支持关键字DESC,但仅供将来使用 建议的解决方法是创建一个额外的列“reverse\u created”,该列将自动填充,以便您的查询可以使用ORDER BY a.title,a.reverse\u created。所以你用max_time-created_time来填充它。然后在该组合上创建一个索引,如果需要,将该索引指定为提示 关于这个话题,有几篇非常好的博客文章可以更好地解释这一点,并举例说明:
-更新-通过在查询中从order by中删除DESC部分,您应该能够对此进行快速测试。结果在功能上是错误的,但它应该使用现有的索引,否则力会起作用。您是否尝试过增加这些值tmp\u table\u size和max\u heap\u table\u size: 这里有一个简短的解释,也有每个细节的链接
希望这有帮助 我希望这在语法上是正确的
SELECT
cc.title AS category,
a.id, a.title, a.alias, a.title_alias,
a.introtext, a.fulltext, a.sectionid,
a.state, a.catid, a.created, a.created_by,
a.created_by_alias, a.modified, a.modified_by,
a.checked_out, a.checked_out_time,
a.publish_up, a.publish_down, a.attribs,
a.hits, a.images, a.urls, a.ordering, a.metakey,
a.metadesc, a.access,
CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(":", a.id, a.alias) ELSE a.id END AS slug,
CASE WHEN CHAR_LENGTH(cc.alias) THEN CONCAT_WS(":", cc.id, cc.alias) ELSE cc.id END AS catslug, CHAR_LENGTH( a.`fulltext` ) AS readmore,
u.name AS author, u.usertype, g.name AS groups, u.email AS author_email
FROM
(
SELECT aa.*
FROM
(
SELECT id FROM
FROM j15_content
WHERE catid=108 AND state=1
AND a.access <= 0
AND (publish_up = '0000-00-00 00:00:00' OR publish_up <= '2012-02-08 00:16:26')
AND (publish_down = '0000-00-00 00:00:00' OR publish_down >= '2012-02-08 00:16:26')
ORDER BY title,created DESC
LIMIT 0,10
) needed_keys
LEFT JOIN j15_content aa USING (id)
) a
LEFT JOIN j15_categories AS cc ON a.catid = cc.id
LEFT JOIN j15_users AS u ON a.created_by = u.id
LEFT JOIN j15_groups AS g ON a.access = g.id;
试试看 如果不使用限制返回的行数,我会尝试使用以下索引之一:state、catid、access或state、catid、publish\u up或state、catid、publish\u down?您也可以尝试强制使用idx\u title\u创建的索引。谢谢,我很快就会尝试。publish_up/down几乎是不相关的,我很可能会从最终查询中删除它们,状态、catid和访问是最重要的。没有限制,这一类的文章大约有200万篇。我已经尝试强制索引无效,我将把结果附加到实际的问题帖子中。谢谢大家。access列可以有哪些值?我已经尝试强制索引,但这并不能解决问题。似乎我可能索引了错误的列,但我不确定哪些列应该/不应该在索引中。我假设由于查询的性质,需要一些复合索引。谢谢,我将很快尝试并回复您。索引对title、catid、id的影响是什么,这样结果就已经按title排序了。我想把它分成两个查询,如果我可以简单地提取文章id,然后执行一个单独的查询,然后使用1、2、3等中的where id返回所有相关的文章信息。查询仍然返回:1028-Sort aborted。
SELECT cc.title AS category, ...
FROM
( SELECT *
FROM j15_content AS a
USE INDEX (title) --- with and without the hint
WHERE 1
AND a.access <= 0
AND a.catid = 108
AND a.state = 1
AND ( publish_up = '0000-00-00 00:00:00'
OR publish_up <= '2012-02-08 00:16:26' )
AND ( publish_down = '0000-00-00 00:00:00'
OR publish_down >= '2012-02-08 00:16:26' )
ORDER BY a.title, a.created DESC
LIMIT 0, 10
) AS a
LEFT JOIN j15_categories AS cc
ON a.catid = cc.id
LEFT JOIN j15_users AS u
ON u.id = a.created_by
LEFT JOIN j15_groups AS g
ON a.access = g.id
SELECT
cc.title AS category,
a.id, a.title, a.alias, a.title_alias,
a.introtext, a.fulltext, a.sectionid,
a.state, a.catid, a.created, a.created_by,
a.created_by_alias, a.modified, a.modified_by,
a.checked_out, a.checked_out_time,
a.publish_up, a.publish_down, a.attribs,
a.hits, a.images, a.urls, a.ordering, a.metakey,
a.metadesc, a.access,
CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(":", a.id, a.alias) ELSE a.id END AS slug,
CASE WHEN CHAR_LENGTH(cc.alias) THEN CONCAT_WS(":", cc.id, cc.alias) ELSE cc.id END AS catslug, CHAR_LENGTH( a.`fulltext` ) AS readmore,
u.name AS author, u.usertype, g.name AS groups, u.email AS author_email
FROM
(
SELECT aa.*
FROM
(
SELECT id FROM
FROM j15_content
WHERE catid=108 AND state=1
AND a.access <= 0
AND (publish_up = '0000-00-00 00:00:00' OR publish_up <= '2012-02-08 00:16:26')
AND (publish_down = '0000-00-00 00:00:00' OR publish_down >= '2012-02-08 00:16:26')
ORDER BY title,created DESC
LIMIT 0,10
) needed_keys
LEFT JOIN j15_content aa USING (id)
) a
LEFT JOIN j15_categories AS cc ON a.catid = cc.id
LEFT JOIN j15_users AS u ON a.created_by = u.id
LEFT JOIN j15_groups AS g ON a.access = g.id;
ALTER TABLE j15_content ADD INDEX subquery_ndx (catid,state,access,title,created);