如何加快慢速SQL查询

时间：2017-05-23 12:12:26

标签： mysql sql optimization 

Table ideas: id, author_id, some_columns

Table ideas_tags: idea_id, tag_name

Table ideas_seen: idea_id, user_id

Table user: uid, ban, some_columns

我需要从列表中获得10个带有标签的想法，其作者不会被禁止，而且当前用户的想法不会出现。

现在我的查询如下：

SELECT 
ideas.*,  GROUP_CONCAT(DISTINCT IT_V.tag_name SEPARATOR '|||') AS tags 
FROM `ideas` 
LEFT JOIN ideas_tags IT 
ON ideas.id=IT.idea_id 
LEFT JOIN ideas_tags IT_V 
ON ideas.id=IT_V.idea_id 
LEFT JOIN ideas_seen IV 
ON ideas.id=IV.idea_id AND IV.user_id=145974517 
LEFT JOIN users ON users.uid=ideas.author_id 

WHERE author_id!=145974517 AND IV.id IS NULL AND ( (IT.tag_name = 'some_tag') OR (IT.tag_name = 'another_tag') OR (IT.tag_name IS NULL) ) AND active=1 AND deleted=0 AND (users.ban=0 OR users.ban IS NULL) 

GROUP BY ideas.id 
ORDER BY id DESC 
LIMIT 10

这是网站上最慢的查询，我不知道如何加快它。

说明： Explain query 

CREATE TABLE IF NOT EXISTS `ideas` (
`id` int(11) NOT NULL,
  `tutorial` tinyint(4) NOT NULL,
  `text` text NOT NULL,
  `author_id` int(11) NOT NULL,
  `active` bit(1) NOT NULL,
  `timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `views` int(11) NOT NULL,
  `views_all` int(11) DEFAULT '0',
  `deleted` tinyint(4) NOT NULL DEFAULT '0',
  `many_users` tinyint(4) DEFAULT NULL,
  `game_id` int(11) DEFAULT NULL
) ENGINE=InnoDB AUTO_INCREMENT=35983 DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `ideas_seen` (
`id` int(11) NOT NULL,
  `idea_id` int(11) NOT NULL,
  `user_id` int(11) NOT NULL
) ENGINE=InnoDB AUTO_INCREMENT=3694368 DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `ideas_tags` (
`id` int(11) NOT NULL,
  `idea_id` int(11) NOT NULL,
  `tag_name` tinytext NOT NULL
) ENGINE=InnoDB AUTO_INCREMENT=86832 DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `users` (
  `uid` int(11) NOT NULL,
  `email` tinytext,
  `password_hash` tinytext,
  `restore_code` tinytext NOT NULL,
  `last_action` timestamp NULL DEFAULT NULL,
  `score` float NOT NULL,
  `date_register` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `posts_length` int(11) DEFAULT NULL,
  `settings` text,
  `titles` int(11) NOT NULL DEFAULT '1',
  `filter` int(11) NOT NULL DEFAULT '1',
  `note` text NOT NULL,
  `ban` tinyint(4) DEFAULT NULL,
  `mod_send` smallint(6) DEFAULT '0',
  `mod_get` int(11) DEFAULT '0',
  `fp_notified` int(11) NOT NULL DEFAULT '0',
  `skilled` tinyint(4) NOT NULL DEFAULT '0',
  `show_only_skilled` tinyint(4) NOT NULL DEFAULT '0'
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


ALTER TABLE `ideas`
 ADD PRIMARY KEY (`id`), ADD KEY `author_id` (`author_id`), ADD KEY `game_id` (`game_id`), ADD KEY `active` (`active`), ADD KEY `many_users` (`many_users`), ADD KEY `deleted` (`deleted`), ADD KEY `tutorial` (`tutorial`), ADD FULLTEXT KEY `idea_text` (`text`);

ALTER TABLE `ideas_seen`
 ADD PRIMARY KEY (`id`), ADD KEY `user_id` (`user_id`), ADD KEY `idea_id` (`idea_id`);

ALTER TABLE `ideas_tags`
 ADD PRIMARY KEY (`id`), ADD KEY `tag_name` (`tag_name`(255)), ADD KEY `idea_id` (`idea_id`);

ALTER TABLE `users`
 ADD PRIMARY KEY (`uid`), ADD UNIQUE KEY `email` (`email`(255)), ADD KEY `ban` (`ban`), ADD KEY `fp_notified` (`fp_notified`), ADD KEY `skilled` (`skilled`);


ALTER TABLE `ideas`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT,AUTO_INCREMENT=35983;
ALTER TABLE `ideas_seen`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT,AUTO_INCREMENT=3694368;
ALTER TABLE `ideas_tags`
MODIFY `id` int(11) NOT NULL AUTO_INCREMENT,AUTO_INCREMENT=86832;

ALTER TABLE `ideas`
ADD CONSTRAINT `ideas_ibfk_1` FOREIGN KEY (`game_id`) REFERENCES `games` (`id`) ON DELETE NO ACTION;

ALTER TABLE `ideas_seen`
ADD CONSTRAINT `ideas_seen_ibfk_1` FOREIGN KEY (`idea_id`) REFERENCES `ideas` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION;

ALTER TABLE `ideas_tags`
ADD CONSTRAINT `ideas_tags_ibfk_2` FOREIGN KEY (`idea_id`) REFERENCES `ideas` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION;

1 个答案:

答案 0 :(得分：1)

  • 不要使用TINYTEXT;更改为VARCHAR(255)并删除索引上的“前缀”。也就是说，将INDEX email(255)更改为INDEX(email)。

  • 不要索引“标志”，不会使用这些索引，因为它们没用。示例：deleted

  • 不要将一个索引作为另一个索引的“左”部分。示例PRIMARY KEY(id) vs INDEX(id, ...)。在PRIMARY KEY的情况下，保留它;抛弃另一个没有提供额外的好处。

  • 我认为没有必要两次加入idea_tags;看看你是否可以避免这种情况。

  • 查询遭受“膨胀 - 放气”综合症。首先，它使用JOINs来扩充行数，然后使用GROUP BY来回到原始行（减去一些被过滤掉的行）。这样做，笨重{{1}在临时表中被拖走。

  • ideas.*（包括TEXT）阻止更有效地使用TINYTEXT用于tmp表。

让我们逐步消除膨胀 - 放气。

首先，让我们构建外部部分：

MEMORY

假设我们可以填写SELECT ideas.*, ( ??? ) as tags FROM ideas WHERE ??? ORDER BY ideas.id DESC LIMIT 10; ，我们现在可以更快地进行评估。这需要???上的索引，与id一起使用。幸运的是，（并且没有PRIMARY KEY(id)），仅需要触及10行。 （在您的版本中，必须收集，分组，整理整个表格，然后才交付。）

由于您的所有WHERE都是JOINs，我们可以证明触及除LEFT JOINs以外的表格的WHERE子句不会过滤掉任何行。离开

ideas

为此，我们有（虽然我不确定它会被使用）：

WHERE author_id!=145974517
  AND  active=1
  AND  deleted=0

返回INDEX(active, deleted, author_id) ...现在删除查询以获取AS tags值，以便为给定的tag_name生成GROUP_CONCAT：

ideas.id

（这里我迷失了为什么有SELECT GROUP_CONCAT(DISTINCT IT_V.tag_name SEPARATOR '|||') AS tags FROM ideas_tags IT_V ON ideas.id = IT_V.idea_id AND ( IT.tag_name = 'some_tag' OR IT.tag_name = 'another_tag' OR IT.tag_name IS NULL ) 的两个连接。）同时，我建议idea_tags可以是获得SELECT的子查询。

嗯..怎么样

tags

这似乎是 no 过滤，因为它是LEFT JOIN users ON users.uid = ideas.author_id WHERE ( users.ban=0 OR users.ban IS NULL ) 。它似乎提供了 no 列，因为其他地方没有提到LEFT。那么，我必须假设它是浪费的代码？

同上

users

因此，它已经归结为删除一些索引，添加一个索引，并将查询重写为

LEFT JOIN  ideas_seen IV    ON ideas.id = IV.idea_id
                 AND  IV.user_id=145974517
WHERE   IV.id IS NULL

可能SELECT ideas.*, ( SELECT GROUP_CONCAT(DISTINCT IT_V.tag_name SEPARATOR '|||') FROM ideas_tags IT_V WHERE ideas.id = IT_V.idea_id AND ( IT.tag_name = 'some_tag' OR IT.tag_name = 'another_tag' OR IT.tag_name IS NULL ) ) as tags FROM ideas WHERE author_id!=145974517 AND active=1 AND deleted=0 ORDER BY ideas.id DESC LIMIT 10; 是不必要的。

相关问题
最新问题