MySQL composite index with or without ID

One 、 Preface

A few days ago, there was a slow sql problem , The scene is import and Export ,, This watch has about 2 More than 100 million data , Need to add index optimization , Tables and fields are desensitized ., primary sql Something like that ：

select * from object_range force index(idx_obj_no_id) where type = 1 and biz_type = 1 and obj_no = 123 order by id limit 1000,500

You can see that there are three query fields type,biz_typ,objec_no, The original query force index go obj_no and id Joint index of , But because of a single object_no The number of lines will still go to hundreds of thousands , So it's still slow to query .

Two 、 First processing .

According to my previous understanding , The composite index is automatically added id Of , Therefore, changes were made directly in production, and these three query fields were linked together to build a joint index idx_type_biz_type_obj_no. And then modify sql Removed force_index I went for a run explain

--  The modified sql no need force_index Time 0.015s
select * from object_range where type = 1 and biz_type = 1 and obj_no = 123 order by id limit 1000,500

--  Go to the new index idx_type_biz_type_obj_no
explain select * from object_range where type = 1 and biz_type = 1 and obj_no = 123 order by id limit 1000,500

Very satisfied with , Then publish directly .
Unfortunately, production is still the same slow sql, hold sql Pull it down and find it under specific parameters explain, This article sql Can go to the primary key index , Why did you leave primary Index? .

3、 ... and 、 solve

First , One sql stay mysql After the analyzer , Optimizer , actuator , Goodbye to the storage engine etc.
After consulting colleagues, I found , Composite indexes do add id, I really remember this correctly , But it turns out that this is in the storage layer . about mysql The optimizer does not know that this index is added id.

So in the sql When analyzing and optimizing , Especially when it comes to sorting , Probably mysql The optimizer thinks there will be filesort So use the primary key id The index will be better , Because the optimizer does not know that there is id, Therefore, the analysis will not consider ...

Then on sql Once again, the forced index publishing , slow sql period .

explain select * from object_range index(idx_type_biz_type_obj_no) where type = 1 and biz_type = 1 and obj_no = 123 order by id limit 1000,500

Back to the beginning , I understand why I started this sql To add idx_obj_no_id Indexes . So the next time you add a joint index, you'd better be honest and finally id add , There is no loss , There will be unexpected gains .