为什么 MySQL 在此查询中不使用我的索引？

Question

建表语句：

create table stock_master.turnover_rate_trade
(
    id int auto_increment
        constraint `PRIMARY`
            primary key,
    before_day int null,
    pre_day int null,
    turnover_rate double null ,
    max_rise double null ,
    keep_day int null ,
    code varchar(50) null ,
    date date null ,
    real_keep int null ,
    rate double null ,
    create_time timestamp default CURRENT_TIMESTAMP null,
    update_time timestamp default CURRENT_TIMESTAMP null,
    constraint uindex
        unique (before_day, pre_day, turnover_rate, max_rise, keep_day, code, date)
);

我的 select 声明：

select id,
       before_day,
       pre_day,
       turnover_rate,
       max_rise,
       keep_day,
       code,
       date
       real_keep,
       rate,
       create_time,
       update_time
from turnover_rate_trade
where
   before_day=6 and pre_day =3 and turnover_rate=22.1 and max_rise =7.1 and keep_day=5 and 
   code='100000' and date='2022-02-02'

执行计划：

我不是专业的dba，尽量避免索引失效。
条件里写的很清楚，就是不行。

表数据信息：

rows: 2 hundred million
before_day: 5~29
pre_day: 0~4
keep_day: 0~29
turnover_rate: 1~23
max_rise: 1~29

平均分配

按照建议：
删除和重建索引花了我一个多小时。

create index turnover
                on turnover_rate_trade (before_day, pre_day, turnover_rate, max_rise, keep_day, code, date)

现在可以了吗？有人可以解释一下吗？

Answer 1

FLOAT或DOUBLE是近似值，以二进制形式存储。 22.1是一个无法精确存储在任何DOUBLE中的十进制值。 用一侧为DOUBLE而另一侧为非整数十进制数的=进行测试是有风险的。

我知道这无法解释为什么未使用索引（根据EXPLAIN ）。 但是让我们先修复比较。

计划 A：使用某种形式的范围测试。 （这肯定会弄乱使用索引。）

计划 B：将列切换为DECIMAL 。 （这样的ALTER会花费很长时间。）

你这里可能有错别字：

   code,
   date        -- perhaps you wanted a comma?
   real_keep,

另一个问题......您没有指定PRIMARY KEY （并且由于其大部分列的可空性，该UNIQUE键无法提升为 PK）。 所有表确实需要一个PK。

建议在适当的地方制作列NOT NULL 。

建议添加显式 PK。

（同样，我无法向您的索引解释失败。）