[英]Why does MySQL not use my index in this query?
create table statement:建表语句:
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)
);
my select statement:我的 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'
I am not a professional dba, avoid indexes invalidation as much as possible.我不是专业的dba,尽量避免索引失效。
It is clearly written in the conditions, but doesn't work.条件里写的很清楚,就是不行。
The table data information:表数据信息:
rows: 2 hundred million
before_day: 5~29
pre_day: 0~4
keep_day: 0~29
turnover_rate: 1~23
max_rise: 1~29
evenly distributed平均分配
as suggested:按照建议:
It took me over an hour to delete and rebuild index.删除和重建索引花了我一个多小时。
create index turnover
on turnover_rate_trade (before_day, pre_day, turnover_rate, max_rise, keep_day, code, date)
FLOAT
or DOUBLE
are approximate values, stored in binary. FLOAT
或DOUBLE
是近似值,以二进制形式存储。 22.1
is a decimal value that cannot be stored exactly in any DOUBLE
. 22.1
是一个无法精确存储在任何DOUBLE
中的十进制值。 It is risky to test with =
with a DOUBLE
on one side and a non-integral decimal number on the other side.用一侧为
DOUBLE
而另一侧为非整数十进制数的=
进行测试是有风险的。
I understand that this fails to explain why the Index was (according to the EXPLAIN
) not used.我知道这无法解释为什么未使用索引(根据
EXPLAIN
)。 But let's fix the comparison first.但是让我们先修复比较。
Plan A: Use some form of range test.计划 A:使用某种形式的范围测试。 (This will definitely mess up using the index.)
(这肯定会弄乱使用索引。)
Plan B: switch the column to DECIMAL
.计划 B:将列切换为
DECIMAL
。 (Such an ALTER
will take a long time.) (这样的
ALTER
会花费很长时间。)
You possibly have a typo here:你这里可能有错别字:
code,
date -- perhaps you wanted a comma?
real_keep,
Another issue... You have not specified a PRIMARY KEY
(and that UNIQUE
key cannot be promoted to PK due to nullability of most of its columns).另一个问题......您没有指定
PRIMARY KEY
(并且由于其大部分列的可空性,该UNIQUE
键无法提升为 PK)。 A PK is really needed for all tables.所有表确实需要一个PK。
Suggest making columns NOT NULL
where appropriate.建议在适当的地方制作列
NOT NULL
。
Suggest adding an explicit PK.建议添加显式 PK。
(Again, I can't explain the failure to your your index.) (同样,我无法向您的索引解释失败。)
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.