這是一個典型問題，在網上搜一下就行了。給你搜了一個粘過來看看
1.索引優化
建索引的選擇必須結合SQL查詢、修改、刪除語句的需要，一般的說法是在WHERE里經常出現的欄位建索引。如果在WHERE經常是幾個欄位一起出現而且是用AND連接的，那就應該建這幾個欄位一起的聯合索引，而且次序也需要考慮，一般是最常出現的放前面，重復率低的放前面。
SQL Server提供了一種簡化並自動維護資料庫的工具。這個稱之為資料庫維護計劃向導（Database Maintenance Plan Wizard ，DMPW）的工具也包括了對索引的優化。如果你運行這個向導，你會看到關於資料庫中關於索引的統計量，這些統計量作為日誌工作並定時更新，這樣就減輕了手工重建索引或者DBCC INDEXDEFRAG所帶來的工作量。如果你不想自動定期刷新索引統計量，你還可以在DMPW中選擇重新組織數據和數據頁，這將停止舊有索引並按特定的填充因子重建索引。
2.
改善硬體（雙CPU，Raid 5，增加內存）
tempdb這個臨時資料庫，它對性能的影響較大。tempdb和其他資料庫一樣可以增大，可以縮小。當數據文件需要增長的時候，通常不能保持剩餘部分的連續性。這時文件就會產生碎片，這種碎片會造成性能下降。這種碎片屬於外來性碎片。要阻止在tempdb中產生外來性碎片，必須保證有足夠的硬碟空間。一般將tempdb的容量放到平均使用容量。而你也應該允許tempdb自動增長，比如你有個一個超大的join操作，它建立了一個超過tempdb容量的時候，該查詢將失敗。你還要設置一個合理的單位增長量。因為如果你設得太小，將會產生許多外來性碎片，反而會佔用更多資源。sqlserver調優最有效的做法之一，就是把爭奪資源的操作獨立出去。tempdb就是一個需要獨立出去的部分而tempdb和其他系統庫一樣是公用的，是存取最可能頻繁的庫，所有處理臨時表、子查詢、GROUP BY、排序、DISTINCT、連接等等。它最適合放到一個具有快速讀寫能力的設備上。比如RAID0卷或RAID0+1卷上。
查詢語句一定要使用存儲過程；
3、查詢盡量使用TOP子句
4.將表按一定的約束分成子表,(如按分類)創建約束,在用Like 時,先用分類 and like , 應該可能解決問題. 而且效果立稈見影!(你要確定SQL會認識你建的分區視圖).我一個表有上百萬的記錄(700兆),用分區視圖後,查詢速度基本跟10萬行一樣.
如果還是太慢,還可以考濾分布式分區視圖!這總可以解決問題了吧!
關鍵在於你能否把大表按某種約束分解成子表.
B. SQL連表查詢跟一個個表查詢那個快各有什麼優點和缺點
SQL鏈接表查詢稱為聯合查詢，表查詢是單個查詢。其區別和優點如下：
1．從發展效率的角度看：
聯合查詢是需要多個單查詢邏輯組合才能完成的查詢工作，聯合查詢只需要一個SQL就可以完成查詢工作，即將業務邏輯轉化為SQL，由資料庫來處理，相對來說，開發效率會更高。
2．從查詢效率來看：
單個查詢具有更好的可重用性，因此比聯合查詢更有效。
當讀取或寫入資料庫時，資料庫使用鎖機制來限制其他連接對其進行操作。由於聯邦查詢比單個查詢慢得多，它們會增加鎖爭用，因此單個查詢更好。
3．從邏輯結構層面來看，分層原則
關聯表示業務規則／邏輯。如果經常使用關聯查詢，就會將大量的業務規則和邏輯放入資料庫中執行，這將大大增加CPU、內存、IO等資源的消耗。
4．從資源利用的角度來看
在大多數情況下，並不是所有相關查詢的結果都得到了有效的使用。例如，後台管理的列表界面會顯示分頁、關聯查詢的結果集，只使用當前頁面的數據，而資料庫需要消耗額外的資源才能得到整個結果集。
5．從架構的可伸縮性的角度來看
大量的相關查詢將導致集中式資料庫體系結構難以轉化為分布式體系結構，可擴展性優化也難以實現。關聯查詢方便快捷，開發效率更高。
不使用關系查詢在體系結構級別上有很多優勢，但是它需要大量的系統分析、設計和開發功能。一般在互聯網行業，如用戶數量最好重視這方面。
由於數據量小，兩個查詢的效率基本沒有差別，但在實際應用中，需要根據數據量、業務復雜度等進行綜合評價。
C. sql數據查詢速度過慢的原因多個表連接會導致過慢嗎怎麼優化
資料庫索引的優勢就是針對多表查詢時，能更快速的查出結果，建議你使用索引來做
D. SQLSERVER2005資料庫，使用select語句在列名中嵌套查詢其他錶速度非常慢是什麼原因呢
A表的column1和B表的columna欄位是否有加索引?沒有都話,先把索引加上
因為A表數據量遠大於B表,那麼A表中肯定存在大量數據是在B表中無關聯的,這些無關聯的數據需要查詢嗎?如果不需要,那麼直接用inner join下豈不美哉
E. sql語句多表聯查，查詢速度太慢，超過10s，由於是菜鳥，不知道怎樣優化
確定是菜鳥，sql 寫成這樣 證明你邏輯很清楚啊，建議如果是初學者，代碼規范一定要保持
不知道代碼規范，可以去窗口format一下。。。
言歸正傳 你這個優化的話 可以把
AND p.mediatypeinfoid in (
select
id
from
fn_get_mediatype_infor(5)
)
上面這部分 換成 inner join
F. 如何提高sql資料庫的查詢速度
一、程序中：
1、保證在實現功能的基礎上，盡量減少對資料庫的訪問次數。
2、通過搜索參數，盡量減少對表的訪問行數,最小化結果集，從而減輕網路負擔，能夠分開的操作盡量分襲蔽開處理，提高每次的響應速度。
3、在數據窗口使用SQL時，盡量把使用的索引放在選擇的首列，演算法的結構盡量簡單。
二、避免使用不兼容的數據類型。
例如「float」、「int」、「char」等，都屬於不兼容。 數據類型的不兼容可能使優化器無法執行一些本來可以進行的優化操型態作。
三、盡量避免在Where子句中對欄位進行函數或表達式卜禪源操作，這將導致引擎放棄使用索引而進行全表掃描。
四、盡量使用數字型欄位。
一部分開發人員和資料庫管理人員喜歡把包含數值信息的欄位設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。
G. SQL2000資料庫，如何提高對一個龐大的表的查詢速度
你經常查詢的，經常分組的，經常判斷的
欄位
，必須加
索引
，增加索引後，查詢速度會大幅度提高，但是插入，更新，刪除速度會變慢，總而言之，總有一個慢，你權衡是數據插入，更新，刪除多還是查詢多，決定是否增加索引，非經常查詢欄位就不要增加索引了，以免浪費
數據空間
和增加插入，更新，刪除的時間
另外，如果數據按時間增長，由於你使用的是SQL2000，建議將
大表
拆開每日保存一張
日表
，縮小單張表的大小，在表內查詢就會快很多（因為讀進
內存
的數據小多了），實現分區的功能；如果使用SQL2005，則資料庫可以直接支持分區
這樣就
沒有問題
了，我們這處理的數據每天4000
萬行
，保存了50天數據，查詢起來也只要5分鍾