为什么我不能直接编写执行计划而不是SQL？

Question

我一直有这样的问题：

• 慢速SQL查询需要更快
• 感到困惑，为什么它很慢
• 查看执行计划
• 意识到为什么它很慢
• 确切地知道执行计划的哪些更改可能会导致更快的查询
• 尝试制定SQL查询以获得所需的执行计划
• 重复上一步~20次
• 学会使用慢查询

这不是询问如何根据所需计划制定查询，因为这取决于具体情况。问题是：为什么要这么麻烦？

当然，对于简单的查询，执行计划是我并不真正关心或想要考虑的事情。但对于复杂的查询，感觉就像我在brainf * ck编程。我不是故意吹嘘，但我相信我在制定执行计划方面比优化者更好。不仅如此，还有一个额外的步骤可以减慢一切。优化器不可能知道很多东西。总是感觉我正在与之抗争而不是与之合作。

我尽可能地在线查看，似乎没有办法直接编写执行计划，虽然我可能错过了一些东西。

为什么我们编写SQL查询而不是直接编写执行计划？

^{_{旁注：在SQLite中，尽管在程序查询的同一进程中运行，但总是让我感到困惑，SQLite仍然要求提供文本，字符数组查询和然后必须解析它。在动态查询生成的情况下，这意味着生成查询，然后立即由同一过程解析。}}

Answer 1

因为SQL是第五代编程语言（我所知道的唯一成功的编程语言） - 它的主要特征是它为您编写代码。它检查数据库的内容并确定最佳的处理方式。

也就是说，有一些方法可以通过RECOMPILE手动更改执行计划。但是，我建议你坚持使用HINTS，而不是试图做任何过于花哨的事情。一般来说，规划师比你可能做得更好。

解决始终如一的慢执行计划的一种常用方法是在查询结尾添加WITH RECOMPILE。它会导致执行计划在每次执行时重新编译 - 对内存性能不是很好，但是值得测试一下它是否可以改进高度活跃的（许多读/写）数据库。

Answer 2

SQL是一种声明性语言，其唯一目的是帮助您编写声明性代码。你必须简单地说出你想要达到的目标。然后，语言有责任找出实现它的最佳方法。由于语言仍然不是那么高级，用户通常必须“确切地知道执行计划的哪些更改可能会导致更快的查询”。理想的声明性语言将完美地破译用户的意图。

Answer 3

对于SQL Server，您可以使用优化程序提示USE PLAN，它允许您向SQL Server提供最佳执行计划。此外，还有其他任何优化器提示，如指定物理连接，优化某些参数，使用特定的表连接等。是的，您可以在当前时刻提供最佳执行计划 。但是，由于数据发生变化，您将来可能会遇到问题。您可以在表列上添加索引，删除它，可以更改列中的数据分布。你现在最好的计划可能是未来最糟糕的计划。 SQL引擎会在任何情况下计算良好计划，也许它不会最佳。

SQL查询就像抽象一样，不允许考虑最佳执行计划。这是我们的优势而不是缺点。