參考地址：
如何看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資料庫，兩千萬就可以了，當資料量過大，就應該從資料庫設計層次找問題了，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/39247.html
標籤：SQL Server
上一篇：資料庫設計優化