我有一个包含大约100.000个博客帖子的表格,通过1:n关系链接到包含50个Feed的表格。当我使用select语句查询两个表时,按发布表的datetime字段排序,MySQL总是使用filesort,导致查询时间非常慢(> 1秒)。这是postings
表(简化)的模式:
+---------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| feed_id | int(11) | NO | MUL | NULL | |
| crawl_date | datetime | NO | | NULL | |
| is_active | tinyint(1) | NO | MUL | 0 | |
| link | varchar(255) | NO | MUL | NULL | |
| author | varchar(255) | NO | | NULL | |
| title | varchar(255) | NO | | NULL | |
| excerpt | text | NO | | NULL | |
| long_excerpt | text | NO | | NULL | |
| user_offtopic_count | int(11) | NO | MUL | 0 | |
+---------------------+--------------+------+-----+---------+----------------+
这是feed
表:
+-------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| type | int(11) | NO | MUL | 0 | |
| title | varchar(255) | NO | | NULL | |
| website | varchar(255) | NO | | NULL | |
| url | varchar(255) | NO | | NULL | |
+-------------+--------------+------+-----+---------+----------------+
这是执行时间> 1秒的查询。请注意post_date
字段有一个索引,但是MySQL没有使用它来对发布表进行排序:
SELECT
`postings`.`id`,
UNIX_TIMESTAMP(postings.post_date) as post_date,
`postings`.`link`,
`postings`.`title`,
`postings`.`author`,
`postings`.`excerpt`,
`postings`.`long_excerpt`,
`feeds`.`title` AS feed_title,
`feeds`.`website` AS feed_website
FROM
(`postings`)
JOIN
`feeds`
ON
`feeds`.`id` = `postings`.`feed_id`
WHERE
`feeds`.`type` = 1 AND
`postings`.`user_offtopic_count` < 10 AND
`postings`.`is_active` = 1
ORDER BY
`postings`.`post_date` desc
LIMIT
15
此查询的explain extended
命令的结果显示MySQL正在使用filesort:
+----+-------------+----------+--------+---------------------------------------+-----------+---------+--------------------------+-------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+----------+--------+---------------------------------------+-----------+---------+--------------------------+-------+-----------------------------+
| 1 | SIMPLE | postings | ref | feed_id,is_active,user_offtopic_count | is_active | 1 | const | 30996 | Using where; Using filesort |
| 1 | SIMPLE | feeds | eq_ref | PRIMARY,type | PRIMARY | 4 | feedian.postings.feed_id | 1 | Using where |
+----+-------------+----------+--------+---------------------------------------+-----------+---------+--------------------------+-------+-----------------------------+
当我删除order by
部分时,MySQL停止使用filesort。如果您对如何优化此查询以使MySQL按照索引排序和选择数据有任何想法,请告诉我。我已经尝试了一些事情,比如在所有where / order by fields上创建一个组合索引,正如一些博客帖子所建议的那样,但这也不起作用。
答案 0 :(得分:37)
在postings (is_active, post_date)
(按此顺序)创建综合索引。
它既可用于is_active
的过滤,也可用于post_date
的排序。
MySQL
应在REF
中对此索引显示EXPLAIN EXTENDED
访问方法。
请注意,您的RANGE
过滤条件超过user_offtopic_count
,这就是为什么您不能在过滤和其他字段排序中使用此字段的索引。
根据user_offtopic_count
的选择性(即多少行满足user_offtopic_count < 10
),在user_offtopic_count
上创建索引并对post_dates进行排序可能更有用。 / p>
为此,请在postings (is_active, user_offtopic_count)
上创建一个复合索引,并确保使用此索引上的RANGE
访问方法。
哪个索引会更快取决于您的数据分配。创建两个索引FORCE
,看看哪个更快:
CREATE INDEX ix_active_offtopic ON postings (is_active, user_offtopic_count);
CREATE INDEX ix_active_date ON postings (is_active, post_date);
SELECT
`postings`.`id`,
UNIX_TIMESTAMP(postings.post_date) as post_date,
`postings`.`link`,
`postings`.`title`,
`postings`.`author`,
`postings`.`excerpt`,
`postings`.`long_excerpt`,
`feeds`.`title` AS feed_title,
`feeds`.`website` AS feed_website
FROM
`postings` FORCE INDEX (ix_active_offtopic)
JOIN
`feeds`
ON
`feeds`.`id` = `postings`.`feed_id`
WHERE
`feeds`.`type` = 1 AND
`postings`.`user_offtopic_count` < 10 AND
`postings`.`is_active` = 1
ORDER BY
`postings`.`post_date` desc
LIMIT
15
/* This should show RANGE access with few rows and keep the FILESORT */
SELECT
`postings`.`id`,
UNIX_TIMESTAMP(postings.post_date) as post_date,
`postings`.`link`,
`postings`.`title`,
`postings`.`author`,
`postings`.`excerpt`,
`postings`.`long_excerpt`,
`feeds`.`title` AS feed_title,
`feeds`.`website` AS feed_website
FROM
`postings` FORCE INDEX (ix_active_date)
JOIN
`feeds`
ON
`feeds`.`id` = `postings`.`feed_id`
WHERE
`feeds`.`type` = 1 AND
`postings`.`user_offtopic_count` < 10 AND
`postings`.`is_active` = 1
ORDER BY
`postings`.`post_date` desc
LIMIT
15
/* This should show REF access with lots of rows and no FILESORT */
答案 1 :(得分:3)
MySQL有两种文件排序算法:一种较旧的文件排序,用于对磁盘上的记录进行排序,以及一种在内存中运行的新版本。
如果它无法在联接中的第一个表上使用索引来对查询进行排序,则必须执行文件排序。如果排序转换为固定宽度格式之前的结果集大于排序缓冲区 OR ,如果它包含任何文本字段,则必须使用较慢的磁盘上文件排序算法(第二个条件满足,因为您的查询有一个文本字段)。
MySQL正在选择使用is_active列,表面上是因为它认为列在继续其他连接和条件之前消除行是最具选择性的。我建议的第一件事是尝试使用post_date,feed_id和where条件中的列创建复合索引,例如: (is_active,user_offtopic_count,post_date,feed_id)。
答案 2 :(得分:3)
此外,重要的是要记住,如果您订购的列具有应用了该功能的话,MySQL将不会使用索引。
您还应该尝试将postss.post_date别名为别名。这将告诉MySQL按未更改的列排序,您仍然会选择unix时间戳。