MySQL ORDER BY 使用文件排序(2 个连接表)

Question

我在查询优化方面遇到了奇怪的问题。 SQL 由类似 ORM 的库生成，只有在读取数兆字节的 SQL 日志后才会检测到错误。

SELECT  
  `ct_pricelistentry`.`uid` as `uid`, `ct_pricelistentry`.`skuGroup` as `skuGroup`
FROM 
  `ct_pricelistentry` INNER JOIN `lct_set` 
ON `lct_set`.`parent_uid`='SET:ALLPRICELISTENTRIES' AND 
   `lct_set`.`ref_uid`=`ct_pricelistentry`.`uid` 
WHERE 
  (`isGroup` IS FALSE) AND 
  (`isService` IS FALSE) AND 
  (`brand` = 'BRAND:5513f43697d637.00632331' OR `brand` IS NULL) 
ORDER BY `skuGroup` ASC

EXPLAIN 说:

'1', 'SIMPLE', 'ct_pricelistentry', 'ALL', 'PRIMARY', NULL, NULL, NULL, '34591', 'Using where; Using filesort'

'1', 'SIMPLE', 'lct_set', 'eq_ref', 'PRIMARY', 'PRIMARY', '292', 'const,dealers_v2.ct_pricelistentry.uid', '1', 'Using where; Using index'

注意:提供了所有需要的索引，包括 skuGroup。但是索引 skuGroup 仍然没有在 EXPLAIN possible_keys 中列出。它也不能被 FORCE INDEX 强制执行(它只是禁用所有索引)。

经过一些研究，我发现了 hacky 解决方案，但不确定它是否按预期工作:

1. 添加FORCE INDEX (skuGroup),
2. 添加到 WHERE 子句虚拟 AND (skuGroup IS NULL OR skuGroup IS NOT NULL) 部分。

后续查询

SELECT  
  `ct_pricelistentry`.`uid` as `uid`, `ct_pricelistentry`.`skuGroup` as `skuGroup`
FROM 
  `ct_pricelistentry` FORCE INDEX (`skuGroup`) INNER JOIN `lct_set` 
ON `lct_set`.`parent_uid`='SET:ALLPRICELISTENTRIES' AND
   `lct_set`.`ref_uid`=`ct_pricelistentry`.`uid` 
WHERE 
  (`isGroup` IS FALSE) AND 
  (`isService` IS FALSE) AND 
  (`brand` = 'BRAND:5513f43697d637.00632331' OR `brand` IS NULL) AND
  (`skuGroup` IS NULL OR `skuGroup` IS NOT NULL)
ORDER BY `skuGroup` ASC

给出没有文件排序的 EXPLAIN，所以它似乎使用索引来获取有序行:

'1', 'SIMPLE', 'ct_pricelistentry', 'range', 'skuGroup', 'skuGroup', '768', NULL, '16911', 'Using where'

'1', 'SIMPLE', 'lct_set', 'eq_ref', 'PRIMARY', 'PRIMARY', '292', 'const,dealers_v2.ct_pricelistentry.uid', '1', 'Using where; Using index'

到底发生了什么？ 这是一个MySQL错误吗？我在 MySQL 5.1 - 5.5 上测试过 - 结果相同。您有更可预测/稳定的解决方案吗？

---- CREATE TABLE ----
CREATE TABLE IF NOT EXISTS `lct_set` (
  `parent_uid` varchar(48) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `ref_uid` varchar(48) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`parent_uid`,`ref_uid`),
  UNIQUE KEY `BACK_PRIMARY` (`ref_uid`,`parent_uid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE IF NOT EXISTS `ct_pricelistentry` (
  `uid` varchar(48) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
  `refcount` int(11) NOT NULL,
  `isDisposed` tinyint(1) DEFAULT NULL,
  `tag` text,
  `isGroup` tinyint(1) DEFAULT NULL,
  `parentEntry` varchar(48) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
  `externalUID` varchar(255) DEFAULT NULL,
  `productCode` varchar(16) DEFAULT NULL,
  `name` varchar(255) DEFAULT NULL,
  `sku` varchar(255) DEFAULT NULL,
  `skuGroup` varchar(255) DEFAULT NULL,
  `measureUnit` varchar(16) DEFAULT NULL,
  `image` varchar(48) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
  `itemClassExternalUID` varchar(255) DEFAULT NULL,
  `itemClassName` varchar(255) DEFAULT NULL,
  `itemClassDescription` text,
  `itemClassComments` text,
  `itemClassAttachments` varchar(48) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
  `brand` varchar(48) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
  `priceGroups` text,
  `productAttributes` text,
  `constituents` text,
  `position` int(11) DEFAULT NULL,
  `isService` tinyint(1) DEFAULT NULL,
  `stackability` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`uid`),
  UNIQUE KEY `test1` (`uid`,`skuGroup`),
  KEY `name` (`name`),
  KEY `sku` (`sku`),
  KEY `itemClassExternalUID` (`itemClassExternalUID`),
  KEY `parentEntry` (`parentEntry`),
  KEY `position` (`position`),
  KEY `externalUID` (`externalUID`),
  KEY `productCode` (`productCode`),
  KEY `skuGroup` (`skuGroup`),
  KEY `brand` (`brand`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Answer 1

修复 使用 INDEX(skuGroup) 避免了文件排序，但阻止了任何有用的过滤。优化过滤比避免文件排序更重要。

删除 FORCE 并添加此“复合”索引

INDEX(isGroup, isService, brand) -- (in any order)

它应该有所帮助，但可能不会阻止“使用文件排序”。 OR 是 killer 。

要防止对 ORDER BY 使用文件排序，您需要一个包含 所有 WHERE 子句的索引(通常是复合索引) , 加上 ORDER BY 列。在构建这样的索引时，唯一可以在WHERE 中处理的事情是and'd together '=' 子句。任何其他内容(例如您的 OR)都会阻止优化。

为什么 OR 会造成伤害 这样想...假设有一长串按姓氏 + 名字排序的姓名打印列表。查询要求 WHERE last = 'Karakulov' ORDER BY first。你会跳到第一个 Karakulov，所有的名字都会按顺序排列。现在假设您想要 WHERE (last = 'Karakulov' OR last = 'James') ORDER BY first。你可以得到你所有的亲戚和我所有的亲戚，但你仍然需要将他们洗牌在一起以执行 ORDER BY first。 MySQL 有一种技术:filesort(以及指向它的 tmp 表。)

作为安慰，filesort 的临时表通常是内存中的 MEMORY 表，因此速度相当快。

解决方法是有时将OR 转换为UNION。 (这可能对您的查询没有帮助。)

一些架构评论和其他注释......

UNIQUE 键没有用，因为 PRIMARY KEY 已经将 uid 声明为“唯一”。

VARCHAR(48) utf8 是一个相当笨拙的大键。它是某种形式的 UUID 吗？如果是这样，我有关于随机性、字符集和大小的讨厌的话要说。

有的uid是(48)，有的是(255)；这是故意的吗？

去掉 (skuGroupIS NULL ORskuGroupIS NOT NULL) -- 优化器可能不够聪明，无法意识到这一点永远是“真”!

FORCE INDEX 今天可能有效，但明天可能适得其反。摆脱它。

innodb_buffer_pool_size 的值是多少？如果您至少有 4GB 内存，它应该是 可用 RAM 的大约 70%。如果您将它保留在某个较低的默认值，那么您可能受 I/O 限制，因此速度很慢。

请提供 SHOW CREATE TABLE lct_set -- JOIN 中发生了一些奇怪的事情。