【问题标题】:MySql EXPLAIN efficienciesMySql 解释效率
【发布时间】:2016-02-29 23:13:46
【问题描述】:

我正在尝试使用EXPLAIN 仔细查看我的查询并查看它们的运行情况,到目前为止,在EXPLAIN 中创建的最大id 是7,但它是冗长的查询,有很多事情要做。我刚刚使用类似于下面的结构进行了另一个查询,EXPLAIN 给了我一个最大为 13 的id。根据我对EXPLAIN 的了解,这通常意味着查询效率较低/运行时间越长,id 越高@ 987654327@ 给出,但这是相对规则还是存在某种界限?例如,最大 id 为 2 的查询被视为非常有效,而最大 id 为 13 的查询被视为非常低效,还是只有 2 比 13 更有效?当然还有与效率无关的ID号的第三个选项。

ID 13 查询:

select if(cond1, subquery, if(cond2, subquery(subsubquery),
subquery(subsubquery))) as colA, if(cond1, subquery(subsubquery), if(cond2,
subquery(subsubquery), subquery(subsubquery))) as colB from TableA join
TableB on X group by y order by z desc

【问题讨论】:

  • 我怀疑这太宽泛而无法简洁地回答 - 但这个问题看起来很可怕!!!!
  • 我更多的是寻找一个普遍的答案,Uueerdo 已经足够做,只是为了引导我的思考。哦,我非常清楚这看起来有多糟糕,我肯定会重新审视它,希望至少减少子查询的数量,如果不是 if 语句也是如此
  • 那些类型的查询可能是架构设计不佳的症状,如果顶层没有聚合函数,那么(抛开性能优势不谈),应该没有按子句分组。
  • 这是为了工作,我对数据库结构没有太多控制权,如果我这样做,查询可能会被压缩成一个带有一些 sum 和 count 函数的查询。

标签: mysql explain


【解决方案1】:

我从未真正听说过与效率相关的 id 编号。除非我弄错了,否则它只是最终参与处理查询的表(和派生表)的数量。

加入一个巨大的表可能会减少/降低 id;加入重复的临时表(因为您不能在一个查询中使用它们两次),但该巨大表的一小部分相关部分(以及更好/更合适的索引)多次肯定会增加 id 计数,但可能会运行更快更高效...甚至考虑到生成这些临时表所需的前面查询的成本。

【讨论】:

  • 感谢您的回答。我以为我听说过 max id 与效率相关,但很高兴听到一些澄清
  • 通过简单的查询,这可能是一个不错的一般/模糊指南;但是当试图获得更复杂的结果时,有很多优化技巧可以增加 id 以使其成为可靠的指标。
  • 所以听起来像是一个相对的指南来考虑并可能引起对运行时间的关注,但不能作为关注运行时间和效率的唯一理由
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-11-10
  • 2014-03-22
  • 1970-01-01
  • 2010-11-12
  • 1970-01-01
相关资源
最近更新 更多