mysql組合索引創(chuàng)建

一般習(xí)慣上id都是主鍵吧，主鍵就相當(dāng)于唯一索引。對于你上面的情況，如果id字段有索引，那就不用再增加一個id+status的組合索引了

從實際場景出發(fā) , 結(jié)合數(shù)據(jù)量 , 然后充分利用explain多做幾次執(zhí)行計劃 , 才會有譜 .
如果也就個幾千幾萬的量 , 不加看起來也沒什么問題 .
除此之外 , 就是你這個status的狀態(tài)值有幾種 , 假如只有0和1兩種 , 索引的效果或許( 我是說或許 )不會有那么好 , 多說無意 , 自己做點兒數(shù)據(jù)跑跑測試吧 .

如果id已經(jīng)是主鍵，就不需要和status做組合索引了。

如果數(shù)據(jù)量大的話可以這么建索引，少的話沒必要。
建議你看下mysql索引原理：https://tech.meituan.com/mysq...

是的，這樣建組合索引很適合，但是如果表數(shù)據(jù)不多的話，就不太有必要，很可能還沒有全表掃描的快。

根據(jù)數(shù)據(jù)分布情景來決定是否來建立索引，id為主鍵一般不建議和其他字段建立組合索引

組合索引建立完成使用的時候，一定按照建立索引的順序使用，否則所以不起作用。

要看數(shù)據(jù)量大小

首先要看數(shù)據(jù)量大小

首先，這里的 id 應(yīng)該是主鍵吧？
然后是否適合可以考慮幾個問題：

1. 這個表的數(shù)據(jù)量時什么量級？
2. status 類型是 int 吧？ 其值是否為有限可枚舉的？
3. 生產(chǎn)環(huán)境中，此處是否是瓶頸？線上庫執(zhí)行很慢么？

一般來看，這種情況是沒必要建 組合索引 的，因為 索引 維護也是有成本的，會降低插入的效率。
而且如果 id 本身為主鍵唯一，查詢的速度就已經(jīng)很快了。