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

解释说：

'1', 'SIMPLE', 'ct_pricelistentry', 'ALL', 'PRIMARY', NULL, NULL, NULL, '34591', '使用where；使用文件排序'

'1', 'SIMPLE', 'lct_set', 'eq_ref', 'PRIMARY', 'PRIMARY', '292', 'const,dealers_v2.ct_pricelistentry.uid', '1', '使用where;使用索引'

注意：所有需要的索引都会显示，包括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', '在哪里使用'

'1', 'SIMPLE', 'lct_set', 'eq_ref', 'PRIMARY', 'PRIMARY', '292', 'const,dealers_v2.ct_pricelistentry.uid', '1', '使用where;使用 索引'

到底发生了什么？ 它是一个 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 是杀手。

为了防止对ORDER BY 使用文件排序，您需要一个包含WHERE 子句的全部 的单个（通常是复合）索引，加上 @ 987654327@ 列。在构造这样的索引时，WHERE 中可以处理的唯一 项是“=”子句。其他任何内容（例如您的OR）都会阻止优化。

为什么 OR 会受伤这样想……假设有一个按姓氏 + 名字排序的长打印姓名列表。查询要求WHERE last = 'Karakulov' ORDER BY first。你会跳到第一个 Karakulov，所有的名字都会按顺序排列。现在假设你想要WHERE (last = 'Karakulov' OR last = 'James') ORDER BY first。你可以得到你所有的亲戚和我所有的亲戚，但你仍然需要把他们洗牌来做ORDER BY first。 MySQL 有一种技术：文件排序（和一个通往它的 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% 的 可用 RAM。如果您将其保留在某个较低的默认值，那么您可能会受到 I/O 限制，因此速度很慢。

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