表名 label_file_bridges
+------------+------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+------------+------+-----+---------+----------------+
| id | int(32) | NO | PRI | NULL | auto_increment |
| label_id | int(32) | NO | MUL | NULL | |
| file_id | int(32) | NO | | NULL | |
| is_active | tinyint(1) | NO | | NULL | |
+------------+------------+------+-----+---------+----------------+
PRIMARY id
idx_label_file_bridge_label_id_file_id_is_active (label_id, file_id, is_active)
select file_id, group_concat(label_id) from label_file_bridges where label_id in (1,2,3,4,5,6,7,8,9,10) and is_active=1 group by file_id;
id: 1
select_type: SIMPLE
table: label_file_bridges
partitions: NULL
type: index
possible_keys: idx_label_file_bridge_label_id_file_id_is_active
key: idx_label_file_bridge_label_id_file_id_is_active
key_len: 9
ref: NULL
rows: 48182
filtered: 10.00
Extra: Using where; Using index; Using filesort
表数据量百万级,以上是测试数据, 使用此 sql 速度还行,但是存在外层排序 filesort, 调试发现用 in + order_by 或者 in + group_by 都会有这个情况 请教一下这个 sql 或者表结构 ( 索引 ) 有可优化的地方吗,有可能避免 filesort 吗
1
lpts007 2020-11-18 14:56:54 +08:00 via Android 1
加 order by null 试过没
|
2
fhsan 2020-11-18 15:18:57 +08:00 1
order by label_id, file_id, is_active
group by file_id |
3
Egfly 2020-11-18 15:32:39 +08:00 1
索引位置换一下 file_id 放在 label_id 前面就行
|
7
Egfly 2020-11-18 15:52:29 +08:00 2
@SjwNo1
主要是 in 导致的。经过 label_id 的 in 查询之后的结果集不是有序的(虽然你 in 的数据是有序的,但是优化器并不知道)。所以需要使用临时表完成 group_by 操作。 如果你把 in 换成 label_id=xxx,应该也是不用 file_sort,可以直接走原索引,你可以 explain 看一下。 |
9
zlowly 2020-11-18 16:10:35 +08:00 1
是否可以考虑用表分区?
is_active 字段从名字上猜测是可变的,不适合分区。但这个 label_id 不知道它的数据是否是可以考虑进行分区? |