帮助提高查询的性能

Question

概述：

我有一个构建查询语句的系统。其中一些必须根据传递到系统的设置参数将一些表连接到其他表。在对创建的查询运行一些性能测试时，我注意到一些查询正在执行 FULL TABLE SCANS，在许多情况下，根据我所读到的内容，这对大表不利。

我想做的事：

1 - Remove the full table scans 
2 - Speed up the Query
3 - Find out if there is a more efficient query I can have the system build instead

查询：

SELECT a.p_id_one, b.p_id_two, b.fk_id_one, c.fk_id_two, d.fk_id_two, 
d.id_three, d.fk_id_one 
FROM ATable a 
LEFT JOIN BTable b ON a.p_id_one = b.fk_id_one 
LEFT JOIN CTable c ON b.p_id_two = c.fk_id_two 
LEFT JOIN DTable d ON b.p_id_two = d.fk_id_two 
WHERE a.p_id_one = 1234567890

The Explain

查询时间

Showing rows 0 - 10 (11 total, Query took 0.0016 seconds.)

当前问题：

1 - 我的系统/DBMS (phpmyadmin) 的查询时间在 0.0013 秒到 0.0017 秒之间。

• 我做了哪些修复工作？
  全表扫描或“ALL”类型的查询正在表（“BTable”、“DTable”）上运行，所以我尝试在适当的 id 上使用 FORCE INDEX。 使用 FORCE INDEX 会删除全表扫描，但不会加快 表现。 我仔细检查了我的 fk_constraints 和索引关系，以确保我没有遗漏任何东西。到目前为止，一切都已验证完毕。

2 - 顾问显示多个警告，其中一些与全表扫描和索引有关。

问题：

假设所有索引都可用并已创建

1 - 有没有更好的方法来执行这个查询？

2 - 多少个连接是太多连接？

3 - 连接可能是问题吗？

4 - 问题是否存在于 WHERE 子句中？

5 - 我可能错过了哪些优化技术/工具？

6 - 我怎样才能让这个查询以 0.0008 和 0.0001 之间的速度执行？

如果需要图像和视觉效果来帮助澄清我的情况，请在下面的评论中提问。我感谢任何和所有的帮助。

谢谢你=)

Answer 1

“p_id_one”并没有告诉我们太多。这是一个自动增量吗？真实的列名有时会提供重要的基数和意图线索。正如威廉所说，“这个问题肯定还有更多”和“整体问题是什么”。

LEFT -- 你需要吗？它阻止了某些形式的优化；如果“右”表行不是可选的，则将其删除。

WHERE a.p_id_one = 1234567890 需要INDEX(p_id_one)。已经是PRIMARY KEY 了吗？在这种情况下，不需要额外的INDEX。 （请提供SHOW CREATE TABLE。）

那些真的是你SELECTing的列/表达式吗？它可以有所作为——尤其是在建议将“覆盖索引”作为优化时。

请提供EXPLAIN SELECT ... 的输出（这不是您提供的讨论。）该输出将有助于提供 1:many、基数等线索。

如果这些是FOREIGN KEYs，则您已经在 b.fk_id_one、c.fk_id_two、d.fk_id_two 上有索引；所以这没什么好做的了。

1.6ms 是涉及 4 个表的查询的绝佳时间。不要计划显着加快速度。您可能会处理数百个连接，每秒执行数千个类似查询。您还需要更多吗？

你在使用 InnoDB 吗？这更适合并发访问。

您的示例似乎没有任何全表扫描；请提供一个例子。

ALL 在 10 行表上无需担心。在百万行的桌子上，这是一件大事。你的桌子会显着增长吗？当担心ALL 时，您应该注意这一点：全表扫描有时比使用“完美”索引更快。当估计的行数超过表的大约 20% 时，优化器决定扫描。表扫描是高效的，因为它直接扫描整个表，即使跳过了 80% 的行。使用索引更复杂——扫描索引，但是对于在索引中找到的每一行，都需要查找数据以找到该行。如果您认为不应该看到ALL，那么可能该索引不是很有选择性。别担心。

不要使用FORCE INDEX——尽管它可能有助于查询今天的值，但可能会损害明天的查询。