【 TiDB 使用环境】测试
【 TiDB 版本】6.5
【复现路径】执行SQL
【遇到的问题：问题现象及影响】
【资源配置】
【附件：截图/日志/监控】
如上图所示，我为表建立了一个联合索引
执行explain发现索引并未起作用
我在sql语句中加入USE INDEX后，explain后发现这时索引才起到作用，在mysql中不指定USE INDEX索引依然可以生效，麻烦大佬解释下问题原因谢谢
如上图所示，我为表建立了一个联合索引
执行explain发现索引并未起作用
我在sql语句中加入USE INDEX后，explain后发现这时索引才起到作用，在mysql中不指定USE INDEX索引依然可以生效，麻烦大佬解释下问题原因谢谢
数据是如何分布的? select project_id ,count(1) from table group by project_id order by 2 desc ,331万条是统计信息不准确吗？
331万是索引条数吧
如果你建了time索引 都会走错路
您好，联合索引确实用到了datetime类型的字段，和这个有关系么
两边的优化器有区别
使用索引 和不适用这个 索引的效率那个更快点？ 那个更好呢 ？
mysql有个ICP特性， 对于tidb 也有下推到tikv的能力。 优化算法不同，选择的路径就不同
如果不加use index的话，查询时间需要十几秒，加完后使用索引的查询时间在一秒左右
您把 表结构发出来看下？？？
固定下执行计划吧。 tidb支持固定执行计划。 或者在程序上 加上这个索引
DDL 那个？ 表创建语句
CREATE TABLE turnstile_inout_record (
id bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘主键’,
person_id bigint(20) NOT NULL DEFAULT ‘0’,
org_id bigint(20) NOT NULL DEFAULT ‘0’,
project_id bigint(20) NOT NULL DEFAULT ‘0’ COMMENT ‘项目_id’,
turnstile_id varchar(20) NOT NULL DEFAULT ‘’,
area_id bigint(20) NOT NULL DEFAULT ‘0’ COMMENT ‘区域id’,
current_area_id varchar(100) NOT NULL DEFAULT ‘’,
card_number varchar(50) NOT NULL DEFAULT ‘’ COMMENT ‘卡号’,
pass_time datetime DEFAULT NULL COMMENT ‘通过时间???’,
access_dict int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘出/入’,
create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT ‘创建时间’,
update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ‘更新时间’,
is_removed tinyint(1) NOT NULL DEFAULT ‘0’ COMMENT ‘逻辑删除’,
result_photo varchar(255) DEFAULT NULL,
PRIMARY KEY (id) /*T![clustered_index] CLUSTERED */,
KEY idx_project_and_pass (project_id,pass_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=13994279 COMMENT=‘闸机进出日志’;
正常，先analyze下表，看看是否能合理使用索引
估计要重新收集一下统计信息