使用GROUP BY的MySQL查询非常慢

问题描述 投票:0回答:2

我有一个使用以下架构的数据库:

CREATE TABLE IF NOT EXISTS `sessions` (
  `starttime` datetime NOT NULL,
  `ip` varchar(15) NOT NULL default '',
  `country_name` varchar(45) default '',
  `country_iso_code` varchar(2) default '',
  `org` varchar(128) default '',
  KEY (`ip`),
  KEY (`starttime`),
  KEY (`country_name`)
);

(实际的表包含更多列;我只包含了我查询的列。)引擎是InnoDB。

如你所见,有3个指数 - 关于ipstarttimecountry_name

该表非常大 - 它包含150万行。我正在运行各种查询,试图提取一个月的信息(对于2018年8月,在下面的示例中)。

像这样的查询

SELECT
  UNIX_TIMESTAMP(starttime) as time_sec,
  country_iso_code AS metric,
  COUNT(country_iso_code) AS value
FROM
  sessions
WHERE
  starttime >= FROM_UNIXTIME(1533070800) AND
  starttime <= FROM_UNIXTIME(1535749199)
GROUP BY metric;

虽然在country_iso_code上没有索引,但是相当缓慢但可忍受(几十秒)。

(忽略SELECT中的第一件事;我知道它似乎没有意义,但是在使用查询结果的工具中需要它。同样,忽略使用FROM_UNIXTIME()而不是日期字符串;这查询的一部分是自动生成的,我无法控制它。)

但是,像这样的查询

SELECT
  country_name AS Country,
  COUNT(country_name) AS Attacks
FROM
  sessions
WHERE
  starttime >= FROM_UNIXTIME(1533070800) AND
  starttime <= FROM_UNIXTIME(1535749199)
GROUP BY Country;

是无法忍受的缓慢 - 我让它运行了大约半个小时然后放弃了而没有得到任何结果。

EXPLAIN的结果:

+----+-------------+----------+------------+-------+------------------------------------+--------------+---------+------+----------+----------+-------------+
| id | select_type | table    | partitions | type  | possible_keys                      | key          | key_len | ref  | rows     | filtered | Extra       |
+----+-------------+----------+------------+-------+------------------------------------+--------------+---------+------+----------+----------+-------------+
|  1 | SIMPLE      | sessions | NULL       | index | starttime,starttime_2,country_name | country_name | 138     | NULL | 14771687 |    35.81 | Using where |
+----+-------------+----------+------------+-------+------------------------------------+--------------+---------+------+----------+----------+-------------+

究竟是什么问题?我应该为其他东西编制索引吗?也许是(starttimecountry_name)的综合指数?我读过this guide,但也许我误解了它?

以下是一些同样缓慢且可能遇到同样问题的其他查询:

查询#2:

SELECT
  ip AS IP,
  COUNT(ip) AS Attacks
FROM
  sessions
WHERE
  starttime >= FROM_UNIXTIME(1533070800) AND
  starttime <= FROM_UNIXTIME(1535749199)
GROUP BY ip;

EXPLAIN的结果:

+----+-------------+----------+------------+-------+--------------------------+------+---------+------+----------+----------+-------------+
| id | select_type | table    | partitions | type  | possible_keys            | key  | key_len | ref  | rows     | filtered | Extra       |
+----+-------------+----------+------------+-------+--------------------------+------+---------+------+----------+----------+-------------+
|  1 | SIMPLE      | sessions | NULL       | index | starttime,ip,starttime_2 | ip   | 47      | NULL | 14771780 |    35.81 | Using where |
+----+-------------+----------+------------+-------+--------------------------+------+---------+------+----------+----------+-------------+

查询#3:

SELECT
  org AS Organization,
  COUNT(org) AS Attacks
FROM
  sessions
WHERE
  starttime >= FROM_UNIXTIME(1533070800) AND
  starttime <= FROM_UNIXTIME(1535749199)
GROUP BY Organization;

EXPLAIN的结果:

+----+-------------+----------+------------+-------+---------------------------+------+---------+------+----------+----------+-------------+
| id | select_type | table    | partitions | type  | possible_keys             | key  | key_len | ref  | rows     | filtered | Extra       |
+----+-------------+----------+------------+-------+---------------------------+------+---------+------+----------+----------+-------------+
|  1 | SIMPLE      | sessions | NULL       | index | starttime,starttime_2,org | org  | 387     | NULL | 14771800 |    35.81 | Using where |
+----+-------------+----------+------------+-------+---------------------------+------+---------+------+----------+----------+-------------+

查询#4:

SELECT
  ip AS IP,
  country_name AS Country,
  city_name AS City,
  org AS Organization,
  COUNT(ip) AS Attacks
FROM
  sessions
WHERE
  starttime >= FROM_UNIXTIME(1533070800) AND
  starttime <= FROM_UNIXTIME(1535749199)
GROUP BY ip;

EXPLAIN的结果:

+----+-------------+----------+------------+-------+--------------------------+------+---------+------+----------+----------+-------------+
| id | select_type | table    | partitions | type  | possible_keys            | key  | key_len | ref  | rows     | filtered | Extra       |
+----+-------------+----------+------------+-------+--------------------------+------+---------+------+----------+----------+-------------+
|  1 | SIMPLE      | sessions | NULL       | index | starttime,ip,starttime_2 | ip   | 47      | NULL | 14771914 |    35.81 | Using where |
+----+-------------+----------+------------+-------+--------------------------+------+---------+------+----------+----------+-------------+
mysql aggregate-functions query-performance
2个回答
0
投票

一般来说,表单的查询

  SELECT column, COUNT(column)
    FROM tbl
   WHERE datestamp >= a AND datestamp <= b
   GROUP BY column

当表格在(datestamp, column)上有复合索引时表现最佳。为什么?它们可以通过索引扫描来满足,而不是需要读取表的所有行。

换句话说,可以通过随机访问索引(到日期戳的第一个值)来定位查询的第一个相关行。然后,MySQL可以按顺序读取索引并计算column中的各种值,直到它到达最后一个相关行。没有必要阅读实际的表格;仅从索引中满足查询。这使它更快。

UPDATE TABLE tbl ADD INDEX date_col (datestamp, column);

为您创建索引。

当心两件事。一:单列索引不一定有助于聚合查询性能。

二:很难猜测用于获取索引扫描的正确索引而不会看到整个查询。简化的查询通常会导致索引过于简单。


0
投票

更好......

请注意,您没有PRIMARY KEY;那很顽皮。拥有PK本身并不能提高性能,但PK开始使用starttime会。我们开工吧:

CREATE TABLE IF NOT EXISTS `sessions` (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT,   -- note
  `starttime` datetime NOT NULL,
  `ip` varchar(39) NOT NULL CHARACTER SET ascii default '',  -- note
  `country_name` varchar(45) default '',
  `country_iso_code` char(2) CHARACTER SET ascii  default '',  -- note
  `org` varchar(128) default '',
  PRIMARY KEY(starttime, id)  -- in this order
  INDEX(id)                   -- to keep AUTO_INCREMENT happy
  -- The rest are unnecessary for the queries in question:
  KEY (`ip`),
  KEY (`starttime`),
  KEY (`country_name`)
) ENGINE=InnoDB;        -- just in case you are accidentally getting MyISAM

为什么?这将利用PK与数据的“聚类”。这样,只扫描时间范围内的表格的一部分。并且索引和数据之间不会反弹。并且您不需要很多索引来有效地完成所有情况。

IPv6最多需要39个字节。请注意,VARCHAR不允许您进行任何范围(CDR)测试。我可以进一步讨论你喜欢的问题。

© www.soinside.com 2019 - 2024. All rights reserved.