Question

我需要帮助优化查询。有一个数据透视表，其中包含与每个用户的通知ID匹配的用户ID：

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

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

我们的想法是获得100个拥有超过120个通知的用户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列中显示“Using index”。）

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

仍然需要评估2800万行。一个使用聚合表达式上的ORDER BY，“使用filesort”操作无法解决。

如果我们必须坚持使用现有查询，那么（该查询的）最佳性能将使用复合索引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索引，并强制执行。

此外，如果此表纯粹是一个链接/关联/连接表，并且不是实体表（即没有对该表的外键引用），那么为了提高性能，我会考虑删除{{1} }列（可能是定义为id（群集）密钥。

我倾向于像这样的表定义：

PRIMARY

Answer 2

sd_user_feed_notification听起来像是user和feed_notification之间的映射表。如果是这样，请删除FK并遵循给定here的规则以获得多对多表。那将包括

PRIMARY KEY(user_id, notification_id),  -- implies UNIQUE
INDEX(notification_id, user_id)         -- saying UNIQUE would be redundant

（反之亦然）。此时，处理所有上述注释。此外，该表只有2列，因此它与索引一样小 - 要么尽可能快。

在几乎情况下，添加INDEX(a)时请删除INDEX(a,b)。但不删除INDEX(b)。复合索引中列的顺序很重要。 More

针对具有2800万行的单个表优化MySQL聚合查询

2 个答案: