关于order by慢查询及索引hit的问题

q1:如下图,加了索引hint最后查执行计划还是没有走索引,是我使用姿势的问题?
q2.加索引用了13分钟(600w量级),是否有order by更好的优化方案?
q3:如下图如果去掉order by和limit,是否使用TiFlish查询更佳,不会影响TiKV的write和ddl/dml

版本信息:
±-------------------+
| @@version |
±-------------------+
| 5.7.25-TiDB-v4.0.0 |
±-------------------+

执行计划:

  1. 请上传所有需要使用的表结构
  2. 加什么索引使用13分钟?
  3. 去掉order by 和 limit 是要查询全量? 和这个sql的意义不是不一样了? tiflash 不影响tikv

1.CREATE TABLE feature.user_hot_click_list_weekly (
gid BIGINT NOT NULL,
feat_val TEXT NOT NULL,
create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
UNIQUE KEY (gid)
)
;
CREATE UNIQUE INDEX user_unique_gid ON feature.user_hot_click_list_weekly (gid);
CREATE INDEX user_hot_click_list_weekly_create_time_index
ON feature.user_hot_click_list_weekly (create_time)
;

2.索引名:user_hot_click_list_weekly_create_time_index
3.是的,具体是查某个时间戳之前的全量,想通过tiflish隔离读写(tp,ap)

  1. select gid,feat_val,create_time from user_hot_click_list_weekly t1 use index(user_hot_click_list_weekly_create_time_index) 可以这样参考使用索引

  2. 从你的sql来看是要通过create_time来获得所有信息,所以走索引是合理的

  3. tiflash 不会影响 tikv

1.这个是参照官方的例子sql-中如何通过-hint-使用一个具体的-index,所以两者的本质区别是什么?不推荐hint的原因是?
2.关于慢查询我现在怀疑是@query_time导致的,理由如下:

set @gid=20892449;
MySQL [(none)]> select gid,feat_val,create_time
    -> from feature.user_hot_click_list_weekly a
    -> where gid = @gid \G
*************************** 1. row ***************************
        gid: 20892449
   feat_val: xxxxxx
create_time: 2020-06-14 18:31:10
1 row in set (3.97 sec)
MySQL [(none)]> select gid,feat_val,create_time
    -> from feature.user_hot_click_list_weekly a
    -> where gid = 20892449 \G
*************************** 1. row ***************************
        gid: 20892449
   feat_val: xxxxxxx
create_time: 2020-06-14 18:31:10
1 row in set (0.00 sec)
  1. 你给的链接,和我给你发的一样吧,和你写的不一样
  2. 能否多尝试几个不同的值,看下是否是@gid 或者 @cretae_time导致的,多谢;另外,你们每次新的session都要这样set值吗?

1.所以是猜测;
2.我这边set只是为了方便统一sql,每次更改用户变量就可以了;所以set不是必须的;@gid我有尝试10个不同的值,去掉@gid替换成指定值,均复现从3s到0s的提升;所以可以确定是@用户变量的原因

您好,确认了,由于暂时不支持getvar 这种走pointget,所以会消耗更多时间。我会反馈这个需求,暂时可能无法解决,多谢。