sql 连接顺序极​​大地改变了性能

Question

所以我在 mysql 中有两个表：articles 和articles_rubrics，都有~20.000 行

article 有多个 cols，但它的 article_id 已被索引。

articles_rubrics 只有两个列：article_id 和 rubrics_id，它们都是单独索引的，除此之外还有这两者的联合索引。

我的问题是，当我通过连接从这些表中选择数据时，顺序非常重要，这对我来说是个问题，我不明白它的原因：

SELECT article_id,rubric_id FROM articles
LEFT JOIN articles_rubrics USING(article_id)
WHERE rubric_id=1
ORDER BY article_id DESC
LIMIT 10;

并解释说（对于articles_rubrics）：

time: 0.312 s
key_len: 1
ref: const
rows: 7352
extra: Using where; Using temporary; Using filesort

但是当我切换它的顺序时：

SELECT article_id,rubric_id FROM articles_rubrics
LEFT JOIN articles USING(article_id)
WHERE rubric_id=1
ORDER BY article_id DESC
LIMIT 10;

并解释说（对于articles_rubrics）：

time: 0.001 s
key_len:9
ref: NULL
rows: 28
extra: Using where; Using index

所以我有两个表，这使得它们的查询速度慢了大约 300 倍。这怎么可能？

PS：我已经为这个例子大大简化了我的现实世界问题，但我偶然发现了这个，因为我的

SELECT * FROM articles [LEFT JOIN for 5 other tables]

耗时 1.5 秒，当我实际添加其他连接时，执行时间变为 0.006 秒。

显示索引：

show index from articles;
Table   Non_unique  Key_name    Seq_in_index    Column_name Collation   Cardinality Sub_part    Packed  Null    Index_type  Comment Index_comment
articles    0   PRIMARY 1   article_id  A   20043   NULL    NULL        BTREE        
articles    1   article_url_title   1   article_url_title   A   10021   NULL    NULL        BTREE        
articles    1   FULLTEXT    1   article_title   NULL    1   NULL    NULL        FULLTEXT         
articles    1   FULLTEXT    2   article_content NULL    1   NULL    NULL        FULLTEXT         

show index from articles_rubrics;
Table   Non_unique  Key_name    Seq_in_index    Column_name Collation   Cardinality Sub_part    Packed  Null    Index_type
articles_rubrics    0   PRIMARY 1   article_id  A   NULL    NULL    NULL        BTREE
articles_rubrics    0   PRIMARY 2   rubric_id   A   20814   NULL    NULL        BTREE
articles_rubrics    1   rubric_id   1   rubric_id   A   17  NULL    NULL        BTREE
articles_rubrics    1   article_id  1   article_id  A   20814   NULL    NULL        BTREE

Answer 1

SELECT article_id,rubric_id 
FROM articles
LEFT JOIN articles_rubrics USING(article_id)
WHERE rubric_id=1 <<<<<<<<<<<<<<<<<<<<<<<<<<< problem here
ORDER BY article_id DESC
LIMIT 10;

通过坚持从此查询返回的每一行都具有 rubric_id=1，您已经消除了两个表之间不匹配的任何行，因此使用 LEFT JOIN 没有任何意义

SELECT a.article_id, ar.rubric_id 
FROM articles AS a
INNER JOIN articles_rubrics AS ar ON a.article_id = ar.article_id
WHERE ar.rubric_id = 1
ORDER BY a.article_id DESC
LIMIT 10;

您需要在每个引用中使用表或表别名。

Answer 2

数据库上的联接操作是昂贵的过程。最好使用简单的 SELECT 嵌套。制作一个列表来存储数据，然后将列表中的项目用于下一个查询。

Answer 3

这两个查询运行相同，唯一的区别是两者都使用来自articles_rubrics 的article_id。

-- SELECT article_id,rubric_id FROM articles -- would be slow here
SELECT ar.article_id,ar.rubric_id FROM articles
JOIN articles_rubrics ar USING(article_id)
WHERE rubric_id=1
ORDER BY article_id DESC
LIMIT 10;

SELECT ar.article_id,ar.rubric_id FROM articles_rubrics ar
JOIN articles USING(article_id)
WHERE rubric_id=1
ORDER BY article_id DESC
LIMIT 10;

如果我强制 sql 服务器在结果中使用articles_rubrics 表，他会正确地确定这些文章实际上并不需要。但是，即使 article_id 用作键，服务器也不会自动执行此操作。

我仍然不完全理解为什么会发生这种情况（或者优化算法实际上是如何工作的），因为在这两种情况下，where rubric_id=1 都进入了articles_rubrics 表，并且在这两种情况下，选定的列已经存在（和join articles for存在再次运行，在这两种情况下）。

但是，由于某种原因，在第一个示例中，服务器决定首先加载所有文章，然后才检查每个文章的 rubric_id。