如何判断SQL查询的复杂度

如何解决如何判断SQL查询的复杂度

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

解决方法

查看有关查询执行计划的官方 MySQL 文档： https://dev.mysql.com/doc/refman/5.7/en/execution-plan-information.html

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

,

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

• 子查询可能会也可能不会大大减慢查询速度。
• GROUP BY 和 ORDER BY -- 当两者都存在但不同时：通常需要两种排序。
• 通常每个 SELECT 只使用一个索引。
• OR 几乎总是低效的。切换到 UNION 可以有效地使用多个索引。
• UNION ALL 有一些限制，比 UNION DISTINCT 更有效（因为重复数据删除过程）
• 非 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 在该链接中，请参阅“处理程序计数”以了解衡量特定查询复杂性的好方法。我用它来比较查询公式等，即使没有填充大表来获取可用时间。

给我一​​堆查询；如果有的话，我会指出每个方面的复杂性。