场景

不废话直接建表：

create table t_log
(
    id                 bigint auto_increment comment '主键id'
        primary key,
    user_id            bigint                                 null comment '用户ID',
    eqp_number         varchar(255)                           null comment '设备号',
    type               char         default '1'               null comment '日志类型 0离线 1上线',
    title              varchar(255) default ''                null comment '日志标题',
    remote_addr        varchar(255)                           null comment '操作IP地址',
    current_project_id bigint                                 not null comment '当前项目ID',
    root_project_id    bigint                                 not null comment '根项目ID',
    create_time        datetime     default CURRENT_TIMESTAMP null comment '创建时间',
    eqp_name           varchar(50)                            null comment '设备名称',
    eqp_model          varchar(50)                            null comment '设备型号',
    eqp_major_type     varchar(5)                             null comment '设备大类1:微断主机;2';

)
    comment '日志' row_format = DYNAMIC;

现在有一个需求是需要根据项目类型(eqp_major_type) 和当前项目id（current_project_id）去查询且需要按着创建时间排序以10个分页。

OK

SELECT a.current_project_id AS projectId, a.eqp_name, a.eqp_model, a.eqp_number, a.type, a.create_time
FROM t_eqp_log a
WHERE a.current_project_id in (176)
and a.eqp_major_type = 1
order by a.create_time desc
LIMIT 10;

easy啊。

时间久了数据量变大 查询变慢了，leader： 那个谁，你去把这个接口sql优化一下

你看都没看直接加上索引

create index t_eqp_log_create_time_index
    on t_eqp_log (create_time);

create index t_eqp_log_current_project_id_index
    on t_eqp_log (current_project_id);

create index t_eqp_log_eqp_major_type_index
    on t_eqp_log (eqp_major_type);

条件字段都加上不就得了吗

但是

目标索引只有createtime被击中， 其他两个字段都没生效，

不对劲啊 （开始Google GPT

一句话总结就是说mysql优化器认为通过create_time索引效率更高，也就是三个字段都没有索引的情况，create_time字段查询的成本会更高，so嘎 那怎么解决呢。很简单啊 直接联合索引啊

create index t_eqp_log_current_project_id_eqp_major_type_create_time_index
    on t_eqp_log (create_time, current_project_id, eqp_major_type);

再次执行一下 不出意外就要出意外了 果然又没生效

分析分析再分析

怎么这行sql越看越不对劲呢。淦 eqp_major_type是string类型的 也就是 eqp_major_type = 1 是存在一个强转的过程

强转就会导致联合索引失效 服了 继续再来

等会 有点对劲啊 赶紧看看文档

官方文档这大一堆 总结就一句话。index是全索引扫描 效率不如range 且重点：

性能从最好到最差：null > system > const > eq_ref > ref > range > index > all

继续看看extra

总结一下就是说这次执行情况为：index 类型意味着 MySQL 使用了全索引扫描，尽管联合索引被使用，但可能在过滤上不如 range 类型有效。Backward index scan 表示它在倒序扫描整个索引，这种扫描方式效率相对低。

这时候突然有灵感，既然选择了联合查询肯定要考虑最左前导列原则啊，create_time作为第一导列 但是where条件却没有，也就是没法用它很好的利用where条件来过滤大部分数据，自然会选择全索引扫描 赶紧试试验证一下

h h h 果然皇天不负