Question

我有一个包含4个表的MySql数据库（实际上远不止这些，但只有这4个与问题相关），让我们称之为A，B，C和D.这是Schema：

CREATE TABLE A
(
  pKey INT NOT NULL AUTO_INCREMENT,
  name NVARCHAR(50),
  PRIMARY KEY(pKey),
  UNIQUE INDEX(name)
);

CREATE TABLE C
(
  pKey INT NOT NULL AUTO_INCREMENT,
  PRIMARY KEY(pKey)
);

CREATE TABLE B
(
  pKey INT NOT NULL AUTO_INCREMENT,
  aKey INT NOT NULL,
  cKey INT NOT NULL,
  PRIMARY KEY(pKey),
  UNIQUE INDEX UniqueKey (aKey, cKey),
  FOREIGN KEY(aKey) REFERENCES A(pKey),
  FOREIGN KEY(cKey) REFERENCES C(pKey)
);

CREATE TABLE D
(
  pKey INT NOT NULL AUTO_INCREMENT,
  cKey INT NOT NULL,
  PRIMARY KEY(pKey),
  INDEX(cKey),
  FOREIGN KEY(cKey) REFERENCES C(pKey)
);

我正在运行以下查询：

SELECT 
    --stuff...
FROM A 
INNER JOIN B
    ON A.pKey=B.aKey
INNER JOIN C
    ON B.cKey=C.pKey
INNER JOIN D
    ON D.cKey=C.pKey
WHERE
    A.name=parameter_1;

问题是，这是一个在单个服务器上运行的大型数据库，并且大多数表都有100K +记录，并且表破坏1000万条记录并不罕见。一张表有超过2亿条记录。

撇开MySql和架构的任何问题（我都坚持使用），当我在这个查询上使用explain时，我对上面的查询有一些奇怪的行为。由于这种行为，我有几个问题。我会首先表现出奇怪的行为。

如果我只是在MySql中解析上述查询，那么我会在EXPLAIN输出的 ref 列中获得我期望的引用。但是，我需要将此查询作为较大查询的子查询运行。解释较大的查询为我提供了类似于上述查询的内容（这只是对应于此查询中的表的较大查询的行）：

+----+-------------+-------+-------+---------------------+---------+---------+-----------------+-------+--------------------------+
| id | select_type | table | type  | possible_keys       | key     | key_len | ref             | rows  | Extra                    |
+----+-------------+-------+-------+---------------------+---------+---------+-----------------+-------+--------------------------+
|  1 | SIMPLE      | A     | const | PRIMARY,key1,key2   | key1    | 38      |                 |     1 |                          |
|  1 | SIMPLE      | D     | index | key3                | key3    | 12      | NULL            | 73868 | Using index              |
|  1 | SIMPLE      | C     | index | PRIMARY,key3        | PRIMARY | 8       | NULL            |     1 |                          |
|  1 | SIMPLE      | B     | ref   | key4,UniqueKey,key6 | key4    | 12      | const,DB.D.key3 |     1 | Using where; Using index |
+----+-------------+-------+-------+---------------------+---------+---------+-----------------+-------+--------------------------+

MySql正在进行两次索引扫描和一次ref类型连接。如果我使用索引提示，我可以略微改进这一点，但只是略有改进。我之前说过，这个查询是作为子查询运行的。这是其他查询的格式：

SELECT
  --stuff
FROM
(
  --sub-query1
) a
INNER JOIN
(
  --the query I have a question about
) b
ON a.c1=b.c2

优化器完全忽略了表C，而是支持在两个外键列B.cKey = D.cKey上进行连接。 所以这里的问题1）为什么优化器会像这样忽略表C？

接下来，即使我确实使用了索引提示，并且它忽略了表C，它仍会进行索引扫描以加入B和D，尽管有适当的索引。的为什么吗

在上面的说明中，它表明表D中有73,868行。在这个问题上实际上有73,568行。被查询的其他表之一（此问题中未显示）有大约1亿行，因此优化它是非常重要的。对于完整查询，rows列的乘积约为2.37E42。是的，我已经考虑过减少查询中表的数量的方法;我需要获取的信息需要我正在访问的每个表，我无法更改数据库的体系结构。

最后，我在这里可以改变的唯一事情是查询和索引/约束。因为这是一个先前存在的系统，我被其他所有东西困住了。 还有其他方法可以进一步优化此操作吗？

谢谢！

编辑：我修改了超级查询的格式。

Answer 1

您可以为此架构添加索引吗？

如果是这样，我建议您将复合索引(name, pKey)添加到表A。不要费心对它施加独特的约束;你已经用其他索引处理过了。该复合将允许您的选择标准A.name=parameter_1，并且您的联接可以通过一次索引扫描得到满足。

使用单列表C只是为了消除不在该表中的结果集行。除非您的查询出现可怕的性能问题，否则我不会担心EXPLAIN会丢失它。

通常，在处理这些多路连接操作时，您应该尝试使用复合覆盖索引来帮助您提高性能。你可以阅读那种索引。

奇怪的MySql连接行为

1 个答案: