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

資深大佬 : zhaoxixiangban 3

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`

大佬有話說 (21)

主資深大佬 : zhaoxixiangban

“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

联合索引咯，share_user_id,create_time 。
資深大佬 : gengz

建个索引(share_user_id, create_time)
資深大佬 : purensong

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

create_time 建索引不好，4F 方案不错
主資深大佬 : zhaoxixiangban

@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

@freebird1994 感谢，但是建立联合索引没有改善
主資深大佬 : zhaoxixiangban

@gengz 感谢，但是建立联合索引没有改善
主資深大佬 : zhaoxixiangban

@dongisking 嗯我试试，谢谢
資深大佬 : stevenkang

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

12 小时以内的数据，按分钟统计；
1 周以内的数据，按小时统计；
一周以上的数据，按天统计；
主資深大佬 : zhaoxixiangban

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

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

顺便把 FORCE_INDEX 去掉再看看，建组合索引之后 FORCE_INDEX 容易绊脚
主資深大佬 : zhaoxixiangban

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

https://www.db-fiddle.com/f/mH4oTUgZF5fzCHJ1Fxf9kt/0
主資深大佬 : zhaoxixiangban

@jsq2627 #15 可以的赞！
資深大佬 : sansanhehe

@zhaoxixiangban 所以你最终是用的(create_time, share_user_id)索引，还是(share_user_id, create_time)索引？有没有用 force index ？可以分享一下吗？
資深大佬 : goodboy95

@zhaoxixiangban 好吧，把范围查询的情况给忘了……确实先 share_user_id 才对……
主資深大佬 : zhaoxixiangban

@sansanhehe #17 (share_user_id, create_time) 没有用 force index 参考 15
資深大佬 : kimchan

@zhaoxixiangban #19 想问下, 15 和 2 3 有区别吗.. 因为我看你前面说的建立联合索引没有改善. 看的有点懵
主資深大佬 : zhaoxixiangban

@kimchan #20 前面我没有去掉 “FORCE_INDEX”