Mysql 向查询优化者建议计划

有时我可以使用forceindex选项在查询上使用特定索引，以加快查询速度

然后，经过一段时间后，该表中的数据可能会发生变化。我使用的force索引可能不是该查询的正确索引搜索

我的问题是

• 是否建议查询优化人员在计划生成期间使用强制索引作为可能的选项。如果使用强制索引的计划很慢，那么可以使用普通的查询计划

• 或者，无论如何都可以编辑MySql/PSQL的代码，以建议优化人员在计划生成期间使用强制索引作为可能的选项

---

其他信息：我想将我的计划添加到Optimizer计划列表中（该Optimizer已经为查询创建了许多计划）。因此，在选择一个查询的最佳方案时，我希望优化器也能考虑我的计划。如果这种方式是可能的，那么优化器不需要每次考虑力指数。它可以将力索引作为生成计划的一个可能选项

---

据我所知，我试图把问题弄清楚。如果有人无法理解，请评论您的查询。

唯一的方法是从查询中删除

强制索引

您可以覆盖优化器的计划，或者让优化器选择计划

优化器无法判断使用索引是否会很慢。它试图在选择一个快速的计划时做出最好的猜测

优化器能够更加准确的唯一方法是运行两个查询，比较性能差异，然后运行快速查询。这显然是不实际的，因此优化器是基于某种统计模型来估计查询的成本的。大多数情况下，这足够准确，优化器的选择是最好的。
强制索引今天可能是好的，但明天可能是坏的。这是因为数据分布更改和/或查询中的常量更改

有几种模式通常会导致选择“错误”索引：

目前还不清楚是针对
WHERE
还是针对
ORDER BY
进行优化

SELECT ...
    FROM a
    JOIN b ON ...
    WHERE a.x ...
      AND b.y ...

是否先过滤
a.x
或
b.y
并不明显。（它不能同时在两个过滤器上进行过滤。）

如果您提供特定的查询，我们可能会提供特定的提示

有时，可以重新格式化查询以欺骗优化器选择一条路径而不是另一条路径。版本8.0有许多“提示”，但这并不一定比强制索引好<代码>直接连接
是提示的另一种风格

重新格式化查询可能需要将查询的一部分转换为子查询。但同样，你冒着“今天好，明天坏”的风险

如果“过度规范化”（例如规范化日期时间，然后在

之间使用

），则解决方案可能涉及反规范化

您是否使用“复合”索引？
中的“范围”部分在索引中最后一个吗？（还有很多其他问题——让我们看看具体的问题。）
据我所知

Mysql不够好，无法支持您的需求，因为缺少某种统计数据和机制，例如直方图、动态采样等

因此，如果数据发生变化，尽管及时收集统计数据，但缺少前面描述的必要内容，优化器的行为可能不会像您预期的那样

你的两个问题可能是很好的练习，但对最终用户来说很难

或者您可以为oracle或maria db团队提供建议？
问：是否建议查询优化人员在其计划生成过程中使用强制索引作为可能的选项。如果使用强制索引的计划很慢，那么可以使用普通的查询计划

答：不，优化器会按照给定的方式进行操作。优化器不会忽略提示。SQL文本中包含的任何提示都会产生影响

这就是为什么暗示是“最后的手段”。我们的首选是让优化器选择适当的计划。实现这一点的最佳方法是仔细编写SQL，以避免使用阻止使用适当索引的构造（例如，在函数中包装列），使适当的索引可用，并确保统计信息准确且最新

问：是否有必要编辑MySql/PSQL的代码，以建议优化人员在计划生成期间使用强制索引作为可能的选项

 A:优化器将考虑所有的索引，并且如果候选访问计划具有最低的成本估计，则选择使用特定的索引。这不需要强制索引提示；MySQL将考虑索引

在SQL文本中使用提示是最后的选择。在考虑使用提示（力指标或其他）之前，我们应该


使用允许（但不阻止）使用适当索引的SQL构造。例如，对于日期时间列
dt
，MySQL可以对该
dt>='2018-04-22'和dt<'2018-04-23'
使用范围扫描操作，但不能对该
日期（dt）='2018-04-22'
使用范围扫描操作。有时，可以通过对SQL文本进行一些简单的调整来解决查询性能问题。有时需要更广泛的重新设计和重新编写

＞P>有合适的索引可用（例如，考虑具有适当的前导列的复合索引，并删除单列上的冗余索引）

确保统计信息是最新的，并且能够代表表（注意，InnoDB使用少量页面样本收集统计信息。如果采样的页面不能代表表，我们可以得到扭曲的统计信息

您处理的一般概念是“内部数据库统计信息”（不是官方术语）。即数据库引擎用于制定查询计划的信息。统计信息
SELECT ...
    FROM a
    JOIN b ON ...
    WHERE a.x ...
      AND b.y ...

ANALYZE TABLE <table_name>;