寫(xiě)在前面

MongoDB支持的索引種類(lèi)很多，諸如單鍵索引，復(fù)合索引，多鍵索引，TTL索引，文本索引，空間地理索引等。同時(shí)索引的屬性可以具有唯一性，即唯一索引。唯一索引用于確保索引字段不存儲(chǔ)重復(fù)的值，即強(qiáng)制索引字段的唯一性。缺省情況下，MongoDB的_id字段在創(chuàng)建集合的時(shí)候會(huì)自動(dòng)創(chuàng)建一個(gè)唯一索引。本文主要描述唯一索引的用法。

關(guān)于什么是索引以及唯一索引這里就不做說(shuō)明了，不清楚的可以自行谷歌或者百度。是什么引起我寫(xiě)這篇文章呢，這來(lái)自于之前項(xiàng)目中的一個(gè)問(wèn)題。

我們用的是MongoDB數(shù)據(jù)存儲(chǔ)用戶(hù)信息，用戶(hù)表中曾經(jīng)用戶(hù)注冊(cè)是通過(guò)手機(jī)號(hào)注冊(cè)的，所以很理所當(dāng)然的給手機(jī)號(hào)加上了唯一索引(Unique)，這是沒(méi)有什么毛病。后期，我們需求改了。你也可以想到變成了既可以手機(jī)號(hào)注冊(cè)又可以郵箱注冊(cè)，這個(gè)時(shí)候由于手機(jī)號(hào)加了Unique索引，事實(shí)上這時(shí)候是會(huì)出現(xiàn)問(wèn)題的。

func init() {
 phoneIndex := mgo.Index{
 Key: []string{"phone"},
 Unique: true,
 }

 col := db.Collection(&User{})
 col.EnsureIndex(phoneIndex)
}

當(dāng)然這問(wèn)題其實(shí)也容易想到，當(dāng)用戶(hù)通過(guò)郵箱注冊(cè)此時(shí)手機(jī)號(hào)填空的時(shí)候，第一次沒(méi)什么問(wèn)題，下個(gè)用戶(hù)再以這種方式注冊(cè)的時(shí)候便會(huì)提示建立在phone上的索引值重復(fù)，很正常嘛，因?yàn)椴迦肓藘蓚€(gè)空值，注意這里是空字符串，而不是null。

于是我們嘗試修改，由于MongoDB是文檔型靈活的數(shù)據(jù)庫(kù)，少插多插一兩個(gè)字段不受影響，所以我們嘗試修改User實(shí)體Phone字段的入口，當(dāng)phone是空字符串的時(shí)候，不讓插入此字段。于是，我們便在phone字段中加入了omitempty標(biāo)簽(我們微服務(wù)用Go語(yǔ)言寫(xiě)的)。下面展示User一部分內(nèi)容：

type User struct {
 Email  string `bson:"email"`
 Salt  string `bson:"salt"`
 Phone  string `bson:"phone,omitempty"`
 IDCard string `bson:"idcard"`
 RealName string `bson:"realname"`
 AuthStatus int `bson:"auth_status"`
}

可以看到phone字段后加了omitempty標(biāo)簽，表示當(dāng)該字段為空的時(shí)候不插入。這還是會(huì)出現(xiàn)問(wèn)題，那么既然還是會(huì)出問(wèn)題為什么會(huì)想到這么解決呢？這源于對(duì)Mysql的使用經(jīng)驗(yàn)，習(xí)慣性的以為MongoDB和Mysql那樣，對(duì)null的值會(huì)不做其索引。也就是說(shuō)，在Mysql中，若在多條記錄中Phone值為Null是被允許的。

上面那種做法，還是會(huì)報(bào)錯(cuò)，提示插入了重復(fù)的值，只不過(guò)這時(shí)不是空字符串，而是null。所以有時(shí)候就不要把Mysql那套拿來(lái)了，Mysql是可以的，但Mongo不行。mongo還是會(huì)對(duì)該條記錄索引，即使該字段為被插入。

我喜歡看官方文檔，下面給出MongoDB官方文檔說(shuō)明：

If a document does not have a value for the indexed field in a unique
index, the index will store a null value for this document. Because of
the unique constraint, MongoDB will only permit one document that
lacks the indexed field. If there is more than one document without a
value for the indexed field or is missing the indexed field, the index
build will fail with a duplicate key error.

其實(shí)已經(jīng)說(shuō)得很清楚了，稍微會(huì)點(diǎn)英語(yǔ)應(yīng)該都能看懂，下面還是給出翻譯版:

如果文檔沒(méi)有唯一索引中索引字段的值，則索引將為此文檔存儲(chǔ)null值。由于唯一約束，MongoDB只允許一個(gè)缺少索引字段的文檔。如果有多個(gè)文檔沒(méi)有索引字段的值或缺少索引字段，則索引構(gòu)建將失敗并出現(xiàn)重復(fù)鍵錯(cuò)誤。

也就是說(shuō)這個(gè)字段哪怕在文檔中沒(méi)有，那么該字段將會(huì)存null值，該字段上也不能同時(shí)出現(xiàn)兩個(gè)null值，這就是為什么上面那種做法還是行不通的原因，其實(shí)上面那種做法也打破了數(shù)據(jù)結(jié)構(gòu)，雖然手機(jī)號(hào)未填，但數(shù)據(jù)庫(kù)中也不應(yīng)該缺少這個(gè)字段，盡管是非關(guān)系數(shù)據(jù)庫(kù)，畢竟還得考慮下業(yè)務(wù)設(shè)計(jì)。

解決方式

是不是就沒(méi)有解決方式了呢？當(dāng)然有，Mongo提供了Sparse Index，被翻譯為稀疏索引。下面是創(chuàng)建稀疏索引的例子：

db.getCollection("test").createIndex( { "phone": 1 }, { sparse: true })

執(zhí)行上面的語(yǔ)句后，不會(huì)去索引不存在phone字段的文檔。也就是說(shuō)存在才對(duì)其索引，那么此時(shí)和Unique索引結(jié)合起來(lái)就可以派上用場(chǎng)了。Unqiue是唯一，Sparse是存在才索引。所以，當(dāng)phone或email為空的時(shí)候我們可以不將其插入這是可以實(shí)現(xiàn)的。

db.getCollection("test").createIndex( { "phone": 1 }, { sparse: true,unique: true } )

上面是是mongo shell語(yǔ)法，通常我們一般通過(guò)代碼中建立索引，修改如下(當(dāng)然User結(jié)構(gòu)體中Phone字段omitempty標(biāo)簽還是要有的)：

func init() {
 phoneIndex := mgo.Index{
 Key: []string{"phone"},
 Unique: true,
 Sparse: true,
 }

 col := db.Collection(&User{})
 col.EnsureIndex(phoneIndex)
}

但是這又正如我們前面說(shuō)的那樣，打破了數(shù)據(jù)原有的數(shù)據(jù)結(jié)構(gòu)。哎，有得有得。當(dāng)然我們還可以從業(yè)務(wù)層面去解決，比如注冊(cè)時(shí)對(duì)其查詢(xún)等操作，當(dāng)然會(huì)耗一定性能，不管你是那空間換時(shí)間，還是拿時(shí)間換空間總得付出一個(gè)，別做一個(gè)太貪心的人。

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問(wèn)大家可以留言交流，謝謝大家對(duì)腳本之家的支持。

最新評(píng)論