很多程序員都不喜歡字符串，我也是，字符串處理起來太麻煩了，而且字符串也比較占空間。舉個例子，一個字符要占1個字節，但一般常用字符就那么幾個(例如我們常要求用戶名只能是大小寫字母與數字)。另外一個問題，就是數據庫查詢的時候，用字符串查詢太不方便了。今天我們來了解下，數據庫中的字符串查詢問題。

[[321170]]

在PC互聯網時代，我們的很多賬戶都需要綁定電子郵箱，我們偶爾需要使用電子郵箱，也就是字符串來進行數據查詢，為了保證查詢效率，我們通常要對字符串字段建立索引。

我們都知道，在InnoDB中，通常使用的是B+樹索引，如果索引的類型是字符串，那么我們可能會面臨這樣一個問題，索引的長度會變得特別長，索引的長度過長會讓索引的索引占用更多的存儲空間，同時也會增加索引的維護成本。通常我們使用字符串索引，只會使用前面若干個字符，假如用戶的郵箱的開頭是26個字母，并且用戶名隨機均勻分布的，那么我們即使使用第一個字符做索引，也能減少25/26的掃描量，假如使用前2個字符，就可以減少675/676次掃描。所以，即便我們只用前面的若干個字符，也能大大地減少數據庫的掃描，提升查詢速度。

但是在現實生活中，用戶名往往不是隨機分布的，像a開頭的用戶往往占比較大。有些字符串的字段，往往開頭是相似的，例如居民的身份證號，前面幾位數通常是省份跟城鎮，教育局的學生信息，通常id是入學時間加月份，索引的選擇最好要滿足唯一性，我們最好能使用更有特色的字段進行索引的建立。

例如身份證的問題，我們知道，身份證的前6位通常是地區信息，全國的省市區加起來也就是幾千個，而身份證的后六位是生日的日信息跟4個隨機數字。那么，僅有30萬分之一的概率后六位的數字是相同的。也就是說，如果把身份證號碼逆序存儲后，取前6位作為索引，可以減少近百分的數據掃描量，從而大大提升掃描的效率。

另外一種方法，就是建立哈希索引而不是B+樹索引，哈希索引的好處是在于查詢特定字符串的時候，幾乎都只要查詢一行數據。但是哈希索引的弊端是不支持范圍查詢，也不支持字符串匹配，假如的業務沒有這樣的場景，那可以使用哈希索引。

好了，今天我們簡單地介紹了Mysql數據庫中，字符串索引的使用。不知道對你是否有所啟發，歡迎大家關注我，共同學習，共同進步。