索引目錄
1、select * 對效率的影響
在我們平時的代碼編寫或面試題中，很多人都會疑惑：select * 到底合理嗎？
如果說不合理，爲什麼？如果說合理，原因又是什麼？
1）、阿里規範
在阿里java規範中是強制不允許使用select * 這種操作的。
下面分析一下爲什麼不允許這種操作。
1、增加查詢分析器解析成本。
這裏主要是考慮了多餘字段帶來的更多成本消耗。
假設一張表有10個字段，你只需要其中的三個字段做分析。若使用select *，分析器就需要解析這十個字段，且將這是個字段查詢出來也會增加多餘的網絡消耗，且若數據庫和應用程序不在同一臺服務器上，這種網絡消耗更加明顯。
2、增減字段容易與 resultMap 配置不一致。
採用select * 這種方式時，若表結構發生了改變，很容易導致操作失敗。
2）、其他缺點
1、會查詢出一些不需要的字段。這些字段很可能沒有索引，這樣就杜絕了覆蓋索引的可能性，而索引覆蓋又是速度極快，效率極高，業界極爲推薦的查詢方式。
2、多餘字段會增大數據傳輸時間。
3、大字段，例如很長的 varchar，blob，text。準確來說，長度超過 728 字節的時候，會把超出的數據放到另外一個地方，因此讀取這條記錄會增加一次 io 操作。
科普：覆蓋索引
解讀1： 就是select的數據列只用從索引中就能夠取得，不必從數據表中讀取，換句話說查詢列要被所使用的索引覆蓋。
解讀2：索引是高效找到行的一個方法，當能通過檢索索引就可以讀取想要的數據，那就不需要再到數據表中讀取行了。如果一個索引包含了（或覆蓋了）滿足查詢語句中字段與條件的數據就叫 做覆蓋索引。
2、索引的簡單介紹
1）、索引簡介
索引用於快速找出在某個列中有一特定值的行。不使用索引，必須從第1條記錄開始然後讀完整個表直到找出相關的行。表越大，花費的時間越多。如果表中查詢的列有一個索引，就能快速到達一個位置去搜尋到數據文件的中間，沒有必要看所有數據。
2）、索引分類
索引分單列索引和組合索引。
①、單列索引(主鍵索引,唯一索引,普通索引)
單列索引，即一個索引只包含單個列，一個表可以有多個單列索引，但這不是組合索引。
普通索引,這個是最基本的索引,
唯一索引,與普通索引類似,但是不同的是唯一索引要求所有的類的值是唯一的,這一點和主鍵索引一樣.但是他允許有空值
主鍵索引,不允許有空值,(在B+TREE中的InnoDB引擎中,主鍵索引起到了至關重要的地位)
②、組合索引
組合索引，即一個索引包含多個列。
如果你建立了 組合索引(a_b_c) 那麼他實際包含的是3個索引 (a) (a,b)(a,b,c)
在使用查詢的時候遵循組合索引的"最左前綴",下面我們來分析一下 什麼是最左前綴:及索引where時的條件要按照建立索引的時候字段的排序方式
1、不按索引最左列開始查詢.
（多列索引） 如index(‘a’, ‘b’, ‘b’)
查詢時使用where ‘b’ = ‘b1’ ,此時不使用索引,
查詢時使用where ’b‘ = ‘b1’ and ‘c’=‘c1’ ,此時也不能使用索引
2、查詢中某個列有範圍查詢，則其右邊的所有列都無法使用索引查詢（多列查詢）
where a= ‘a1’ and b like = ‘b%’ and c=’c’
查詢時只會使用索引中的前兩列,因爲like是範圍查詢
3、不能跳過某個字段來進行查詢,這樣利用不到索引,比如我的sql 是
select * from table where a > ‘a1’ and b = ‘b1’ and c = c1;
那麼這時候他使用不到組合索引.
因爲我的索引是 (a, b, c),如果第一個字段出現了範圍符號的查找,那麼將不會用到索引,如果我是第二個或者第三個字段使用範圍符號的查找,那麼他會利用索引,利用的索引是(a).
因爲上面說了建立組合索引(a, b, c), 會出現三個索引
③、聚集索引、非聚集索引
聚集（clustered）索引，也叫聚簇索引。
定義：數據行的物理順序與列值（一般是主鍵的那一列）的邏輯順序相同，一個表中只能擁有一個聚集索引。
一個表就像是我們以前用的新華字典，聚集索引就像是拼音目錄，而每個字存放的頁碼就是我們的數據物理地址，而拼音目錄對應的A-Z的字順序，和新華字典實際存儲的字的順序A-Z也是一樣的
非聚集（unclustered）索引。
定義：該索引中索引的邏輯順序與磁盤上行的物理存儲順序不同，一個表中可以擁有多個非聚集索引。
其實按照定義，除了聚集索引以外的索引都是非聚集索引，只是人們想細分一下非聚集索引，分成普通索引，唯一索引，全文索引。如果非要把非聚集索引類比成現實生活中的東西，那麼非聚集索引就像新華字典的偏旁字典，他結構順序與實際存放順序不一定一致。
3）、索引建立規範
索引建立的規範:
1:經常被搜索。2:經常排序。3:經常作爲where條件。4:無大量重複值。5:不經常更新。6:經常作爲order條件。
3、索引是不是越多越好
由於經常被問到這個問題，所以這裏單獨拉出來分析一下。
結論:不是
1、數據量小的表不需要建立索引,因爲小的表即使建立索引也不會有大的用處,還會增加額外的索引開銷。
2、不經常引用的列不要建立索引,因爲不常用,即使建立了索引也沒有多大意義。
3、經常頻繁更新的列不要建立索引,數據變更需要維護索引，越多的索引代表更多的維護成本。
4、更多的索引也需要更多的存儲空間。
5、重複值多的列不適合建立索引，例如sex字段，值只有男、女。這時建立索引就沒有意義。