MySQL“IN”运算符在使用左连接和分组的大量值上运行缓慢
[英]MySQL “IN” operator run slow on large amount of value with left join and group by
问题描述
I have a table with 20043428 postings.
我有一个包含 20043428 个帖子的表。 When I query table with a select statement, using IN operator on ownerId field with large amount of value, it run in very slow query times (>2second).当我使用 select 语句查询表时，在具有大量值的 ownerId 字段上使用 IN 运算符时，它以非常慢的查询时间（> 2 秒）运行。 Here's the schema of the story table:这是故事表的架构：
CREATE TABLE `Story` (
`storyId` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`storyType` int(11) DEFAULT '0',
`parentStoryId` bigint(20) unsigned DEFAULT NULL,
`ownerId` bigint(20) unsigned NOT NULL,
`lockroomId` bigint(20) unsigned DEFAULT NULL,
`isHost` tinyint(1) DEFAULT '0',
`updatedAt` timestamp(6) NULL DEFAULT CURRENT_TIMESTAMP(6),
`createdAt` timestamp(6) NULL DEFAULT CURRENT_TIMESTAMP(6),
`message` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci,
`imageUrl` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`amount` int(11) DEFAULT NULL,
`location` varchar(45) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`privacy` tinyint(1) NOT NULL DEFAULT '0',
`minutes` int(11) DEFAULT '0',
`hasCoinBadge` tinyint(1) DEFAULT '0',
`hasFriendBadge` tinyint(1) DEFAULT '0',
`localDBId` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci,
`tagName` varchar(63) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '',
`tagColor` varchar(15) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT '',
`tagId` bigint(20) DEFAULT NULL,
`numLikes` int(11) DEFAULT '0',
`numComments` int(11) DEFAULT '0',
`lastCommenterId` bigint(20) unsigned DEFAULT NULL,
`lastCommentTimestamp` timestamp(6) NULL DEFAULT CURRENT_TIMESTAMP(6),
`lastComment` varchar(256) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`secondLastCommenterId` bigint(20) unsigned DEFAULT NULL,
`secondLastCommentTimestamp` timestamp(6) NULL DEFAULT CURRENT_TIMESTAMP(6),
`secondLastComment` varchar(256) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`lastLikerId` bigint(20) unsigned DEFAULT NULL,
`jointStoryInfo` text COLLATE utf8mb4_unicode_ci,
`milestoneImageUrl` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
PRIMARY KEY (`storyId`),
UNIQUE KEY `StoryId_UNIQUE` (`storyId`),
KEY `ownerId` (`ownerId`),
KEY `parentStoryId` (`parentStoryId`),
KEY `updatedAt` (`updatedAt`),
KEY `ownerId_updatedAt` (`ownerId`,`updatedAt`),
KEY `updatedAt_ownerId_descending_index` (`updatedAt` DESC,`ownerId`),
KEY `lockroomId` (`lockroomId`),
KEY `combine_lockroomId_Index` (`storyType`,`lockroomId`),
KEY `combine_storyType_createdAt_index` (`storyType`,`ownerId`),
CONSTRAINT `ownerId` FOREIGN KEY (`ownerId`) REFERENCES `User` (`userId`),
CONSTRAINT `parentStoryId` FOREIGN KEY (`parentStoryId`) REFERENCES `Story` (`storyId`)
) ENGINE=InnoDB AUTO_INCREMENT=20043428 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
+----------------------------+---------------------+------+-----+----------------------+-------------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------------+---------------------+------+-----+----------------------+-------------------+
| storyId | bigint(20) unsigned | NO | PRI | NULL | auto_increment |
| storyType | int(11) | YES | | 0 | |
| parentStoryId | bigint(20) unsigned | YES | MUL | NULL | |
| ownerId | bigint(20) unsigned | NO | MUL | NULL | |
| lockroomId | bigint(20) unsigned | YES | MUL | NULL | |
| isHost | tinyint(1) | YES | | 0 | |
| updatedAt | timestamp(6) | YES | MUL | CURRENT_TIMESTAMP(6) | DEFAULT_GENERATED |
| createdAt | timestamp(6) | YES | | CURRENT_TIMESTAMP(6) | DEFAULT_GENERATED |
| message | text | YES | | NULL | |
| imageUrl | varchar(255) | YES | | NULL | |
| amount | int(11) | YES | | NULL | |
| location | varchar(45) | YES | | NULL | |
| privacy | tinyint(1) | NO | | 0 | |
| minutes | int(11) | YES | | 0 | |
| hasCoinBadge | tinyint(1) | YES | | 0 | |
| hasFriendBadge | tinyint(1) | YES | | 0 | |
| localDBId | text | YES | | NULL | |
| tagName | varchar(63) | YES | | | |
| tagColor | varchar(15) | YES | | | |
| tagId | bigint(20) | YES | | NULL | |
| numLikes | int(11) | YES | | 0 | |
| numComments | int(11) | YES | | 0 | |
| lastCommenterId | bigint(20) unsigned | YES | | NULL | |
| lastCommentTimestamp | timestamp(6) | YES | | CURRENT_TIMESTAMP(6) | DEFAULT_GENERATED |
| lastComment | varchar(256) | YES | | NULL | |
| secondLastCommenterId | bigint(20) unsigned | YES | | NULL | |
| secondLastCommentTimestamp | timestamp(6) | YES | | CURRENT_TIMESTAMP(6) | DEFAULT_GENERATED |
| secondLastComment | varchar(256) | YES | | NULL | |
| lastLikerId | bigint(20) unsigned | YES | | NULL | |
+----------------------------+---------------------+------+-----+----------------------+-------------------+
Here is the index of Story Table:这是故事表的索引：
+-------+------------+------------------------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+-------+------------+------------------------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Story | 0 | PRIMARY | 1 | storyId | A | 19350090 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 0 | StoryId_UNIQUE | 1 | storyId | A | 19350090 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 1 | ownerId | 1 | ownerId | A | 1255716 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 1 | parentStoryId | 1 | parentStoryId | A | 1 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | updatedAt | 1 | updatedAt | A | 19350090 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | ownerId_updatedAt | 1 | ownerId | A | 1743714 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 1 | ownerId_updatedAt | 2 | updatedAt | A | 19350090 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | updatedAt_ownerId_descending_index | 1 | updatedAt | D | 19139564 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | updatedAt_ownerId_descending_index | 2 | ownerId | A | 18636190 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 1 | lockroomId | 1 | lockroomId | A | 328860 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_lockroomId_Index | 1 | storyType | A | 685 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_lockroomId_Index | 2 | lockroomId | A | 221470 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_storyType_createdAt_index | 1 | storyType | A | 542 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_storyType_createdAt_index | 2 | ownerId | A | 1013545 | NULL | NULL | | BTREE | | | YES | NULL |
+-------+------------+------------------------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
And here's the query that takes >3 second to execute.这是执行时间超过 3 秒的查询。 What this query do is to get the all the Story that user in the ownerId set.这个查询的作用是获取该用户在 ownerId 集合中的所有故事。 As a result I use IN operator.因此，我使用 IN 运算符。
SELECT
*
FROM
((SELECT
Story.*,
jointStory.guestIds,
jointStory.guestStoryIds,
jointStory.guestTrees,
jointStory.guestDurations
FROM
Story
LEFT JOIN (SELECT
lockroomId,
GROUP_CONCAT(Story.ownerId) AS guestIds,
GROUP_CONCAT(Story.storyId) AS guestStoryIds,
GROUP_CONCAT(Story.imageUrl) AS guestTrees,
GROUP_CONCAT(Story.minutes) AS guestDurations
FROM
Story
WHERE
Story.storyType = 1
AND updatedAt < FROM_UNIXTIME(1600385817)
AND lockroomId IN (SELECT DISTINCT
lockroomId
FROM
Story
WHERE
ownerId IN (295840 , 657517, 853992, 887429, 895536, 938358, 1235164, 1240124, 1253845, 1272622, 1272677, 1302831, 1338671, 1395429, 1223590)
AND Story.storyType = 1
AND lockroomId IS NOT NULL)
GROUP BY Story.lockroomId) jointStory ON jointStory.lockroomId = Story.lockroomId
WHERE
Story.storyType = 2
AND Story.privacy = 0
AND Story.updatedAt < FROM_UNIXTIME(1600385817)
AND ownerId IN (295840 , 657517, 853992, 887429, 895536, 938358, 1235164, 1240124, 1253845, 1272622, 1272677, 1302831, 1338671, 1395429, 1223590)
AND Story.lockroomId IS NOT NULL
GROUP BY Story.lockroomId
ORDER BY updatedAt DESC
LIMIT 10) UNION ALL (SELECT
Story.*, NULL, NULL, NULL, NULL
FROM
Story
WHERE
Story.storyType = 0 AND privacy = 0
AND ownerId IN (295840 , 657517, 853992, 887429, 895536, 938358, 1235164, 1240124, 1253845, 1272622, 1272677, 1302831, 1338671, 1395429, 1223590)
AND updatedAt < FROM_UNIXTIME(1600385817)
ORDER BY updatedAt DESC
LIMIT 10)) newsFeed
LEFT JOIN
StoryEngagement ON StoryEngagement.storyId = newsFeed.storyId
AND StoryEngagement.userId = 1223590
ORDER BY updatedAt DESC
LIMIT 10;
The result of the explain extended command on this query shows that MySQL is using filesort and using index condition:该查询的解释扩展命令的结果显示 MySQL 正在使用文件排序和使用索引条件：
+----+-------------+-----------------+------------+--------+----------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------+---------+-----------------------------+------+----------+-------------------------------------------------------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-----------------+------------+--------+----------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------+---------+-----------------------------+------+----------+-------------------------------------------------------------------------------------------------+
| 1 | PRIMARY | <derived2> | NULL | ALL | NULL | NULL | NULL | NULL | 12 | 100.00 | Using filesort |
| 1 | PRIMARY | StoryEngagement | NULL | eq_ref | PRIMARY | PRIMARY | 16 | const,newsFeed.storyId | 1 | 100.00 | Using where |
| 2 | DERIVED | Story | NULL | range | ownerId,updatedAt,ownerId_updatedAt,updatedAt_ownerId_descending_index,lockroomId,combine_lockroomId_Index,combine_storyType_createdAt_index | combine_storyType_createdAt_index | 13 | NULL | 124 | 0.51 | Using index condition; Using where; Using MRR; Using temporary; Using filesort |
| 2 | DERIVED | <derived3> | NULL | ref | <auto_key0> | <auto_key0> | 9 | flora_test.Story.lockroomId | 2 | 100.00 | NULL |
| 3 | DERIVED | Story | NULL | range | ownerId,ownerId_updatedAt,lockroomId,combine_lockroomId_Index,combine_storyType_createdAt_index | combine_storyType_createdAt_index | 13 | NULL | 169 | 10.17 | Using index condition; Using where; Using MRR; Using temporary; Using filesort; Start temporary |
| 3 | DERIVED | Story | NULL | ref | updatedAt,updatedAt_ownerId_descending_index,lockroomId,combine_lockroomId_Index,combine_storyType_createdAt_index | lockroomId | 9 | flora_test.Story.lockroomId | 58 | 0.10 | Using where; End temporary |
| 5 | UNION | Story | NULL | range | ownerId,updatedAt,ownerId_updatedAt,updatedAt_ownerId_descending_index,combine_lockroomId_Index,combine_storyType_createdAt_index | combine_storyType_createdAt_index | 13 | NULL | 3517 | 5.00 | Using index condition; Using where; Using filesort |
+----+-------------+-----------------+------------+--------+----------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------+---------+-----------------------------+------+----------+-------------------------------------------------------------------------------------------------+
It would be very appreciate if you have any ideas on how to optimize this query.如果您对如何优化此查询有任何想法，将不胜感激。 It would be great if there is a way that do not need to create index and make this query run faster, because this is a huge production table and adding index take very long time, also adding some new index may cause other query run slower.如果有一种不需要创建索引的方法可以让这个查询运行得更快，那就太好了，因为这是一个巨大的生产表，添加索引需要很长时间，而且添加一些新索引可能会导致其他查询运行更慢。 I have already tried a few things such as creating a combined index on group by fields( index(storyType,ownerId) ) as suggested by a few blog postings, but run even slower...我已经尝试了一些方法，例如按照一些博客帖子的建议在 group by fields( index(storyType,ownerId) ) 上创建组合索引，但运行速度更慢...
UPDATE更新
I rewrite the query as you suggested and I add those covering index.我按照您的建议重写了查询，并添加了那些覆盖索引。
INDEX(storyType, lockroomId, ownerId)
INDEX(storyType, privacy, ownerId)
INDEX(storyType, privacy, updatedAt)
Here is the index set of this table:这是该表的索引集：
+-------+------------+---------------------------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression |
+-------+------------+---------------------------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
| Story | 0 | PRIMARY | 1 | storyId | A | 19350090 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 0 | StoryId_UNIQUE | 1 | storyId | A | 19350090 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 1 | ownerId | 1 | ownerId | A | 1255716 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 1 | parentStoryId | 1 | parentStoryId | A | 1 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | updatedAt | 1 | updatedAt | A | 19350090 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | ownerId_updatedAt | 1 | ownerId | A | 1743714 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 1 | ownerId_updatedAt | 2 | updatedAt | A | 19350090 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | updatedAt_ownerId_descending_index | 1 | updatedAt | D | 19139564 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | updatedAt_ownerId_descending_index | 2 | ownerId | A | 18636190 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 1 | lockroomId | 1 | lockroomId | A | 328860 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_story_index | 1 | storyType | A | 429 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_story_index | 2 | lockroomId | A | 665208 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_story_index | 3 | createdAt | A | 19350090 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_story_index | 4 | ownerId | A | 19350090 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 1 | combine_story_privacy_ownerId_index | 1 | storyType | A | 514 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_story_privacy_ownerId_index | 2 | privacy | A | 1544 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 1 | combine_story_privacy_ownerId_index | 3 | ownerId | A | 1924457 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 1 | combine_story_privacy_updatedAt_index | 1 | storyType | A | 527 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_story_privacy_updatedAt_index | 2 | privacy | A | 1582 | NULL | NULL | | BTREE | | | YES | NULL |
| Story | 1 | combine_story_privacy_updatedAt_index | 3 | updatedAt | A | 19350090 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_type_lockroomId_ownerId_index | 1 | storyType | A | 523 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_type_lockroomId_ownerId_index | 2 | lockroomId | A | 734891 | NULL | NULL | YES | BTREE | | | YES | NULL |
| Story | 1 | combine_type_lockroomId_ownerId_index | 3 | ownerId | A | 1267468 | NULL | NULL | | BTREE | | | YES | NULL |
+-------+------------+---------------------------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+
However the query is still run slowly about 3.404sec.但是查询仍然运行缓慢，大约 3.404 秒。 Here is the EXPLAIN SELECT :这是解释EXPLAIN SELECT ：
+----+-------------+-----------------+------------+--------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+---------+--------------------------------+-------+----------+----------------------------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-----------------+------------+--------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+---------+--------------------------------+-------+----------+----------------------------------------------------------------------+
| 1 | PRIMARY | <derived2> | NULL | ALL | NULL | NULL | NULL | NULL | 12 | 100.00 | Using filesort |
| 1 | PRIMARY | StoryEngagement | NULL | eq_ref | PRIMARY | PRIMARY | 16 | const,newsFeed.storyId | 1 | 100.00 | Using where |
| 2 | DERIVED | Story | NULL | range | ownerId,updatedAt,ownerId_updatedAt,updatedAt_ownerId_descending_index,lockroomId,combine_story_index,combine_story_privacy_ownerId_index,combine_story_privacy_updatedAt_index,combine_type_lockroomId_ownerId_index | combine_story_privacy_ownerId_index | 14 | NULL | 27 | 5.09 | Using index condition; Using where; Using temporary; Using filesort |
| 2 | DERIVED | <derived3> | NULL | ref | <auto_key0> | <auto_key0> | 9 | flora_test.Story.lockroomId | 2 | 100.00 | NULL |
| 3 | DERIVED | s3 | NULL | ref | ownerId,ownerId_updatedAt,lockroomId,combine_story_index,combine_story_privacy_ownerId_index,combine_story_privacy_updatedAt_index,combine_type_lockroomId_ownerId_index | combine_type_lockroomId_ownerId_index | 5 | const | 36390 | 0.02 | Using where; Using index; Using temporary; Using filesort; LooseScan |
| 3 | DERIVED | s2 | NULL | ref | updatedAt,updatedAt_ownerId_descending_index,lockroomId,combine_story_index,combine_story_privacy_ownerId_index,combine_story_privacy_updatedAt_index,combine_type_lockroomId_ownerId_index | combine_type_lockroomId_ownerId_index | 14 | const,flora_test.s3.lockroomId | 26 | 50.00 | Using where |
| 5 | UNION | Story | NULL | range | ownerId,updatedAt,ownerId_updatedAt,updatedAt_ownerId_descending_index,combine_story_index,combine_story_privacy_ownerId_index,combine_story_privacy_updatedAt_index,combine_type_lockroomId_ownerId_index | combine_story_privacy_ownerId_index | 14 | NULL | 3906 | 50.00 | Using index condition; Using where; Using filesort |
+----+-------------+-----------------+------------+--------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------+---------+--------------------------------+-------+----------+----------------------------------------------------------------------+
After testing, I think the upper side of the UNION is slower.经过测试，我觉得UNION的上边比较慢。 And LEFT JOIN StoryEngagement is necessary, because this table store all the likeId CommentId.而LEFT JOIN StoryEngagement是必须的，因为这个表存储了所有的likeId CommentId。 As a result we need to join this table and get who comment or like on this story.因此，我们需要加入此表并了解谁对这个故事发表评论或点赞。
Thank you for helping me to solve the problem.谢谢你帮我解决问题。
1 个解决方案
解决方案1
0 2020-09-19 06:46:26
FROM Story
WHERE Story.storyType = 1
AND updatedAt < FROM_UNIXTIME(1600385817)
AND lockroomId IN (
SELECT DISTINCT lockroomId
FROM Story
WHERE ownerId IN (295840 , 657517, 853992, 887429, 895536,
938358, 1235164, 1240124, 1253845, 1272622,
1272677, 1302831, 1338671, 1395429, 1223590)
AND Story.storyType = 1
AND lockroomId IS NOT NULL
)
See if this is any faster:看看这是否更快：
FROM Story AS s2
WHERE s2.storyType = 1
AND s2.updatedAt < FROM_UNIXTIME(1600385817)
AND EXISTS ( SELECT 1 FROM Story
WHERE s3.ownerId IN (...)
AND s3.storyType = 1
AND s3.lockroomId = s2.lockroomId )
And have this "covering" index:并有这个“覆盖”索引：
INDEX(storyType, lockroomId, ownerId)
Please qualify all columns with aliases.请使用别名限定所有列。
For this为了这
WHERE Story.storyType = 2
AND Story.privacy = 0
AND Story.updatedAt < FROM_UNIXTIME(1600385817)
AND ownerId IN (295840 , 657517, 853992, 887429, 895536,
938358, 1235164, 1240124, 1253845, 1272622, 1272677, 1302831,
1338671, 1395429, 1223590
)
AND Story.lockroomId IS NOT NULL
have these有这些
INDEX(storyType, privacy, ownerId)
INDEX(storyType, privacy, updatedAt)
(The Optimizer will pick which one is better.) （优化器将选择哪个更好。）
For LEFT JOIN StoryEngagement ... , it is unclear whether having the join is needed and/or whether the LEFT has any effect.对于LEFT JOIN StoryEngagement ... ，尚不清楚是否需要加入和/或LEFT是否有任何效果。 It needs:它需要：
StoryEngagement: INDEX(userId, storyId) -- in either order
Which side of the UNION is slower? UNION哪一边比较慢？ Is it slow enough that we should focus on it and ignore (for now) the rest of the query?它是否足够慢以至于我们应该专注于它而忽略（现在）查询的其余部分？
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.
相关问题
Mysql LEFT JOIN很慢 - Mysql LEFT JOIN is slow
mysql左边加入一个非常大的表 - 超级慢 - mysql left join with a VERY large table - super slow
MySQL查询非常慢（Left-JOIN，GROUP BY等？） - Very slow MySQL query (Left-JOIN, GROUP BY, etc. ?)
MySQL查询左联接，分组和排序非常慢 - MySQL Query with left join, group by and order by extremely slow
MySQL左联接和分组 - MySQL left join and group by
使用GROUP BY进行MYSQL LEFT JOIN - MYSQL LEFT JOIN with GROUP BY
MySQL组由左连接 - MySQL group by with left join
MySQL左外连接很慢 - MySQL left outer join is slow
使用mysql缓慢左加入 - slow left join using mysql
mysql离开联接很慢 - Mysql left join very slow
相关标签