1. 索引設計原則
索引設計不合理或缺少索引都會對資料庫的效能造成障礙，高效的索引對於獲得良好的效能非常重要。
設計索引時的一些原則：
◊ 索引並不是越多越好，乙個表中如果有大量的索引，不僅占用大量的磁碟空間，而且會影響insert、delete、update等語句的效能。當表中資料更改的同時，索引也會進行調整和更新。
◊ 避免對經常更新的表進行過多的索引，並且索引中的列盡可能少。而對經常用於查詢的字段應該建立索引，但要避免新增不必要的字段。
◊ 資料量小的表最好不要使用索引，由於資料較少，查詢花費的時間可能比遍歷索引的時間還要短，索引可能不會產生優化效果。
◊ 在條件表示式中經常用到的、不同值較多的列上建立索引，在不同值較少的列上不要建立索引。比如字段【性別】上只有【男】【女】兩個不同值，因此無須建立索引。如果建立索引，不但不會提高查詢效率，反而會嚴重降低更新速度。
◊ 當唯一性是某種資料本身的特徵時，指定唯一索引。使用唯一索引能夠確保定義的列的資料完整性，提供查詢速度。
◊ 在頻繁進行排序和分組（group by或order by）的列上建立索引，如果排序的列有多個，可以在這些列上建立組合索引。
2. 建立索引常用的規則
◊ 表的主鍵、外來鍵必須有索引；
◊ 資料量超過300的表應該有索引；
◊ 經常與其他表進行連線的表，在連線欄位上應該建立索引；
◊ 經常出現在where字句中的字段，特別是大表的字段，應該建立索引；
◊ 索引應該建在選擇性高的字段上；
◊ 索引應該建在小字段上，對於大的文字字段甚至超長字段，不要建索引；
◊ 頻繁進行資料操作的表，不要建立太多的索引；
◊ 刪除無用的索引，避免對執行計畫造成負面影響。
3. 查詢優化原則
◊ 避免對列的操作。
任何對列的操作都可能導致全表掃瞄，這裡所謂的操作包括資料庫函式、計算表示式等，查詢時要盡可能將操作移至等式的右邊，甚至去掉函式。
示例：
select*from
[dbo
].[product
]where
[unitprice]/
10>
3
◊ 避免不必要的型別轉換
◊ 增加查詢的範圍限制，避免全範圍的查詢
◊ 盡量去掉 in、or
◊ 盡量去掉 <>
◊ 去掉where字句中的is null和is not null。where字句中的is null和is not null將不會使用索引而是進行全表搜尋。
◊ like字句盡量前段匹配
◊ 建立基於函式的索引。前面談到任何對列的操作都可能導致全表掃瞄，但是這種查詢在系統中經常需要使用，這時可以建立乙個基於函式的索引。
示例：
createindex ix_productname on
[dbo
].[product
] (convert(varchar(8), [
createdate
], 112))
SQL Server 監控系列（文章索引）
sql server監控在很多時候可以幫助我們了解資料庫做了些什麼，比如誰誰在什麼時候修改了表結構，誰誰在刪除了某個物件，當這些事情發生了，老闆在後面追著說這是誰幹的，如果你找不出元凶，那麼就成為背黑鍋的人了。如果你想更了解什麼時候需要對資料庫做什麼監控，那麼我建議你看看本系列文章 下圖是乙個關於s...
SQL server 索引的設計
盡量避免表掃瞄 檢查你的查詢語句的where子句，因為這是優化器重要關注的地方。包含在where裡面的每一列 column 都是可能的侯選索引，為能達到最優的效能，考慮在下面給出的例子 對於在where子句中給出了column1這個列。下面的兩個條件可以提高索引的優化查詢效能！第一 在表中的colu...
設計模式 系列索引
園子裡面有太多優秀的設計模式文章了，但是可能每個人的出發角度和關注點不同，可能會對每個模式理解的角度和切面不同，我想以我自己理解的方式來跟大家共同 下常用的設計模式，並且我會結合 工作中的開發實際場景來說明每個模式的用法和特點，希望能對大家有所幫助，當然這些內容都是個人在實際專案中的總結和實踐，錯誤...