9

我们在 MySql 中有一个大约 3000 万条记录的表，以下是表结构

CREATE TABLE `campaign_logs` (
  `domain` varchar(50) DEFAULT NULL,
  `campaign_id` varchar(50) DEFAULT NULL,
  `subscriber_id` varchar(50) DEFAULT NULL,
  `message` varchar(21000) DEFAULT NULL,
  `log_time` datetime DEFAULT NULL,
  `log_type` varchar(50) DEFAULT NULL,
  `level` varchar(50) DEFAULT NULL,
  `campaign_name` varchar(500) DEFAULT NULL,
  KEY `subscriber_id_index` (`subscriber_id`),
  KEY `log_type_index` (`log_type`),
  KEY `log_time_index` (`log_time`),
  KEY `campid_domain_logtype_logtime_subid_index` (`campaign_id`,`domain`,`log_type`,`log_time`,`subscriber_id`),
  KEY `domain_logtype_logtime_index` (`domain`,`log_type`,`log_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |

以下是我的查询

我正在做 UNION ALL 而不是使用 IN 操作

SELECT log_type,
       DATE_FORMAT(CONVERT_TZ(log_time,'+00:00','+05:30'),'%l %p') AS log_date,
       count(DISTINCT subscriber_id) AS COUNT,
       COUNT(subscriber_id) AS total
FROM stats.campaign_logs USE INDEX(campid_domain_logtype_logtime_subid_index)
WHERE DOMAIN='xxx'
  AND campaign_id='123'
  AND log_type = 'EMAIL_OPENED'
  AND log_time BETWEEN CONVERT_TZ('2015-02-01 00:00:00','+00:00','+05:30') AND CONVERT_TZ('2015-03-01 23:59:58','+00:00','+05:30')
GROUP BY log_date

UNION ALL

SELECT log_type,
       DATE_FORMAT(CONVERT_TZ(log_time,'+00:00','+05:30'),'%l %p') AS log_date,
       COUNT(DISTINCT subscriber_id) AS COUNT,
            COUNT(subscriber_id) AS total
FROM stats.campaign_logs USE INDEX(campid_domain_logtype_logtime_subid_index)
WHERE DOMAIN='xxx'
  AND campaign_id='123'
  AND log_type = 'EMAIL_SENT'
  AND log_time BETWEEN CONVERT_TZ('2015-02-01 00:00:00','+00:00','+05:30') AND CONVERT_TZ('2015-03-01 23:59:58','+00:00','+05:30')
GROUP BY log_date

UNION ALL

SELECT log_type,
       DATE_FORMAT(CONVERT_TZ(log_time,'+00:00','+05:30'),'%l %p') AS log_date,
       COUNT(DISTINCT subscriber_id) AS COUNT,
            COUNT(subscriber_id) AS total
FROM stats.campaign_logs USE INDEX(campid_domain_logtype_logtime_subid_index)
WHERE DOMAIN='xxx'
  AND campaign_id='123'
  AND log_type = 'EMAIL_CLICKED'
  AND log_time BETWEEN CONVERT_TZ('2015-02-01 00:00:00','+00:00','+05:30') AND CONVERT_TZ('2015-03-01 23:59:58','+00:00','+05:30')
GROUP BY log_date,

以下是我的解释声明

+----+--------------+---------------+-------+-------------------------------------------+-------------------------------------------+---------+------+--------+------------------------------------------+
| id | select_type  | table         | type  | possible_keys                             | key                                       | key_len | ref  | rows   | Extra                                    |
+----+--------------+---------------+-------+-------------------------------------------+-------------------------------------------+---------+------+--------+------------------------------------------+
|  1 | PRIMARY      | campaign_logs | range | campid_domain_logtype_logtime_subid_index | campid_domain_logtype_logtime_subid_index | 468     | NULL |  55074 | Using where; Using index; Using filesort |
|  2 | UNION        | campaign_logs | range | campid_domain_logtype_logtime_subid_index | campid_domain_logtype_logtime_subid_index | 468     | NULL | 330578 | Using where; Using index; Using filesort |
|  3 | UNION        | campaign_logs | range | campid_domain_logtype_logtime_subid_index | campid_domain_logtype_logtime_subid_index | 468     | NULL |   1589 | Using where; Using index; Using filesort |
| NULL | UNION RESULT | <union1,2,3>  | ALL   | NULL                                      | NULL                                      | NULL    | NULL |   NULL |                                          |
+----+--------------+---------------+-------+-------------------------------------------+-------------------------------------------+---------+------+--------+------------------------------------------+
  1. 我将 COUNT(subscriber_id) 更改为 COUNT(*) 并没有观察到性能提升。

2.我从查询中删除了 COUNT(DISTINCTsubscriber_id)，然后我获得了巨大的性能提升，我在大约 1.5 秒内得到结果，之前需要 50 秒 - 1 分钟。但我需要从查询中区分订阅者 ID

以下是我从查询中删除 COUNT(DISTINCTsubscriber_id) 时的说明

+----+--------------+---------------+-------+-------------------------------------------+-------------------------------------------+---------+------+--------+-----------------------------------------------------------+
| id | select_type  | table         | type  | possible_keys                             | key                                       | key_len | ref  | rows   | Extra                                                     |
+----+--------------+---------------+-------+-------------------------------------------+-------------------------------------------+---------+------+--------+-----------------------------------------------------------+
|  1 | PRIMARY      | campaign_logs | range | campid_domain_logtype_logtime_subid_index | campid_domain_logtype_logtime_subid_index | 468     | NULL |  55074 | Using where; Using index; Using temporary; Using filesort |
|  2 | UNION        | campaign_logs | range | campid_domain_logtype_logtime_subid_index | campid_domain_logtype_logtime_subid_index | 468     | NULL | 330578 | Using where; Using index; Using temporary; Using filesort |
|  3 | UNION        | campaign_logs | range | campid_domain_logtype_logtime_subid_index | campid_domain_logtype_logtime_subid_index | 468     | NULL |   1589 | Using where; Using index; Using temporary; Using filesort |
| NULL | UNION RESULT | <union1,2,3>  | ALL   | NULL                                      | NULL                                      | NULL    | NULL |   NULL |                                                           |
+----+--------------+---------------+-------+-------------------------------------------+-------------------------------------------+---------+------+--------+-----------------------------------------------------------+
  1. 我通过删除 UNION ALL 分别运行了三个查询。一个查询花费了 32 秒，其他查询花费了 1.5 秒，但是第一个查询处理大约 350K 记录，而其他查询只处理 2k 行

我可以通过省略来解决我的性能问题，COUNT(DISTINCT...)但我需要这些值。有没有办法重构我的查询，或添加索引或其他东西来获取COUNT(DISTINCT...)值，但要快得多？

更新 以下信息是关于上表的数据分布

对于 1 个域 1 个活动 20 log_types 1k-200k 订阅者

我正在运行的上述查询，域有 180k+ 订阅者。

4

6 回答 6

5

如果没有 的查询count(distinct)要快得多，也许您可​​以进行嵌套聚合：

SELECT log_type, log_date,
       count(*) AS COUNT, sum(cnt) AS total
FROM (SELECT log_type,
             DATE_FORMAT(CONVERT_TZ(log_time,'+00:00','+05:30'),'%l %p') AS log_date,
             subscriber_id, count(*) as cnt
      FROM stats.campaign_logs USE INDEX(campid_domain_logtype_logtime_subid_index)
      WHERE DOMAIN = 'xxx' AND
            campaign_id = '123' AND
            log_type IN ('EMAIL_SENT', 'EMAIL_OPENED', 'EMAIL_CLICKED') AND
            log_time BETWEEN CONVERT_TZ('2015-02-01 00:00:00','+00:00','+05:30') AND 
                             CONVERT_TZ('2015-03-01 23:59:58','+00:00','+05:30')
      GROUP BY log_type, log_date, subscriber_id
     ) l
GROUP BY logtype, log_date;

运气好的话，这将需要 2-3 秒而不是 50 秒。但是，您可能需要将其分解为子查询，以获得完整的性能。因此，如果这没有显着的性能提升，请改in回=其中一种类型。如果可行，那么union all可能是必要的。

编辑：

另一种尝试是使用变量来枚举之前的值group by：

SELECT log_type, log_date, count(*) as cnt,
       SUM(rn = 1) as sub_cnt
FROM (SELECT log_type,
             DATE_FORMAT(CONVERT_TZ(log_time,'+00:00','+05:30'),'%l %p') AS log_date,
             subscriber_id,
             (@rn := if(@clt = concat_ws(':', campaign_id, log_type, log_time), @rn + 1,
                        if(@clt := concat_ws(':', campaign_id, log_type, log_time), 1, 1)
                       )
              ) as rn
      FROM stats.campaign_logs USE INDEX(campid_domain_logtype_logtime_subid_index) CROSS JOIN
           (SELECT @rn := 0)
      WHERE DOMAIN = 'xxx' AND
            campaign_id = '123' AND
            log_type IN ('EMAIL_SENT', 'EMAIL_OPENED', 'EMAIL_CLICKED') AND
            log_time BETWEEN CONVERT_TZ('2015-02-01 00:00:00', '+00:00', '+05:30') AND 
                             CONVERT_TZ('2015-03-01 23:59:58', '+00:00', '+05:30')
      ORDER BY log_type, log_date, subscriber_id
     ) t
GROUP BY log_type, log_date;

这仍然需要另一种数据，但它可能会有所帮助。

于 2015-03-21T01:40:08.303 回答
3

要回答您的问题：

有没有办法重构我的查询，或添加索引或其他东西，以获取 COUNT(DISTINCT...) 值，但要快得多？

是的，不要按计算字段分组（不要按函数结果分组）。相反，预先计算它，将其保存到持久列并将此持久列包含到索引中。

我会尝试执行以下操作，看看它是否会显着改变性能。

1）简化查询，专注于某一部分。只留下三个中最长SELECT的一个，摆脱UNION调整期。一旦优化了最长SELECT的，添加更多并检查完整查询的工作方式。

2）按函数结果分组并不能让引擎有效地使用索引。使用此函数的结果向表中添加另一列（起初是暂时的，只是为了检查想法）。据我所知，您希望按 1 小时分组，因此添加列log_time_hour datetime并将其设置为log_time舍入/截断到最接近的小时（保留日期部分）。

使用新列添加索引：(domain, campaign_id, log_type, log_time_hour, subscriber_id)。索引中前三列的顺序无关紧要（因为您使用相等比较查询中的某个常量，而不是范围），但要使它们与查询中的顺序相同。或者，更好的是，在索引定义和查询中按选择性顺序制作它们。如果您有100,000活动、1000域和3日志类型，请按以下顺序排列：campaign_id, domain, log_type. 这应该没什么关系，但值得检查。log_time_hour必须在索引定义中排在第四位，subscriber_id最后。

在查询中使用新列 inWHERE和 in GROUP BY。确保在GROUP BY:log_type和中包含所有需要的列log_time_hour。

你需要两个COUNT和COUNT(DISTINCT)吗？只留下COUNT第一个并衡量性能。只留下COUNT(DISTINCT)并衡量绩效。保留两者并衡量性能。看看他们如何比较。

SELECT log_type,
       log_time_hour,
       count(DISTINCT subscriber_id) AS distinct_total,
       COUNT(subscriber_id) AS total
FROM stats.campaign_logs
WHERE DOMAIN='xxx'
  AND campaign_id='123'
  AND log_type = 'EMAIL_OPENED'
  AND log_time_hour >= '2015-02-01 00:00:00' 
  AND log_time_hour <  '2015-03-02 00:00:00'
GROUP BY log_type, log_time_hour
于 2015-03-19T05:39:10.460 回答
1

  1. subscriber_id在您的密钥中没有用，因为您在计算不同的订阅者之前按密钥之外的计算字段（log_date）进行分组。它解释了为什么这么慢，因为 MySQL 必须在不使用 key 的情况下对重复的订阅者进行排序和过滤。

  2. 您的 log_time 条件可能存在错误：您的选择（即'+05:30','+00:00'）应该有相反的时区转换，但它不会对您的查询时间产生任何重大影响。

  3. log_type IN (...)您可以通过执行 a和 group by来避免“联合所有”log_type, log_date

最有效的解决方案是在您的数据库模式中添加一个 mid-hour 字段，并将一天中的 48 个中点之一设置在那里（并注意中点时区）。所以你可以在campaign_id, domain, log_type, log_mid_hour,上使用索引subscriber_id

这将是非常多余的，但会提高速度。

所以这应该会导致你的表中的一些初始化： 小心：不要在你的生产表上测试这个

ALTER TABLE campaign_logs
   ADD COLUMN log_mid_hour TINYINT AFTER log_time;

UPDATE campaign_logs SET log_mid_hour=2*HOUR(log_time)+IF(MINUTE(log_time)>29,1,0);

ALTER TABLE campaign_logs
ADD INDEX(`campaign_id`,`domain`,`log_time`,`log_type`,`log_mid_hour`,`subscriber_id`);

您还必须在脚本中设置 log_mid_hour 以供将来记录。

您的查询将变为（对于 11 小时中点时移）：

SELECT log_type,
   MOD(log_mid_hour+11, 48) tz_log_mid_hour,
   COUNT(DISTINCT subscriber_id) AS COUNT,
   COUNT(subscriber_id) AS total
FROM stats.campaign_logs
WHERE DOMAIN='xxx'
   AND campaign_id='123'
   AND log_type IN('EMAIL_SENT', 'EMAIL_OPENED','EMAIL_CLICKED')
   AND log_time BETWEEN CONVERT_TZ('2015-02-01 00:00:00','+05:30','+00:00')   
   AND CONVERT_TZ('2015-03-01 23:59:58','+05:30','+00:00')
GROUP BY log_type, log_mid_hour;

这将为您提供每个中点的计数，以充分利用您的索引。

于 2015-03-20T21:00:17.670 回答
1 
SELECT log_type,
       DATE_FORMAT(CONVERT_TZ(log_time,'+00:00','+05:30'),'%l %p') AS log_date,
       count(DISTINCT subscriber_id) AS COUNT,
       COUNT(subscriber_id) AS total
FROM stats.campaign_logs USE INDEX(campid_domain_logtype_logtime_subid_index)
WHERE DOMAIN='xxx'
  AND campaign_id='123'
  AND log_time BETWEEN CONVERT_TZ('2015-02-01 00:00:00','+00:00','+05:30') AND CONVERT_TZ('2015-03-01 23:59:58','+00:00','+05:30')
GROUP BY log_type, log_date

AND log_type IN ('EMAIL_OPENED', 'EMAIL_SENT', 'EMAIL_CLICKED')需要时添加。

于 2015-03-16T12:28:20.267 回答
1

我会尝试您正在使用的索引的其他排序，移动subscriber_id，看看效果如何。通过将具有更高基数的列向上移动可以获得更好的结果。

起初，我认为它可能只使用了索引的一部分（根本没有访问subscriber_id）。如果它不能使用subscriber_id，那么将它向上移动到索引树会导致它运行得更慢，这至少会告诉你它不能使用它。

我想不出还有什么可以玩的。

于 2015-03-19T05:02:31.720 回答
0

我有一个非常相似的问题，在 SO 上发布，并得到了一些很大的帮助。这是线程：MySQL MyISAM 慢计数（）查询尽管覆盖了索引

简而言之，我发现我的问题与查询或索引无关，而与我设置表和 MySQL 的方式有关。当我执行以下操作时，我完全相同的查询变得更快：

  1. 切换到 InnoDB（您已经在使用）
  2. 将 CHARSET 切换为 ASCII。如果您不需要 utf8，则需要 3 倍的空间（以及搜索时间）。
  3. 使每个列的大小尽可能小，如果可能，不要为空。
  4. 增加了 MySQL 的 InnoDB 缓冲池大小。如果这是一台专用机器，许多建议是将其增加到 RAM 的 70%。
  5. 我按覆盖索引对表进行排序，通过 SELECT INTO OUTFILE 将其写出，然后将其重新插入到新表中。这会对搜索顺序中的所有记录进行物理排序。

我不知道这些更改中的哪一个解决了我的问题（因为我不科学并且没有一次尝试它们），但它使我的查询速度提高了 50-100 倍。YMMV。

于 2015-03-26T02:31:22.697 回答