[sql 优化] 麻烦大佬看下这段 sql 怎么优化能快点

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1659 天前的主题，其中的信息可能已经有所发展或是发生改变。

CREATE TABLE `fx_share` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'ID',
`share_id` varchar(36) NOT NULL COMMENT '分享 ID',
`share_channel_id` varchar(10) DEFAULT NULL COMMENT '分享渠道 ID',
`aim_id` varchar(36) NOT NULL COMMENT '分享目标 ID',
`share_url` varchar(255) DEFAULT NULL COMMENT '分享的链接',
`share_user_id` varchar(36) NOT NULL COMMENT '分享发起人（导购）',
`share_title` varchar(255) DEFAULT NULL COMMENT '分享的标题（预留字段）',
`share_extra` varchar(255) DEFAULT NULL COMMENT '分享的参数（预留字段）',
`watch_count` int(11) DEFAULT NULL COMMENT '浏览次数',
`create_time` datetime NOT NULL COMMENT '创建时间',
`update_time` datetime DEFAULT NULL COMMENT '更新时间',
`deleted` tinyint(1) DEFAULT NULL COMMENT '删除：0 未删除，1 删除',
`bind_status` varchar(5) DEFAULT 'true' COMMENT '绑定状态用于顾客和导购绑定（为 0 时可以绑定，为 1 时不可以绑定）',
PRIMARY KEY (`id`,`share_id`) USING BTREE,
UNIQUE KEY `unx_shareid` (`share_id`) USING BTREE,
KEY `idx_userid` (`share_user_id`) USING BTREE,
KEY `idx_aim` (`aim_id`) USING BTREE,
KEY `create_time_index` (`create_time`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=811316 DEFAULT CHARSET=utf8mb4 COMMENT='分享表';

EXPLAIN SELECT
`share_user_id` AS `shoppingGuideId`,
count( share_user_id ) AS `statisticNum`
FROM
fx_share FORCE INDEX(create_time_index)
WHERE
create_time > '2020-01-01 00:00:03' AND create_time <'2020-06-28 16:55:03'
GROUP BY
`shoppingGuideId`

23 条回复 • 2020-05-23 10:47:28 +08:00

zhaoxixiangban

2020-05-11 10:42:23 +08:00

"id" "1"
"select_type" "SIMPLE"
"table" "fx_share"
"partitions" "range"
"type" "range"
"possible_keys" "idx_userid,create_time_index"
"key" "key_len" "create_time_index"
"ref" "5"
"rows" "217959"
"filtered" "100"
"Extra" "Using index condition; Using temporary; Using filesort"

freebird1994

2020-05-11 10:52:31 +08:00

联合索引咯，share_user_id,create_time 。

gengz

2020-05-11 10:58:01 +08:00

建个索引(share_user_id, create_time)

purensong

2020-05-11 11:02:31 +08:00

我想法是再派生出一列，把 create_time 的日期提取出来作为字段 date，加上索引，先筛选 date 再筛选 create_time

dongisking

2020-05-11 11:14:38 +08:00

create_time 建索引不好，4F 方案不错

zhaoxixiangban

2020-05-11 11:28:22 +08:00

@purensong 你是説，增加字段 date copy create_time 字段，然后 [date> '2020-01-01 00:00:03' AND date<'2020-06-28 16:55:03' and create_time > '2020-01-01 00:00:03' AND create_time <'2020-06-28 16:55:03' ] 这样么？

zhaoxixiangban

2020-05-11 11:28:55 +08:00

@freebird1994 感谢，但是建立联合索引没有改善

zhaoxixiangban

2020-05-11 11:29:02 +08:00

@gengz 感谢，但是建立联合索引没有改善

zhaoxixiangban

2020-05-11 11:29:22 +08:00

@dongisking 嗯我试试，谢谢

stevenkang

2020-05-11 11:38:14 +08:00

建议按粒度定时统计，要用时直接从统计表查。

12 小时以内的数据，按分钟统计；
1 周以内的数据，按小时统计；
一周以上的数据，按天统计；

zhaoxixiangban

2020-05-11 11:46:00 +08:00

@stevenkang 这个明天就要用，我也是这么想的，空间换时间。但是实现需要点时间，只能先上功能后面优化了。

goodboy95

2020-05-11 14:04:46 +08:00

为什么楼上是先 share_user_id 再 create_time 的？这按理说不应该是先筛 create_time，再照 share_user_id 去分组吗？我开始对自己的知识产生怀疑了……
不过怀疑归怀疑，试一下建立(create_time, share_user_id)的组合索引吧，也算是帮我证明一下我的知识有没有问题了。

goodboy95

2020-05-11 14:06:14 +08:00

顺便把 FORCE_INDEX 去掉再看看，建组合索引之后 FORCE_INDEX 容易绊脚

zhaoxixiangban

2020-05-11 14:16:02 +08:00

@goodboy95 #13 受教了，到 1s 内了。组合索引也有顺序问题，组合索引用 FORCE_INDEX 会有影响