在不使用嵌套查询的情况下使用 GROUP BY 和 ORDER BY 优化 JOINed 表上的 MySQL 查询答案

【问题标题】：Optimising MySQL query on JOINed tables with GROUP BY and ORDER BY without using nested queries在不使用嵌套查询的情况下使用 GROUP BY 和 ORDER BY 优化 JOINed 表上的 MySQL 查询
【发布时间】：2011-10-20 08:01:04
【问题描述】：

对我来说，这有点像一个初学者的 SQL 问题，但在这里。这就是我想要做的：

将三个表连接在一起，产品、标签和链接表。
将标签聚合到一个逗号分隔的字段中（因此是 GROUP_CONCAT 和 GROUP BY）
将结果限制为 30 个
按照“创建”日期的顺序获取结果
尽可能避免使用子查询，因为它们特别不适合使用 Active Record 框架编写代码

我已经在这篇文章的底部描述了涉及的表，但这是我正在执行的查询

   SELECT p.*, GROUP_CONCAT(pt.name) 
     FROM products p
LEFT JOIN product_tags_for_products pt4p ON (pt4p.product_id = p.id)
LEFT JOIN product_tags pt ON (pt.id = pt4p.product_tag_id)
 GROUP BY p.id
 ORDER BY p.created 
    LIMIT 30;

大约有 280,000 种产品、130 个标签、524,000 条链接记录，我已经分析了表格。问题是（在体面的硬件上）运行它需要超过 80 年代，这对我来说感觉不对。

这是解释结果：

id   select_type    table    type    possible_keys                    key                              key_len    ref                   rows  Extra
1    SIMPLE         p        index   NULL                             created                          4          NULL                  30    "Using temporary"
1    SIMPLE         pt4p     ref     idx_product_tags_for_products    idx_product_tags_for_products    3          s.id                  1     "Using index"
1    SIMPLE         pt       eq_ref  PRIMARY                          PRIMARY                          4          pt4p.product_tag_id   1

我认为它以错误的顺序做事，即在连接后对结果进行排序，使用大型临时表，然后进行限制。我脑海中的查询计划是这样的：

使用“created”键对 products 表进行排序
遍历每一行，将其与其他表进行 LEFT JOINing，直到达到 30 的 LIMIT。

这听起来很简单，但它似乎并不像那样工作 - 我错过了什么吗？

CREATE TABLE `products` (
  `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
  `title` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `rating` float NOT NULL,
  `created` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `last_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `active` tinyint(1) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `created` (`created`),
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

CREATE TABLE `product_tags_for_products` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `product_id` mediumint(8) unsigned NOT NULL,
  `product_tag_id` int(10) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_product_tags_for_products` (`product_id`,`product_tag_id`),
  KEY `product_tag_id` (`product_tag_id`),
  CONSTRAINT `product_tags_for_products_ibfk_1` FOREIGN KEY (`product_id`) REFERENCES `products` (`id`),
  CONSTRAINT `product_tags_for_products_ibfk_2` FOREIGN KEY (`product_tag_id`) REFERENCES `product_tags` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci


CREATE TABLE `product_tags` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(100) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

应 Salman A 的要求更新了分析信息：

Status,  
  Duration,CPU_user,CPU_system,Context_voluntary,Context_involuntary,Block_ops_in,Block_ops_out,Messages_sent,Messages_received,Page_faults_major,Page_faults_minor,Swaps,Source_function,Source_file,Source_line
starting,              
  0.000124,0.000106,0.000015,0,0,0,0,0,0,0,0,0,NULL,NULL,NULL
"Opening tables",      
  0.000022,0.000020,0.000003,0,0,0,0,0,0,0,0,0,"unknown function",sql_base.cc,4519
"System lock",   
  0.000007,0.000004,0.000002,0,0,0,0,0,0,0,0,0,"unknown function",lock.cc,258
"Table lock",   
  0.000011,0.000009,0.000002,0,0,0,0,0,0,0,0,0,"unknown function",lock.cc,269
init,           
  0.000055,0.000054,0.000001,0,0,0,0,0,0,0,0,0,"unknown function",sql_select.cc,2524
optimizing,       
  0.000008,0.000006,0.000002,0,0,0,0,0,0,0,0,0,"unknown function",sql_select.cc,833
statistics,      
  0.000116,0.000051,0.000066,0,0,0,0,0,0,0,1,0,"unknown function",sql_select.cc,1024
preparing,       
  0.000027,0.000023,0.000003,0,0,0,0,0,0,0,0,0,"unknown function",sql_select.cc,1046
"Creating tmp table",
  0.000054,0.000053,0.000002,0,0,0,0,0,0,0,0,0,"unknown function",sql_select.cc,1546
"Sorting for group", 
  0.000018,0.000015,0.000003,0,0,0,0,0,0,0,0,0,"unknown function",sql_select.cc,1596
executing,       
  0.000004,0.000002,0.000001,0,0,0,0,0,0,0,0,0,"unknown function",sql_select.cc,1780
"Copying to tmp table", 
  0.061716,0.049455,0.013560,0,18,0,0,0,0,0,3680,0,"unknown function",sql_select.cc,1927
"converting HEAP to MyISAM",
  0.046731,0.006371,0.017543,3,5,0,3,0,0,0,32,0,"unknown function",sql_select.cc,10980
"Copying to tmp table on disk", 
 10.700166,3.038211,1.191086,538,1230,1,31,0,0,0,65,0,"unknown function",sql_select.cc,11045
"Sorting result", 
  0.777887,0.155327,0.618896,2,137,0,1,0,0,0,634,0,"unknown function",sql_select.cc,2201
"Sending data", 
  0.000336,0.000159,0.000178,0,0,0,0,0,0,0,1,0,"unknown function",sql_select.cc,2334
end, 
  0.000005,0.000003,0.000002,0,0,0,0,0,0,0,0,0,"unknown function",sql_select.cc,2570
"removing tmp table", 
  0.106382,0.000058,0.080105,4,9,0,11,0,0,0,0,0,"unknown function",sql_select.cc,10912
end, 
  0.000015,0.000007,0.000007,0,0,0,0,0,0,0,0,0,"unknown function",sql_select.cc,10937
"query end", 
  0.000004,0.000002,0.000001,0,0,0,0,0,0,0,0,0,"unknown function",sql_parse.cc,5083
"freeing items", 
  0.000012,0.000012,0.000001,0,0,0,0,0,0,0,0,0,"unknown function",sql_parse.cc,6107
"removing tmp table", 
  0.000010,0.000009,0.000001,0,0,0,0,0,0,0,0,0,"unknown function",sql_select.cc,10912
"freeing items", 
  0.000084,0.000022,0.000057,0,1,0,0,1,0,0,0,0,"unknown function",sql_select.cc,10937
"logging slow query", 
  0.000004,0.000001,0.000001,0,0,0,0,0,0,0,0,0,"unknown function",sql_parse.cc,1723
"logging slow query", 
  0.000049,0.000031,0.000018,0,0,0,0,0,0,0,0,0,"unknown function",sql_parse.cc,1733
"cleaning up", 
  0.000007,0.000005,0.000002,0,0,0,0,0,0,0,0,0,"unknown function",sql_parse.cc,1691

这些表格是：

Products = 84.1MiB（products 表中有额外的字段，为清楚起见我省略了）标签 = 32KiB 链接表 = 46.6MiB

【问题讨论】：

您检查过您的 MySQL（尤其是 InnoDB）设置吗？
您能否发布（i）SET PROFILING = 1; /* the above query with SQL_NO_CACHE keyword */; SHOW PROFILE ALL; 的输出（ii）以 KB 为单位的三个表的大小。
更新了带有分析信息的帖子。奇怪的是，查询从 80 秒下降到了 10 秒，但仍然很慢。
其次，为什么你有不同大小的INT？虽然在上述查询中这不是问题，但请考虑 524000 int 与 524000 bigint = 2MB 大小差异。
按照消除Copying to tmp table on disk的各种建议，我尝试减少我下拉的字段（这不是一个很好的解决方案，因为我需要在结果中大部分）并增加@ 987654328@ 和 max_heap_table_size 从默认的 16Mb 到 512Mb。这解决了写入磁盘的问题，但在Copying to tmp table 中仍然需要 2.09 秒。也许我需要对如何避免生成临时表进行更多研究。

标签： mysql query-optimization

【解决方案1】：

我会尝试首先将产品数量限制为 30 个，然后仅加入 30 个产品：

   SELECT p.*, GROUP_CONCAT(pt.name) as tags
     FROM (SELECT p30.* FROM products p30 ORDER BY p30.created LIMIT 30) p 
LEFT JOIN product_tags_for_products pt4p ON (pt4p.product_id = p.id) 
LEFT JOIN product_tags pt ON (pt.id = pt4p.product_tag_id) 
 GROUP BY p.id 
 ORDER BY p.created

我知道您说没有子查询，但您没有解释原因，而且我看不出有任何其他方法可以解决您的问题。

请注意，您可以通过将子选择放在视图中来消除子选择：

CREATE VIEW v_last30products AS 
  SELECT p30.* FROM products p30 ORDER BY p30.created LIMIT 30;

那么查询就简化为：

   SELECT p.*, GROUP_CONCAT(pt.name) as tags
     FROM v_last30products p 
LEFT JOIN product_tags_for_products pt4p ON (pt4p.product_id = p.id) 
LEFT JOIN product_tags pt ON (pt.id = pt4p.product_tag_id) 
 GROUP BY p.id 
 ORDER BY p.created

其他问题，你的n-to-n表product_tags_for_products

没有意义，我会像这样重组它：

CREATE TABLE `product_tags_for_products` (    
  `product_id` mediumint(8) unsigned NOT NULL,    
  `product_tag_id` int(10) unsigned NOT NULL,    
  PRIMARY KEY (`product_id`,`product_tag_id`),       
  CONSTRAINT `product_tags_for_products_ibfk_1` FOREIGN KEY (`product_id`) REFERENCES `products` (`id`),    
  CONSTRAINT `product_tags_for_products_ibfk_2` FOREIGN KEY (`product_tag_id`) REFERENCES `product_tags` (`id`)    
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

这应该使查询更快：
- 缩短使用的密钥（在 InnoDB 上，PK 始终包含在辅助密钥中）；
- 允许您使用比使用辅助密钥更快的PK；

更多速度问题
如果您仅将select * 替换为您需要的字段select p.title, p.rating, ... FROM，这也会加快速度。

【讨论】：

那将是一个子查询。这也意味着如果我以后想按标签过滤，通过添加 WHERE 子句或更改为 INNER JOIN，那么我很可能会得到不到 30 个结果。
OP 发布的EXPLAIN 暗示 MySQL 一开始就将 products 表限制为 30 行。
@SalmanA 确实，这让我很困惑，为什么要花这么长时间？
@SalmanA，我不这么认为，否则它不会花那么多时间。它确实在某个时间点创建了一个包含 30 行的临时表，但它似乎对该点之前的所有行都做了很多工作。
@Ben：你试过 Johan 的查询吗？它比你的版本快吗？它会产生不同的 EXPLAIN 计划吗？

【解决方案2】：

啊 - 我看到你 GROUP BY 上的所有键都不是 BTREE，默认情况下 PRIMARY 键是散列。它有助于在有排序索引时进行分组......否则它必须扫描......

我的意思是，我认为如果您为 p.id 和 p.created 添加一个基于 BTREE 的索引，将会有很大帮助。在这种情况下，我认为引擎将避免必须扫描/排序所有这些键来执行分组和排序。

【讨论】：

根据OP发布的表定义，他们所有的表都使用InnoDB，only supports B-tree indexes。（InnoDB 也有 adaptive hash indexes，但这些是根据现有的 B 树索引自动生成的。）

【解决方案3】：

关于标签过滤（您在 Johan's answer 的 cmets 中提到），如果显而易见的话

SELECT p.*, GROUP_CONCAT(pt.name) AS tags
FROM products p
  JOIN product_tags_for_products pt4p2 ON (pt4p2.product_id = p.id)
  JOIN product_tags pt2 ON (pt2.id = pt4p2.product_tag_id)
  LEFT JOIN product_tags_for_products pt4p ON (pt4p.product_id = p.id)
  LEFT JOIN product_tags pt ON (pt.id = pt4p.product_tag_id)
WHERE pt2.name IN ('some', 'tags', 'here')
GROUP BY p.id
ORDER BY p.created LIMIT 30

跑得不够快，你可以试试这个：

CREATE TEMPORARY TABLE products30
  SELECT p.*
  FROM products p
    JOIN product_tags_for_products pt4p ON (pt4p.product_id = p.id)
    JOIN product_tags pt ON (pt.id = pt4p.product_tag_id)
  WHERE pt.name IN ('some', 'tags', 'here')
  GROUP BY p.id
  ORDER BY p.created LIMIT 30

SELECT p.*, GROUP_CONCAT(pt.name) AS tags
FROM products30 p
  LEFT JOIN product_tags_for_products pt4p ON (pt4p.product_id = p.id)
  LEFT JOIN product_tags pt ON (pt.id = pt4p.product_tag_id)
GROUP BY p.id
ORDER BY p.created

（我使用临时表是因为您说“没有子查询”；我不知道它们在 Active Record 框架中是否更容易使用，但至少这是另一种方法。）

附言。关于您最初的问题的一个非常离奇的想法：如果您将GROUP BY p.id 子句更改为GROUP BY p.created, p.id，会有什么不同吗？可能不会，但我至少会尝试一下。

【讨论】：