Question

我的问题是我有两个不同的查询在不同的情况下运行良好的情况。

SCHEMA

  messages 
      message_id, entity_id, message, timestamp

   subscription
      user_id, entity_id

   users
      user_id

   entities
      entity_id

情况1：大量消息条目和至少一个相关订阅条目

情况2：很少有消息条目和/或几个或零个相关的订阅条目

我的两个查询是：

 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（.000x秒）中运行良好：大量消息条目和至少一个相关的订阅条目。在情况2中，这个查询需要1.7秒以上。

 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

此查询在情境2（.000x秒）内运行良好：很少有消息条目和/或几个或零个相关的订阅条目。情况1中此查询将花费1.3秒以上。

我是否可以使用可以充分利用这两个世界的查询？如果没有，那么最好的方法是什么处理这种情况？

索引：

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

EXPLAIN INFO

限制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

尝试使用WHERE

更改AND

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

OR

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

OR可能就是这样：

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

如何改进密钥表和另一个密钥表之间的JOIN操作

1 个答案: