一、業務場景
專案開發中，資料儲存是一定少不了的，不管是儲存關係型資料還是還是非關係型資料。可選擇的範圍也很廣，比如mysql，postgresql，oracle,mongodb等等。一般都是根據專案的實際需要來選用資料庫。選擇資料庫後，需要考慮的一個問題就是資料的儲存效能，當資料量不多的時候，快一點慢一點影響都不大。可是在專案後期，隨著資料量的不斷增多，就必須要考慮效能問題，否則使用者的使用體驗會很差。比如載入一個頁面非常慢，做某一個操作花的時間特別長等等。那麼如何提升資料庫中資料的存取效率呢？這就不得不說資料庫索引這個資料結構。簡單點說索引就好比是閱讀一本書的時候，書中的目錄，可以讓你快速找到你想看的內容。資料庫索引也是同樣的道理，可以根據索引快速找到使用者想查詢的資料。下面就來說說真實專案中，索引使用的一些場景。
三、應用場景
.1.資料表中的更新時間欄位建立普通索引；
這個欄位建立索引的原因是一般排序的時候會使用到這個欄位，還有很多的時間區間查詢的時候會使用到這個欄位；
.2.具有唯一性的欄位，並且這個欄位可能會單獨作為一項查詢條件，這種情況可以建立唯一索引；
比如什麼什麼編號，或者MQ訊息的訊息ID欄位，可以單獨建立一個索引；處理的時候一般會進行訊息唯一性處理，會根據訊息ID去查詢某條資料是否已經處理過了。
.3.某幾個欄位從業務角度考慮具有唯一性，可以建立聯合的唯一索引；
這種情況需要根據真實的業務需求具體分析，可能有兩個欄位，也可能有三個欄位，組合起來具有唯一性。這樣在資料入庫的時候，就避免了資料重複。因為如果重複插入，會直接報錯。
.4.兩個欄位或者是三個欄位建立普通聯合索引；
這種索引主要就是為了加快查詢效率。
.5.單個欄位建立普通索引；
這種處理方式是為了加快查詢效率，比如有的按照名稱查詢時，可以加一個索引，提高查詢效率。
.6.關聯表中儲存的主表中的主鍵欄位；一般會建立普通索引；
這種比較常規，為了加快查詢效率而建立的索引；特別是在進行關聯查詢的時候；
.7.表中的ID，非主鍵ID，而是業務資料的唯一ID，可以建立一個唯一索引。
這種情況一個是為了確保資料ID的唯一性，還有一個就是為了加快查詢效率。
總結：上面的幾種情況，是專案當中正在使用的幾種方式。專案中幾乎所有的表在建表的時候，都建立了索引，就是為了加快資料存取的效率。
自己在今後的工作中也可以借鑑。有其他想法的小夥伴，歡迎留言討論。