查询运行时间过长

Question

我正在运行下面的查询以基于同一个表内的日期字段检索唯一的最新结果。但是当这个表增长时，这个查询需要很多时间。任何改善这一点的建议都是值得欢迎的。

select 
    t2.* 
from 
    (
     select 
      (
       select 
        id 
       from 
        ctc_pre_assets ti 
       where 
        ti.ctcassettag = t1.ctcassettag 
       order by 
        ti.createddate desc limit 1 
      ) lid 
     from 
      (
       select 
        distinct ctcassettag 
       from 
        ctc_pre_assets 
      ) t1 
    ) ro, 
    ctc_pre_assets t2 
where 
    t2.id = ro.lid 
order by 
    id 

我们能够多次包含相同的行，但每行都有不同的时间戳。我的对象基于单个列，例如assettag我想用最新的时间戳检索每个assettag的单行。

Answer 1

找到每个ctcassettag的最新日期然后重新找回匹配的整个行更简单并且可能更快。

这并假设没有ctcassettag具有相同createddate多行，在这种情况下，你可以拿回超过每ctcassettag一行。

SELECT 
    ctc_pre_assets.* 
FROM 
    ctc_pre_assets 
INNER JOIN 
(
    SELECT 
     ctcassettag, 
     MAX(createddate) AS createddate 
    FROM 
     ctc_pre_assets 
    GROUP BY 
     ctcassettag 
) 
    newest 
     ON newest.ctcassettag = ctc_pre_assets.ctcassettag 
     AND newest.createddate = ctc_pre_assets.createddate 
ORDER BY 
    ctc_pre_assets.id 

编辑：处理与同一日期的多个行。

你还没有真正说过如何在同一createddate上多行同一ctcassettag的情况下选择你想要的行。所以，这个解决方案只是从duplicates中选择最低的id这一行。

SELECT 
    ctc_pre_assets.* 
FROM 
    ctc_pre_assets 
WHERE 
    ctc_pre_assets.id 
    = 
    (
     SELECT 
      lookup.id 
     FROM 
      ctc_pre_assets lookup 
     WHERE 
      lookup.ctcassettag = ctc_pre_assets.ctcassettag 
     ORDER BY 
      lookup.createddate DESC, 
      lookup.id   ASC 
     LIMIT 
      1 
    ) 

但这仍然使用相关子查询，这比简单的嵌套子查询慢（如我的第一个答案），但它处理的“副本”。

您可以通过更改相关子查询中的ORDER BY来更改要选择的行的规则。

它也非常类似于您自己的查询，但少一个连接。

Answer 2

嵌套查询总是比传统查询花费更长的时间，因为。你可以追加'解释'在查询的开始，并把你的结果在这里？这将有助于我们分析确切的查询/表格，这些查询/表格的响应时间更长。

检查表是否有索引。不可缩进的表是不可取的（除非显然需要不缩进），并且执行查询的速度惊人地慢。

相反，我认为最好的情况是避免完全编写嵌套查询。 Bette，分别运行每个查询，然后在第二个查询中使用结果（数组或列表格式）。

Answer 3

一是一些问题，你至少应该问问自己，但也许也给我们一个答复，以改善我们的反应的准确性：

1. 是您的数据标准化？如果是的话，也许你应该例外以避免这个残酷的子查询问题
2. 你使用的是索引吗？如果是的话，哪一个，你是否充分利用它们？

一些建议，以提高可读性，也许性能查询： - 由 使用群体 - - 使用加入 使用聚合

例（未经测试，因此可能无法正常工作，但应该给的印象）：

SELECT t2.* 
FROM (
    SELECT id 
    FROM ctc_pre_assets 
    GROUP BY ctcassettag 
    HAVING createddate = max(createddate) 
    ORDER BY ctcassettag DESC 
) ro 
INNER JOIN ctc_pre_assets t2 ON t2.id = ro.lid 
ORDER BY id 

使用正常化是伟大的，但也有地方正常化导致弊大于利的几个注意事项。这看起来像这样的情况，但如果没有我的表格，我无法确定。

使用截然不同的方式，我不禁得到你可能得不到所有相关结果的感觉 - 也许别人可以证实或否认这一点？

这并不是说子查询都不好，但如果写入不正确，它们往往会产生大规模的可伸缩性问题。确保你使用正确的方式（谷歌吗？）

索引可以为您节省一堆时间 - 如果你真的使用它们。设置它们还不够，您必须创建实际使用索引的查询。 Google也是如此。