參考地址：
如何看MS SQLSERVER數據庫的執行計划https://blog.csdn.net/luoyanqing119/article/details/17022649
SQLserver索引的原理和應用https://www.cnblogs.com/knowledgesea/p/3672099.html
聚集索引和非聚集索引https://www.cnblogs.com/aspnethot/articles/1504082.html
數據庫SQL優化大總結之 百萬級數據庫優化方案https://www.cnblogs.com/yunfeifei/p/3850440.html
數據庫優化之程序操作優化https://www.cnblogs.com/AK2012/archive/2012/12/28/2012-122803.html
為什么不建議用select *？https://blog.csdn.net/u013240038/article/details/90731874
上圖中，數據庫執行一個T-SQL發生的事，了解一下數據庫的構成以及功能。
執行計划：
可以緩存，存儲過程/參數化查詢
select * from User where id=1
select * from User where id=2
select * from User where id=@id
數據是什么？
數據庫就是把東西有序放好，還能隨時找到的一個工具。應用程序，有序的數據管理，數據在硬盤上（持久化，唯一的，多線程操作需要加鎖，速度慢，可以SSD加快速度）。char nvarchar字段最長是8kb。
聚集索引
舉個例子，在圖書館中，就是書多。圖書館是怎么分類的呢？文學、武俠、IT.....每個類別還有很多書啊，就按照首字母排序。新華字典文字都是按照字母排序的。聚集索引也叫聚簇索引，把數據有序的拜訪，物理排序，找字母a開頭，找時間范圍的。。。
SQLserver自增int，默認聚集索引，所以查詢不排序，就是Id排序。換聚集索引很耗時，很多的硬盤操作，生產環境需要謹慎。聚集索引只有一個，但是生成聚集索引的可以有多個列。一般是自增主鍵/創建時間/價格。因為數據物理排序了，所以查詢快，非常適合大於、小於、between order by。
聚集索引速度大於非聚集索引
非聚集索引
在新華字典中，偏旁部首查找漢子---找頁碼----看詳情。圖書館電子查找，輸入名字---樓層----書架---層。
特點：重復存儲值和路徑，體積小一些，所以查找快一些，快速定位，直達目標。不影響數據的物理排序，但是會重復存儲一個數據和位置。
找數據：先找索引----快速定位-----拿到數據，查找快，但是有維護的索引的成本，請小心。
非聚集索引可以有很多個，好像最多個255個，每個索引也可以有很多個字段，建議索引不要超過10個。適合經常查詢的字段。非聚集索引不能運算，不能like'% %'，也不能where Id-1>10。like 'a%'這個是可以用非聚集索引的。
建議索引的原則/建議：
1、主鍵是必須建立索引的（推薦數值主鍵，性能最高）
2、外鍵也要索引，join能提升性能
3、經常查詢的字段建立索引
4、經常在where里面的也要建立索引
5、order by 、group by、distinct
6、聚合運算/where條件時，先索引字段
不需要建立索引的：
1、基本不怎么查詢的
2、重復值比較傴的
3、text/image不要索引
4、索引不要太多了
還有其他的索引，主XML索引、輔助XML索引、空間索引、非聚集Columnstore索引（數量超過千萬的時間建立的索引，先出的一個東西吧）
執行計划：
提交SQL語句，數據庫查詢優化器，經過分析生成，指定多個查詢方式，從中算則使用資源最少的，數控制定執行計划是按照使用資源最少，而不是時間最短。
1、Table Scan 全表掃描性能最差
2、Cluster Index Scan （聚集索引的掃描） 性能最差，同上，雖然有聚集索引，其實也是全表掃描
3、Index Seek（NonClustered）（索引查找） 性能非常高
4、Index Scan 先Index 再掃描
5、Cluster Index Seek 性能最高
常規的SQL優化建議
1、對列的計算，任何形式都要避免
2、in 查詢 or 查詢索引會失效，可能是拆分
3、in 換 exists，not in 不要用，完全不走索引
4、is null 和 is not null都不走索引，索引里面不保存null的
5、<>這種也不走索引，可以拆分成< 和 >
6、join時，連接越少，性能越高。左連接，以左邊的表結果為主；右連接，反過來；連接字段要求帶索引
當數據庫量達到上億之后，索引用處就不大了，SQLserver數據庫，兩千萬就可以了。當數據量過大，就應該從數據庫設計層次找問題了。