TIMESTAMPDIFF MIN MAX 优化答案

【问题标题】：TIMESTAMPDIFF MIN MAX optimizationTIMESTAMPDIFF MIN MAX 优化
【发布时间】：2017-02-01 23:14:48
【问题描述】：

我有 3 个 Innodb 表，其中 2 个是“大”的

composer_sessions 92 行
会话 2,530,587 行
跟踪 8,032,697 行

我正在运行以下查询：

SELECT TIMESTAMPDIFF(SECOND,
                     MIN(tracking.timestamp),
                     MAX(tracking.timestamp) ) AS `thetime`,
       SUM(tracking.type = 'scene') AS `scenecount` 
FROM `tracking`, `sessions` 
WHERE tracking.tour_ID = '102098'
  AND sessions.session_ID = tracking.session_ID 
  AND sessions.IP NOT IN(SELECT DISTINCT `IP`
                          FROM `composer_sessions`)
GROUP BY tracking.session_ID
HAVING TIMESTAMPDIFF(SECOND, MIN(tracking.timestamp), 
                             MAX(tracking.timestamp)) <= '3600'
   AND TIMESTAMPDIFF(SECOND, MIN(tracking.timestamp),
                             MAX(tracking.timestamp) ) > '60'
   AND SUM(tracking.type = 'scene') >= '2'

查询中使用的所有列都已编入索引。查询中的“join”用于清除与我们不希望出现在结果中的 IP 地址相关的数据。

我是否有更好的方法来构建此查询和/或任何人都可以建议复合（多列）索引以使此查询运行得更快？

【问题讨论】：

尝试在HAVING 子句中使用thetime，而不是重复计算。不过，我不确定它是否会有所作为。
尝试用LEFT JOIN/NULL 模式替换NOT IN 测试。
您可能想阅读这篇文章，尤其是关于查询性能问题的部分。 meta.stackoverflow.com/questions/271055/…
请为表格提供SHOW CREATE TABLE。 “查询中使用的所有列都已编入索引”太不精确了。

标签： mysql join query-performance

【解决方案1】：

尝试调整您的查询以使用现代连接语法，例如

SELECT ...
  FROM tracking
  JOIN sessions ON sessions.session_ID = tracking.session_ID
  LEFT JOIN composer_sessions ON sessions.IP = composer_sessions.IP
 WHERE composer_sessions.IP IS NULL
   AND tracking.tour_ID = '102098'
 GROUP BY tracking.session_ID
HAVING ...

这还使用LEFT JOIN ... IS NULL 模式根据第三个表的内容消除不需要的行。

然后，在您的 tracking 表上创建一个所谓的 compound covering index。它应按此顺序包含以下列。

    ( tour_id, session_id, timestamp, type )

这允许直接从索引中满足查询的tracking 部分。查询计划器可以根据您选择的tour_id 随机访问索引，因为该值在索引中的最左侧。然后它可以按顺序扫描索引以提取您需要的其余内容。

同样，在您的sessions 表上尝试复合索引

   ( session_ID, IP )

看看有没有帮助。您也可以尝试将这些列按相反的顺序排列。

请注意，单个列上的大量索引很少有助于复杂查询的性能。为此，您需要精心挑选的复合索引。许多单列索引通常被认为对整体性能有害，因为它们会减慢插入和更新速度并且没有任何好处。

阅读：http://use-the-index-luke.com/

【讨论】：