下面暫從硬體、sql優化、sql server軟體設定、資料壓縮四個方面進行概括：
一、硬體調優
硬體型別劃分：記憶體、cpu、硬碟、網路
通過sql server的「活動監視器」-「最近耗費大量資源的查詢」功能，通過對cpu耗時和執行次數排序，
這裡假設所有語句的併發數與執行時長均合理，以此判定cpu是否滿足生產需求；
拋開記憶體表，只看傳統表在任務執行時記憶體和硬碟的互相讀寫情況，
我們可以通過windows自帶的「效能監視器」——「資料收集器集」功能，甄別記憶體和硬碟是否需要公升級；
再看網路：目前企業內部均使用千兆口，若資料庫需提供互聯業務，此時便需要將公網上下線頻寬考慮進來。
二、sql**的調優
1.避免where子句使用!=和<>操作符，導致放棄使用索引而進行全表掃瞄；
2.避免where子句使用or連線條件，導致放棄使用索引，可改用union all
3.使用like模糊查詢也將導致全表掃瞄；
4.in和not in也需要慎用，同樣會導致全表掃瞄，如：select id from a where num in('a','b','c')
----能用between就不要用in
5.避免where子句中對字段進行表示式操作，這將導致引擎放棄使用索引而全表掃瞄；
6.select id from t where num/2=10, 應該改為select id from t where num=20
7.避免在where子句中對字段進行函式操作，這將導致全表掃瞄；
8.根據「from面積」善用多表連線查詢、巢狀子查詢、相關子查詢；
9.distinct關鍵字，將直接導致查詢降速；
10.判斷表中是否存在資料,善於從多種選擇中挑選效能消耗低的語句
select count(*) from product
select top(1) id from product order by id desc
三、軟體調優
1.條件允許的情況下，可選擇搭建sql server alwayson可用性組實現讀寫分離；
可參考：
2.儲存拆分（分表+分磁碟）
例如：乙個表對應乙個檔案組，乙個檔案組對應多個檔案；
乙個表拆分成多個分割槽表（根據分割槽方案與分割槽函式，例按每100萬條記錄、或按記錄建立時間設定分割槽規則），
最終實現乙個表對應多個分割槽表，乙個分割槽表對應乙個檔案組，乙個檔案組可以對應多個檔案，我們可以將頻繁讀寫的檔案組儲存在高效能磁碟上，對存檔的檔案組還可以設定為唯讀。
四、資料壓縮
1.條件允許的情況下，定期合理清理資料庫日誌；
2.使用dbcc showcontig(tablename) 可直觀的查閱表的 「平均頁密度」，經常執行刪除操作的表平均頁密度越低。
行壓縮--所有數字型別(int、numerica等)和基於數字型別(datetime)將會轉換成可變長度值；
--char和nchar會轉換成可變長度儲存；
頁壓縮--字首壓縮：字首為aabbcc，對應值aabbccdd則替換為6dd；
--字典壓縮：搜尋頁面上任意位置的重複值，不侷限於一列；
行壓縮：alter table testcompression rebuild with (data_compression=row)
頁壓縮：alter table testcompression rebuild with (data_compression=page)
如果有大量重複值或重複字首，建議使用字典字首表；
經常執行刪除操作的表容易造成頁密度調整，增加from面積，建議定期執行資料壓縮，然後執行索引重建。
sql server查詢優化
0 在可以使用and的情況下，盡量不要使用between。1 在可以使用and的情況下，盡量不要使用or。or需要check所有列出的情況。2 在可以使用exists的情況下，避免使用in。exists走index，in不走索引。3 where條件中，如果使用了索引列，盡量不要對該列使用函式，會破壞...
SQLServer 聚集索引優化方案
最近接到客戶提報的問題 無線上傳的資料，伺服器處理速度太慢了，300條資料處理了10分鐘。太誇張了！分析原因發現同事在匯入這個系統時是按照原來專案資料庫生成的指令碼，可是沒有發現這些指令碼都沒有索引。發現這個問題後，我大悅。立馬按照原來的索引生成後給了客戶，客戶反映提高很多！可是用了沒多長時間，同乙...
mysql查詢優化方案
select from table where deleted at and owner id order by status,id desc limit select from table no1 join select id from table where deleted at and own...