乙個詭異的MySQL索引選擇問題

2021-09-08 15:52:45 字數 1515 閱讀 8554

表結構及資料量

create table `tb_habit_log_total` (

`totalid` int(11) not null auto_increment,

`openid` varchar(100) collate utf8mb4_unicode_ci not null default '',

`habitid` int(11) not null,

`joincreatedate` timestamp null default current_timestamp,

`totalsuccessday` int(11) default '0',

`totallastdate` date default null,

`joinstate` tinyint(1) default '1',

`totaladminrole` tinyint(1) default '0',

primary key (`totalid`),

unique key `uk_hid_oid` (`habitid` , `openid`) using btree,

key `openid` (`openid`),

key `idx_totalsuccessday` (`totalsuccessday`),

key `idx_totallastdate` (`totallastdate`),

key `idx_totaladminrole` (`totaladminrole`),

key `idx_joincreatedate` (`joincreatedate`),

key `idx_hid_js_tid` (`habitid` , `joinstate` , `totalid` , `joincreatedate`) using btree

) engine=innodb auto_increment=22854700 default charset=utf8mb4;

索引情況 

然後看看詭異的執行計畫,這倆只是habitid不同

看看各自的資料量

儘管資料量不一樣,但這也不應該是mysql選擇走totalid索引的理由,因為where條件加order by條件以及limit條件可以確定走idx_hid_js_tid索引才是最快的,排序可以直接通過索引排,取前10條返回就ok

最後發現,order by把聯合索引都指定上的話,mysql終於選對索引了

關於socket物件在xp下的乙個詭異問題

1.因公司需求裝了幾台xp老機器 結果各種奇詭譎閃爍的情況出現了。socket通訊線程裡 2.在主線程建構函式中 建立 socket物件 qudpsocket s1 new qudpsocket this s1 bind qudpsocket reuseaddresshint,port recv r...

mysql索引技巧 mysql索引的乙個技巧

針對select from table where col1 number order by col2 desc。其實按照常規的方法可以這樣設計 key col1,col2 但是這種辦法在mysql裡不算是理想的,where條件裡限定索引前部分是乙個範圍的情況下後面的order by還是會有file...

乙個看似詭異的錯誤

先上 客戶端 如下 include include include include include void str cli file stream,int fd int main int argc,char argv int socket fd 5 int i for i 0 i 5 i str ...