如何判断SQL查询的复杂度答案

【问题标题】：How to judge the complexity of SQL queries如何判断SQL查询的复杂度
【发布时间】：2021-03-31 03:15:02
【问题描述】：

任何解释如何判断 SQL 查询复杂性的资源将不胜感激。

【问题讨论】：

大多数（如果不是全部）DBMS 允许您获取有关查询的计划信息。虽然看起来简单的 sql可能导致复杂的计划，反之亦然，但它可能是一个很好的起点。
如果您的意思是我如何评估一个查询需要完成的复杂程度作为任务我认为这个问题与本网站无关，请阅读stackoverflow.com/help/on-topic 了解您可以询问的内容并阅读@ 987654322@。作为计算复杂性理论的入门者
我投票结束这个问题，因为问题似乎是关于计算复杂性理论的

【解决方案1】：

（通过“复杂性”，我假设您的意思是“缓慢”？）一些提示：

子查询可能会也可能不会大大降低查询速度。
GROUP BY 和 ORDER BY -- 当两者都存在但不同时：通常需要两种类型。
通常每个SELECT 只使用一个索引。
OR 几乎总是效率低下。切换到UNION 可以有效地使用多个索引。
UNION ALL，有一些限制，比UNION DISTINCT 更有效（因为重复数据删除）
Non-sargeable 表达式不能使用索引，因此效率非常低。
如果整个WHERE、GROUP BY 和ORDER BY 由单个索引处理，则可以有效地处理LIMIT。（否则它必须收集所有的东西，分类，然后才能剥掉几行。）
实体-属性-值模式效率低下。
UUID 和 GUID 在非常大的表上效率低下。
复合索引通常优于单列索引。
“覆盖”索引要好一些。
有时，尤其是在涉及LIMIT 时，最好将查询从内到外翻转。即从一个子查询开始，找到您需要的少数ids，然后返回到同一个表和其他表以获取所需的其余列。
“窗口化函数”在 MySQL 8 和 MariaDB 10.2 中实现不佳。它们对于“groupwise-max”和“分层模式”很有用。在优化器改进之前，我声明它们是“复杂的”。
最近的版本已识别“行构造函数”；以前它们的性能受到影响。
拥有AUTO_INCREMENT id 在某些情况下会损害性能；帮助他人。

EXPLAIN（或EXPLAIN FORMAT=JSON）告诉你发生了什么现在；它没有告诉你如何重写查询或添加什么更好的索引。

更多索引提示：http://mysql.rjweb.org/doc.php/index_cookbook_mysql 在该链接中，请参阅“处理程序计数”以了解衡量特定查询复杂性的好方法。我用它来比较查询公式等，即使没有填充大表来获得可用的时间。

给我一堆查询；我会指出其中的复杂性（如果有的话）。

【讨论】：

【解决方案2】：

您可以使用 EXPLAIN 命令获取有关您的查询的更多信息。

【讨论】：