2

我有一个具有以下结构的表，几乎有 120000 行，

desc user_group_report +------------------+----------+------+-----+-------------------+-------+ | Field | Type | Null | Key | Default | Extra | +------------------+----------+------+-----+-------------------+-------+ | user_id | int | YES | MUL | NULL | | | group_id | int(11) | YES | MUL | NULL | | | type_id | int(11) | YES | | NULL | | | group_desc | varchar(128)| NO| | NULL | | status | enum('open','close')|NO| | NULL | | | last_updated | datetime | NO | | CURRENT_TIMESTAMP | | +------------------+----------+------+-----+-------------------+-------+

我在以下键上有索引：

  • user_group_type(user_id,group_id,group_type)
  • group_type(group_id,type_id)
  • user_type(user_id,type_id)
  • 用户组（用户 ID，组 ID）

我的问题是我正在按 group_id 在上面的表组上运行 count(*) 聚合，并且在 type_id 上有一个子句

这是查询：

select count(*) user_count, group_id
from user_group_report
where type_id = 1
group by group_id;

这是解释计划（查询平均需要 0.3 秒）：

+----+-------------+------------------+-------+---------------------------------+---------+---------+------+--------+--------------------------+
| id | select_type | table            | type  | possible_keys                   | key     | key_len | ref  | rows   | Extra                    |
+----+-------------+------------------+-------+---------------------------------+---------+---------+------+--------+--------------------------+
|  1 | SIMPLE      | user_group_report | index | user_group_type,group_type,user_group | group_type | 10      | NULL | 119811 | Using where; Using index |
+----+-------------+------------------+-------+---------------------------------+---------+---------+------+--------+--------------------------+

在这里，据我了解，由于索引复杂，查询几乎会进行全表扫描，并且当我尝试在 group_id 上添加索引时，解释计划中的行显示的数量较少（几乎是行的一半），但查询执行所需的时间增加到 0.4-0.5 秒。

我尝试了不同的方法来添加/删除索引，但它们都没有减少所花费的时间。

假设表结构不能更改并且查询独立于其他表，有人可以建议我一种更好的方法来优化上述查询，或者如果我在这里遗漏任何东西。

PS：我已经尝试将查询修改为以下但找不到任何改进。

select count(user_id) user_count, group_id
from user_group_report
where type_id = 1
group by group_id;

任何一点帮助表示赞赏。

编辑：

根据建议，我添加了一个新索引

type_group on (type_id,group_id)

这是新的解释计划。解释中的行数，减少但查询执行时间仍然相同

+----+-------------+------------------+------+---------------------------------+---------+---------+-------+-------+--------------------------+
| id | select_type | table            | type | possible_keys                   | key     | key_len | ref   | rows  | Extra                    |
+----+-------------+------------------+------+---------------------------------+---------+---------+-------+-------+--------------------------+
|  1 | SIMPLE      | user_group_report | ref  | user_group_type,type_group,user_group | type_group | 5       | const | 59846 | Using where; Using index |
+----+-------------+------------------+------+---------------------------------+---------+---------+-------+-------+--------------------------+

编辑 2： 按照答案/评论中的建议添加详细信息

select count(*)
from user_group_report
where type_id = 1

此查询本身需要 0.25 秒才能执行。

这是解释计划：

+----+-------------+------------------+------+---------------+---------+---------+-------+-------+-------------+
| id | select_type | table            | type | possible_keys | key     | key_len | ref   | rows  | Extra       |
+----+-------------+------------------+------+---------------+---------+---------+-------+-------+-------------+
|  1 | SIMPLE      | user_group_report | ref  | type_group       | type_group | 5       | const | 59866 | Using index |
+----+-------------+------------------+------+---------------+---------+---------+-------+-------+-------------+
4

3 回答 3

4

我相信你group_type是错的。尝试切换属性。

create index ix_type_group on user_group_report(type_id,group_id)

此索引更适合您的查询，因为您type_id = 1在where子句中指定了。因此，查询处理器在您的索引中找到第一条记录type_id = 1，然后用它扫描索引中的记录type_id并执行聚合。使用这样的索引，只能访问索引中的相关记录，这是索引无法访问的group_type。

于 2019-03-27T10:47:39.113 回答
2

如果 type_id 是有选择性的（即它显着减少了搜索空间），创建索引type_id, group_id应该会有很大帮助。

这是因为它减少了需要首先分组的记录数量（删除 type_id != 1 的所有内容），然后才进行分组/求和。

编辑：

根据评论，我们似乎需要更多地了解瓶颈在哪里——查找记录或分组/求和。

第一步是衡量以下方面的表现：

select count(*)
from user_group_report
where type_id = 1

如果这明显更快，则挑战可能在于分组而不是查找记录。如果这同样慢，那么首先要找到记录。

于 2019-03-27T10:47:38.923 回答
1

大多数列真的需要NULLable吗？更改到NOT NULL适用的地方。

有多少百分比的表type_id = 1？如果它是桌子的大部分，那么这就解释了为什么你没有看到太大的改进。同时，EXPLAIN似乎认为只有两个不同的值type_id，因此它说只有一半的表会被扫描——这个数字是不可信的。

要更深入地了解正在发生的事情，请执行以下操作：

EXPLAIN FORMAT=JSON SELECT...;

和

FLUSH STATUS;
SELECT ...
SHOW SESSION STATUS LIKE 'Handler%';

我们可以帮助解释您获得的数据。（这里是对此类的简要讨论。）

于 2019-04-18T17:47:01.640 回答