优化连接查询中的 order by 子句

Question

我需要帮助来优化此查询。

  SELECT messages.*
   FROM messages
   INNER JOIN subscription ON subscription.entity_id = messages.entity_id
   WHERE subscription.user_id = 1
   ORDER BY messages.timestamp DESC 
   LIMIT 50

没有限制，此查询返回 200K 行，运行大约需要 1.3 - 2 秒。问题似乎出在 order by 子句中。没有它，查询需要 0.0005 秒。

Indexes:
    ( subscription.user_id, subscription.entity_id )
    ( subscription.entity_id )
    ( messages.timestamp )
    ( messages.entity_id, messages.timestamp )

我可以通过将查询更改为以下内容来提高性能：

SELECT messages.* FROM messages
INNER JOIN subscription ON subscription.entity_id = messages.entity_id 
INNER JOIN ( 
   SELECT message_id FROM messages ORDER BY timestamp DESC
) as temp on temp.messsage_id = messages.message_id
WHERE subscription.user_id = 1 LIMIT 50

这将在 0.12 秒内运行。一个非常好的改进，但我想知道它是否可以更好。它似乎 如果我能以某种方式过滤第二个内部连接，那么事情会更快。

谢谢。

架构：

   messages 
      message_id, entity_id, message, timestamp

   subscription
      user_id, entity_id

更新

Raymond Nijland 的答案解决了我最初的问题，但又出现了一个问题

 SELECT messages.*
   FROM messages
   STRAIGHT_JOIN subscription ON subscription.entity_id = messages.entity_id
   WHERE subscription.user_id = 1
   ORDER BY messages.timestamp DESC 
   LIMIT 50

直接连接在两种情况下效率低下：

1. 订阅表中没有user_id条目

2. 消息表中相关条目很少

关于如何解决此问题的任何建议？如果不是从查询的角度来看，是应用程序吗？

更新

解释信息

限制 50

| id | select_type | table             | type   | possible_keys                           | key           | key_len | ref                                    | rows | Extra       |
|  1 | SIMPLE      | messages          | index  | idx_timestamp                           | idx_timestamp | 4       | NULL                                   |   50 |             |
|  1 | SIMPLE      | subscription      | eq_ref | PRIMARY,entity_id,user_id               | PRIMARY       | 16      | const, messages.entity_id              |    1 | Using index |

没有限制

| id | select_type | table             | type   | possible_keys                           | key           | key_len | ref                                    |   rows   | Extra         |
|  1 | SIMPLE      | messages          | ALL    | entity_id_2,entity_id                   | NULL          | NULL    | NUL                                    |   255069 | Using filesort|
|  1 | SIMPLE      | subscription      | eq_ref | PRIMARY,entity_id,user_id               | PRIMARY       | 16      | const, messages.entity_id              |        1 | Using index   |

创建表语句：

约 5000 行

subscription | CREATE TABLE `subscription` (
  `user_id`   bigint(20) unsigned NOT NULL,
  `entity_id` bigint(20) unsigned NOT NULL,
  PRIMARY KEY (`user_id`,`entity_id`),
  KEY `entity_id` (`entity_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

约 255,000 行

messages | CREATE TABLE `messages` (
  `message_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `entity_id` bigint(20) unsigned NOT NULL,
  `message` varchar(255) NOT NULL DEFAULT '',
  `timestamp` int(10) unsigned NOT NULL,
  PRIMARY KEY (`message_id`),
  KEY `entity_id` (`entity_id`,`timestamp`),
  KEY `idx_timestamp` (`timestamp`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 

Answer 1

删除索引messages.entity_id 这个是冗余的并尝试直接加入我认为mysql 优化器以错误的顺序访问您的表。 MySQL 需要首先访问表消息，以便它可以使用消息上的索引（实体 ID、时间戳）并消除对“使用临时；使用文件排序”的需要（如果 MySQL 需要创建基于 MyISAM 磁盘的表并且需要使用磁盘 I/O 读取和 I/O 写入排序（快速排序算法）。

 SELECT STRAIGHT_JOIN messages.*
   FROM messages
   INNER JOIN subscription ON subscription.entity_id = messages.entity_id
   WHERE subscription.user_id = 1
   ORDER BY messages.timestamp DESC 
   LIMIT 50

或

 SELECT messages.*
   FROM messages
   STRAIGHT_JOIN subscription ON subscription.entity_id = messages.entity_id
   WHERE subscription.user_id = 1
   ORDER BY messages.timestamp DESC 
   LIMIT 50

我也遇到过这个问题，我像 http://sqlfiddle.com/#!2/b34870/1 那样修复了它，但后来使用国家/城市表

编辑因为 Jason M 对 STRAIGHT_JOIN 的反应

直接连接在两种情况下效率低下：

订阅表中没有 user_id 条目

事实上，带有 INNER JOIN 的 MySQL 优化器会触发“在读取 const 表后注意到不可能的 WHERE”并且永远不会执行查询。 但是 STRAIGHT_JOIN 不会触发“在读取 const 表后注意到不可能的 WHERE”，因此需要进行（可能是完整的）索引扫描以找到可能会减慢查询执行速度的 user_id 值。 简单的解决方法是：将现有的 user_id 与 STRAIGHT_JOIN 一起使用

消息表中的相关条目很少

这里可能存在同样的问题 MySQL 认为它应该进行（可能是完整的）索引扫描以查找结果。但我需要查看 EXPLAIN 语句才能确定

您可能还想先尝试此查询

SELECT 
 *
FROM (

 SELECT
  entity_id

 FROM
  subscriptions

 WHERE
  subscription.user_id = 1 
)
 subscriptions

INNER JOIN 
 messages

ON
 subscriptions.entity_id = messages.entity_id

ORDER BY
 messages.timestamp DESC

LIMIT 50