mysql – 如何使用join和order-by优化此选择?

我们有两个表:

 CREATE TABLE `messages` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `created` int(10) unsigned DEFAULT '0',
  `user_id` int(11) DEFAULT '0',
....
  `subject_id` int(11) unsigned DEFAULT '0',
  PRIMARY KEY (`id`),
  UNIQUE KEY `id` (`id`),
  KEY `user_id` (`user_id`),
  KEY `created` (`created`),
  KEY `text_id` (`text_id`) USING BTREE,
  KEY `subject_id` (`subject_id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=237542180 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT

第二个:

CREATE TABLE `users` (
  `id` int(12) NOT NULL AUTO_INCREMENT,
  `email` char(150) DEFAULT NULL,
  `reg_time` int(10) unsigned DEFAULT '0',
  `password` char(255) DEFAULT NULL,
...................
  `moderation` int(1) unsigned NOT NULL DEFAULT '0',
  `tag` varchar(255) DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `id` (`id`),
  UNIQUE KEY `email` (`email`),
  KEY `created` (`reg_time`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=123585 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT

消息有~49M记录,用户有13k.数据库引擎:Aurora(MySQL兼容)5.6.10a

非常长的要求是

SELECT messages.*, users.administrator_group_id FROM messages 
    LEFT JOIN users ON messages.user_id = users.id 
    ORDER BY messages.id desc LIMIT 0,20

如果我在没有订单的情况下运行此请求则需要14-16秒.订购时间超过5分钟.

我考虑更改业务逻辑以避免此请求并限制来自消息的记录集,例如通过消息日期,但想知道是否有任何方法可以在同一硬件上加速它.

解决方法:

我从来没有使用过Aurora,并且可能与MySQL存在差异,但是当执行计划不是最优的时候,有一种方法在MySQL中经常用于类似的问题,即当它首先执行连接然后必须执行ORDER BY时大的中间结果集.

我们尝试首先在派生表中限制结果,然后重新加入,而不是连接2个表.这种方式索引将用于ORDER BY – LIMIT,然后它只需要在第二个表中执行N个搜索(在这种情况下为20):

SELECT 
    m.*, 
    u.administrator_group_id 
FROM 
    ( SELECT id 
      FROM messages 
      ORDER BY id DESC 
      LIMIT 20
    ) AS mi
  JOIN 
    messages AS m ON m.id = mi.id
  LEFT JOIN 
    users AS u ON m.user_id = u.id 
ORDER BY 
    mi.id DESC ;

一个变化:

SELECT 
    m.*, 
    u.administrator_group_id 
FROM 
    ( SELECT mi.* 
      FROM messages AS mi 
      ORDER BY mi.id DESC 
      LIMIT 20
    ) AS m
  LEFT JOIN 
    users AS u ON m.user_id = u.id 
ORDER BY 
    m.id DESC ;

尝试两者并检查执行计划和性能.在任何合理的硬件中,从一个或两个表中获取20行并使用索引的查询应该非常有效.以毫秒为单位,而不是秒或分钟.

上一篇:HPC市场份额剖析和全球超算计划


下一篇:分布式事务及详解