mysql - 优化MySQL单表2800万行聚合查询

Question

我需要帮助优化查询。有一个数据透视表保存与每个用户的通知 ID 匹配的用户 ID:

+----+---------+-----------------+
| id | user_id | notification_id |
+----+---------+-----------------+
|  1 |     234 |               3 |
|  2 |     546 |              34 |
|  3 |     646 |              11 |
+----+---------+-----------------+

user_id 和 notification_id 都是外键。该表有~2800 万行。

我们的想法是获取拥有超过 120 条通知的用户的 100 个 ID，按照通知最多的用户进行排序:

SELECT user_id, COUNT(feed_notification_id) AS notification_count 
FROM sd_user_feed_notification
GROUP BY user_id
HAVING notification_count >= 120
ORDER BY notification_count DESC
LIMIT 100

问题是上面的查询运行了超过 200 秒，因为它基本上必须遍历所有行来聚合通知。

外键已经是索引。查询本身非常简单。

有什么办法可以优化吗？

MySQL版本:5.6

Answer 1

如果(user_id, feed_notification_id)上没有复合索引，则索引可能无法完全满足查询。也就是说，执行计划正在对基础表页执行查找，以检查 feed_notification_id 是否为 NULL。 (COUNT(expr) 聚合不会包含表达式计算结果为 NULL 的行。)

我们(可能会)通过可以从索引满足的查询获得更好的性能，例如，通过删除对 feed_notification_id 列的引用。

如果我们保证 feed_notification_id 不为 NULL，那么这将为我们带来等效的结果:

EXPLAIN 
SELECT user_id
     , COUNT(1) AS notification_count 
  FROM sd_user_feed_notification
 GROUP BY user_id

(我们希望 EXPLAIN 输出在 Extra 列中显示“使用索引”。)

因此查询将只是索引的完整扫描，而不查找基础表。

<小时/>

仍然需要评估 2800 万行。 A 通过聚合表达式上的 ORDER BY，就无法回避“使用文件排序”操作。

<小时/>

如果我们必须坚持使用现有查询，那么(该查询的)最佳性能将是使用复合索引ON sd_user_feed_notification (user_id, feed_notification_id)。

添加该索引会使索引ON sd_user_feed_notification (user_id)变得多余。

<小时/>

跟进

问:(1) 我是否应该删除 user_id 和 notification_id 上的单个索引并仅在我的查询中保留复合索引？

问:(2) 这不会影响对该表运行的其他查询吗？

答:如果我们在 (user_id,feed_notification_id) 上添加复合索引，那么我们可以仅删除 (user_id) 上的索引。该复合索引适合支持外键约束。

任何受益于旧(单个 user_id 列)索引的查询都可以受益于替换(复合)索引(以 user_id 作为前导列。)

某些查询将受益更多，消除了对基础表中页面的查找(以检索 notification_id 的值。)

替换索引会更大，但它的工作原理是一样的，在我们查找与单个用户相关的行时，通过消除大量行来提高性能。

<小时/>

新的复合索引不会替代feed_notification_id列上的索引。

我们仍然需要一个将该列作为前导列的索引。 (我们可以将其替换为 (feed_notification_id,user_id) 上的复合索引。

索引中列的顺序很重要。

<小时/>

如果(user_id，feed_notification_id)的组合是UNIQUE，那么我们可以将索引定义为UNIQUE索引，并强制执行。

此外，如果此表纯粹是链接/关联/连接表，而不是实体表(即没有对此表的外键引用)，那么为了性能，我会考虑删除 id 列(大概定义为 PRIMARY (集群)键。

我倾向于这样的表定义:

CREATE TABLE sd_user_feed_notification
( user_id               INT NOT NULL COMMENT 'PK, FK ref user.id'
, feed_notification_id  INT NOT NULL COMMENT 'PK, FK ref feed_notification.id'
, PRIMARY KEY (user_id, feed_notification_id)
, KEY sd_user_feed_notification_IX (feed_notification_id, user_id)

, CONSTRAINT FK_sd_user_feed_notification_user 
  FOREIGN KEY (user_id)              REFERENCES sd_user (id) 
  ON UPDATE CASCADE ON DELETE CASCADE 

, CONSTRAINT FK_sd_user_feed_notification_feed
  FOREIGN KEY (feed_notification_id) REFERENCES sd_feed_notification (id)
  ON UPDATE CASCADE ON DELETE CASCADE

) ENGINE=InnoDB
;