Ⅰ 如何優化sqlserver order by
1、整理 或者 重建一下索引
2、order by fbsj desc 裡面的 fbsj 是否可以改成 order by id desc，如果數據邏輯可以的話，建立一個ID 聚集索引 ，在 order by 的時候，聚集索引比 非聚集索引快很多
Ⅱ 資料庫的查詢優化方法分析
盡量不要使用 or 使用or會引起全表掃描 將大大降低查詢效率
alice like % &abigale& % 會使索引不起作用(針對sqlserver)
經過實踐驗證 charindex()並不比前面加%的like更能提高查詢效率 並且charindex()會使索引失去作用（指sqlserver資料庫）
欄位提取要按照 需多少 提多少 的原則 避免 select * 盡量使用 select 欄位 欄位 欄位 實踐證明 每少提取一個欄位 數據的提取速度就會有相應的提升 提升的速度還要看您舍棄的欄位的大小來判斷
order by按聚集索引列排序效率最高 一個sqlserver數據表只能建立一個聚集索引 一般默認為ID 也可以改為其它的欄位
能使用exists和not exists盡量使用 避免使用in或not in
能使用表連接盡量使用 避免使用exists和not exists
SET NOCOUNT ON
正確使用UNION和UNION ALL
慎用SELECT DISTINCT
少用游標
使用表的別名(Alias)
當在SQL語句中連接多個表時 請使用表的別名並把別名前綴於每個Column上 這樣可以減少解析的時間並減少那些由Column歧義引起的語法錯誤
盡量少使用游標
原因很簡單;就是游標的演算法是最原始的計算機演算法(和for if等語句一樣 一條條搜索來算;效率極低);
而sql語句用的是集合運算;速度則快的多;如果用索引速度則很快(用了指針)
創建索引
a 聚集索引:
聚集索引是磁碟存儲和邏輯顯示是一樣的
mssql表的主鍵一般是聚集索引;主鍵(每一條記錄唯一確定);
創建的主鍵自動會是聚集索引;
如有一個非常大的表(有百萬行);很長時間磁碟存儲上會有類似碎片(磁碟填充率效率低;一般是頻繁刪除造成的);
要提高它的性能的最簡潔辦法是:把這個表的主鍵去掉再保存後;然後重新設主鍵再保存;
(這個表就會在磁碟上重新整理排序;性能當然會提高喲)
b 非聚集索引:
非聚集索引是在外面建立小的附加表(一種樹形結構;大多數是B或B+樹);
讀(遍歷select等sql語句)表特快;但寫(update;delete insert等sql語句)表性能會略微下降
針對數據量大的表建議非聚集索引不要超過 個(節省額外磁碟負擔)
不要給類似 性別 列創建索引
死鎖:
是指有線程在讀一條記錄;別的線程讀這條記錄就要等待;
在mssql中只要長期占那條記錄的線程去掉;死鎖就會解除
在mssql中鎖是針對每一行記錄(所以性能不錯)
經常產生鎖的原因有:
a 在sql語句中使用事務語句(特別是事務中當查詢比較耗時)
b 在前台的應用程序的connetion沖突(未關閉)
c 多表聯合查詢(尤其是在打開大的數據集時)
sql語句優化
a is null not or in 不會用索引
b 避免在索引列上使用計算或函數處理(索引會大失性能) 還有 % ;有的甚至會全失索引性能
c SELECT中避免使用 * (寧可把需要欄位列出來;而不要用*去把所有的欄位都列出來)
d 避免相關子查詢(select中套select)
e where的條件中 =＞exists＞in (指性能)
f order by group by having distinct 等語句要慎用(因為它們效率不高;它們是先把數據到臨時表中再進行處理的)
g 聚集索引如有 個欄位組成(tt 和tt );tt 在前面;where的條件中如只用tt 欄位來判斷;就會用到一半的聚集索引;
where的條件中如tt 和tt 欄位都用來判斷了;就會全用到聚集索引;
where的條件中如只用tt 欄位來判斷;就會用不到聚集索引了;
盡量不要使用TEXT數據類型
除非你使用TEXT處理一個很大的數據 否則不要使用它 因為它不易於查詢 速度慢 用的不好還會浪費大量的空間
一般的 VARCHAR可以更好的處理你的數據
盡量不要使用臨時表
盡量不要使用臨時表 除非你必須這樣做 一般使用子查詢可以代替臨時表 使用臨時表會帶來系統開銷
如果前台的代碼你是使用資料庫連接池而臨時表卻自始至終都存在 SQL Server提供了一些替代方案 比如Table數據類型
盡量少使用外鍵和觸發器
因為在mssql中這些功能的性能做得不是很好;隨便動一下表(它就會到相關的表去搞判斷;有很多情況並不需要);在後台消耗資源大
lishixin/Article/program/Oracle/201311/16744
Ⅲ 關於SQLServer 2000 索引問題
沒法解決！
每日寫入10萬左右，1d=24H=24*60m=24*60*60s=86400s 這才8萬多條記錄，每秒鍾至少寫入一條記錄，這個已經不是關系庫可以承受的了。
你該跟領導說明情況，讓他知道還有個「實時資料庫」，這個才是解決辦法。
如PI、eDNA等實時庫才是能承受。
別說sql2000性能不好，就算用oracle11r2也不成。
如果非得用關系庫，那就考慮分表吧。
例如：主鍵一般都是有含義的，如 年份+序號，字母+序號..按照某一規律進行分表，然後將各分表連接做成一個視圖。
Ⅳ SQL資料庫容量大，查詢速度慢，有何解決方案
首先應該確定是誰慢的，往往是程序處理方面的問題而不是資料庫的問題。
程序方面應該盡可能的減少數據查詢返回的內容，比如可以查詢返回ID，然後再根據ID一條一條的查詢具體內容，看似慢了，在數據量達的時候快很多
對於數據可以參照下面幾點
1、優化SQL語句，SQL語句對查詢速度影響最大
2、對於經常查詢的欄位作索引。但是這樣會增加修改時的壓力
4、優化SQLServer，比如給其分配固定的內存，預先分配查詢內存，調整CPU使用率等。
5、優化硬體資源，比如使用更高的伺服器或者硬碟，獨立安排資料庫的數據文件和索引文件，將數據文件分布於不同的物理硬碟上等等
6、考慮使用分布資料庫或者對大表進行拆分
另外，2G的資料庫應該不算很大了，我處理過18G的資料庫，8000萬條記錄，查詢速度可以被接受
Ⅳ 淺談如何優化SQL Server伺服器
數據和日誌文件分開存放在不同磁碟上
數據文件和日誌文件的操作會產生大量的I/O 在可能的條件下 日誌文件應該存放在一個與數據和索引所在的數據文件不同的硬碟上以分散I/O 同時還有利於資料庫的災難恢復
tempdb資料庫單獨存放在不同磁碟上
tempdb資料庫是其他所有資料庫都有可能使用的臨時資料庫 當使用select into 在沒建立索引的列上執行Orderby時就會在tempdb資料庫中產生臨時表來存儲中間數據 由於建立和填充臨時表會嚴重降低系統性能 所以在盡可能的情況下應該為要排序的列建立索引 同時 tempdb資料庫是為所有的用戶和應用程序共享 所以如果一個用戶占據了tempdb資料庫的所有空間 則其他資料庫將不能再使用 在可能的情況下 tempdb資料庫應該單獨放置在一個速度更快的硬碟或者RAID陣列上 分離tempdb資料庫的I/O操作以加快性能 tempdb資料庫應該有適當的容量 以滿足用戶的需要 應該允許tempdb資料庫的空間自動增長 如果設置為不允許自動增長 當查詢操作建立了超過tempdb資料庫容量的臨時表時 操作將無法完成
適當設置tempdb資料庫的增長幅度 過小的增長幅度會產生更多的外部碎片 會佔用更多的資源
避免熱點數據的發生
在SQLServer 之前 對於沒有聚集索引的表（堆集表） 新插入的數據行總是放置在磁碟中表的物理結尾處 如果並發的用戶很多 同時在對表執行插入或者更新數據的操作 這將使得十分繁忙的表的末尾有可能產生數據熱點 並發的I/O操作集中對少數頁面進行操作 將導致資料庫性能的下降
在SQLServer中 新的數據行的物理存儲空間的分配是通過PFS頁面來進行的 PFS頁面的管理演算法將插入操作進行分散來盡量避免產生數據熱點
在設計應用系統和資料庫時 要避免在自然增長的列上建立主鍵 這樣有可能導致熱點數據的發生
數據類型要少
在設計表時 盡可能少用數據類型 這樣一個數據頁面上可以保存最多的信息 數據頁面就少 檢索數據頁面的I/O操作就少 所以效率會高
監控和整理空間碎片
文件空間的自動增長提高了自動管理性 但可能導致空間碎片 物理空間與數據的邏輯空間不再連續 定期的監控和空間碎片整理有利於提高I/O性能
使用主數據文件和次要數據文件
每個資料庫的一個主數據文件屬於主文件組 對於 GB左右規模的資料庫 一個數據文件就夠了 如果有次要數據文件 主數據文件中有管理次要數據文件的指針
採用多個數據文件時 主數據文件用於存儲系統對象和表 次要數據文件用於存儲用戶數據和索引 在可能的情況下 主數據文件和次要數據文件可以單獨存放在不同的磁碟上以分散I/O
如果採用多個數據文件 推薦主數據文件存儲系統數據 次要數據文件存放用戶數據和索引 這樣會有助於提高I/O性能
利用文件組改善性能
在大型資料庫系統中 可以考慮建立文件組來管理數據文件 將表和索引通過存放在不同的物理磁碟上進行性能監控比較 最後得出優化的存儲方案
重視自動增長和自動收縮可能導致的性能問題
資料庫文件的自動增長和自動收縮功能對於小型資料庫的管理十分有用 但可能導致大型資料庫的性能問題 因為文件的自然增長的同時會導致存儲碎片的發生 當文件空間變大時 新分配的空間不一定和原來的空間連續 當文件空間收縮時 釋放了部分空間 然而當文件又需要增長存儲空間卻不能利用原先釋放的空間 也會導致碎片的發生
分離系統數據和用戶數據
將系統資料庫和用戶資料庫分開存放在不同的物理磁碟上有助於改善I/O性能 有助於資料庫備份和恢復
優化索引設計
索引的設計對資料庫的性能十分重要 具體不再闡述 可參見本博相關文章
定期更新統計信息
SQLServer默認使用基於代價的優化 所以統計信息的及時更新對於查詢優化十分重要
定期的一致性檢查
lishixin/Article/program/SQLServer/201311/22434
Ⅵ 如何利用索引提高SQLServer數據處理的效率
在良好的資料庫設計基礎上，能有效地使用索引是SQL Server取得高性能的基礎，SQL Server採用基於代價的優化模型，它對每一個提交的有關表的查詢，決定是否使用索引或用哪一個索引。因為查詢執行的大部分開銷是磁碟I/O，使用索引提高性能的一個主要目標是避免全表掃描，因為全表掃描需要從磁碟上讀表的每一個數據頁，如果有索引指向數據值，則查詢只需讀幾次磁碟就可以了。
所以如果建立了合理的索引，優化器就能利用索引加速數據的查詢過程。但是，索引並不總是提高系統的性能，在增、刪、改操作中索引的存在會增加一定的工作量，因此，在適當的地方增加適當的索引並從不合理的地方刪除次優的索引，將有助於優化那些性能較差的SQL Server應用。實踐表明，合理的索引設計是建立在對各種查詢的分析和預測上的，只有正確地使索引與程序結合起來,才能產生最佳的優化方案。本文就SQL Server索引的性能問題進行了一些分析和實踐。
一、聚簇索引(clustered indexes)的使用
聚簇索引是一種對磁碟上實際數據重新組織以按指定的一個或多個列的值排序。由於聚簇索引的索引頁面指針指向數據頁面，所以使用聚簇索引查找數據幾乎總是比使用非聚簇索引快。每張表只能建一個聚簇索引，並且建聚簇索引需要至少相當該表120%的附加空間，以存放該表的副本和索引中間頁。建立聚簇索引的思想是：
1、大多數表都應該有聚簇索引或使用分區來降低對表尾頁的競爭，在一個高事務的環境中，對最後一頁的封鎖嚴重影響系統的吞吐量。
2、在聚簇索引下，數據在物理上按順序排在數據頁上，重復值也排在一起，因而在那些包含范圍檢查(between、<、<=、>、>=)或使用group by或order by的查詢時，一旦找到具有范圍中第一個鍵值的行，具有後續索引值的行保證物理上毗連在一起而不必進一步搜索，避免了大范圍掃描，可以大大提高查詢速度。
3、在一個頻繁發生插入操作的表上建立聚簇索引時，不要建在具有單調上升值的列(如IDENTITY)上，否則會經常引起封鎖沖突。
4、在聚簇索引中不要包含經常修改的列，因為碼值修改後，數據行必須移動到新的位置。
5、選擇聚簇索引應基於where子句和連接操作的類型。
聚簇索引的侯選列是：
1、主鍵列,該列在where子句中使用並且插入是隨機的。
2、按范圍存取的列，如pri_order > 100 and pri_order < 200。
3、在group by或order by中使用的列。
4、不經常修改的列。
5、在連接操作中使用的列。
二、非聚簇索引(nonclustered indexes)的使用
SQL Server預設情況下建立的索引是非聚簇索引，由於非聚簇索引不重新組織表中的數據，而是對每一行存儲索引列值並用一個指針指向數據所在的頁面。換句話說非聚簇索引具有在索引結構和數據本身之間的一個額外級。一個表如果沒有聚簇索引時,可有250個非聚簇索引。每個非聚簇索引提供訪問數據的不同排序順序。在建立非聚簇索引時，要權衡索引對查詢速度的加快與降低修改速度之間的利弊。另外，還要考慮這些問題：
1、索引需要使用多少空間。
2、合適的列是否穩定。
3、索引鍵是如何選擇的，掃描效果是否更佳。
4、是否有許多重復值。
對更新頻繁的表來說，表上的非聚簇索引比聚簇索引和根本沒有索引需要更多的額外開銷。對移到新頁的每一行而言，指向該數據的每個非聚簇索引的頁級行也必須更新，有時可能還需要索引頁的分理。從一個頁面刪除數據的進程也會有類似的開銷，另外，刪除進程還必須把數據移到頁面上部，以保證數據的連續性。所以，建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情況：
1、某列常用於集合函數(如Sum,....)。
2、某列常用於join,order by,group by。
3、查尋出的數據不超過表中數據量的20%。
三、覆蓋索引(covering indexes)的使用
覆蓋索引是指那些索引項中包含查尋所需要的全部信息的非聚簇索引，這種索引之所以比較快也正是因為索引頁中包含了查尋所必須的數據,不需去訪問數據頁。如果非聚簇索引中包含結果數據,那麼它的查詢速度將快於聚簇索引。
但是由於覆蓋索引的索引項比較多,要佔用比較大的空間。而且update操作會引起索引值改變。所以如果潛在的覆蓋查詢並不常用或不太關鍵，則覆蓋索引的增加反而會降低性能。
四、索引的選擇技術
p_detail是住房公積金管理系統中記錄個人明細的表，有890000行，觀察在不同索引下的查詢運行效果，測試在C/S環境下進行，客戶機是IBM PII350(內存64M),伺服器是DEC Alpha1000A(內存128M),資料庫為SYBASE11.0.3。
1、 select count(*) from p_detail where
op_date>』19990101』 and op_date<』
19991231』 and pri_surplus1>300
2、 select count(*),sum(pri_surplus1) from p_detail
where op_date>』19990101』 and
pay_month between『199908』 and』199912』
不建任何索引查詢1 1分15秒
查詢2 1分7秒
在op_date上建非聚簇索引查詢1 57秒
查詢2 57秒
在op_date上建聚簇索引查詢1 <1秒
查詢2 52秒
在pay_month、op_date、pri_surplus1上建索引查詢1 34秒
查詢2 <1秒
在op_date、pay_month、pri_surplus1上建索引查詢1 <1秒
查詢2 <1秒
從以上查詢效果分析，索引的有無，建立方式的不同將會導致不同的查詢效果，選擇什麼樣的索引基於用戶對數據的查詢條件,這些條件體現於where從句和join表達式中。一般來說建立索引的思路是：
(1)主鍵時常作為where子句的條件，應在表的主鍵列上建立聚簇索引，尤其當經常用它作為連接的時候。
(2)有大量重復值且經常有范圍查詢和排序、分組發生的列，或者非常頻繁地被訪問的列，可考慮建立聚簇索引。
(3)經常同時存取多列，且每列都含有重復值可考慮建立復合索引來覆蓋一個或一組查詢，並把查詢引用最頻繁的列作為前導列，如果可能盡量使關鍵查詢形成覆蓋查詢。
(4)如果知道索引鍵的所有值都是唯一的，那麼確保把索引定義成唯一索引。
(5)在一個經常做插入操作的表上建索引時，使用fillfactor(填充因子)來減少頁分裂，同時提高並發度降低死鎖的發生。如果在只讀表上建索引，則可以把fillfactor置為100。
(6)在選擇索引鍵時，設法選擇那些採用小數據類型的列作為鍵以使每個索引頁能夠容納盡可能多的索引鍵和指針，通過這種方式，可使一個查詢必須遍歷的索引頁面降到最小。此外，盡可能地使用整數為鍵值，因為它能夠提供比任何數據類型都快的訪問速度。
五、索引的維護
上面講到,某些不合適的索引影響到SQL Server的性能,隨著應用系統的運行,數據不斷地發生變化,當數據變化達到某一個程度時將會影響到索引的使用。這時需要用戶自己來維護索引。索引的維護包括：
1、重建索引
隨著數據行的插入、刪除和數據頁的分裂，有些索引頁可能只包含幾頁數據，另外應用在執行大塊I/O的時候，重建非聚簇索引可以降低分片，維護大塊I/O的效率。重建索引實際上是重新組織B-樹空間。在下面情況下需要重建索引：
(1)數據和使用模式大幅度變化。
(2)排序的順序發生改變。
(3)要進行大量插入操作或已經完成。
(4)使用大塊I/O的查詢的磁碟讀次數比預料的要多。
(5)由於大量數據修改，使得數據頁和索引頁沒有充分使用而導致空間的使用超出估算。
(6)dbcc檢查出索引有問題。
當重建聚簇索引時，這張表的所有非聚簇索引將被重建。
2、索引統計信息的更新
當在一個包含數據的表上創建索引的時候，SQL Server會創建分布數據頁來存放有關索引的兩種統計信息：分布表和密度表。優化器利用這個頁來判斷該索引對某個特定查詢是否有用。但這個統計信息並不動態地重新計算。這意味著，當表的數據改變之後，統計信息有可能是過時的，從而影響優化器追求最有工作的目標。因此，在下面情況下應該運行update statistics命令：
(1)數據行的插入和刪除修改了數據的分布。
(2)對用truncate table刪除數據的表上增加數據行。
(3)修改索引列的值。
六、結束語
實踐表明，不恰當的索引不但於事無補，反而會降低系統的執行性能。因為大量的索引在插入、修改和刪除操作時比沒有索引花費更多的系統時間。例如下面情況下建立的索引是不恰當的：
1、在查詢中很少或從不引用的列不會受益於索引，因為索引很少或從來不必搜索基於這些列的行。
2、只有兩個或三個值的列，如男性和女性(是或否)，從不會從索引中得到好處。
另外，鑒於索引加快了查詢速度，但減慢了數據更新速度的特點。可通過在一個段上建表，而在另一個段上建其非聚簇索引，而這兩段分別在單獨的物理設備上來改善操作性能。
Ⅶ 如何做SqlServer 數據查詢優化！
一、建立索引
二、建立存儲過程
三、只查詢您所需要的數據，不要把所有數據都查詢出來，防止數據冗餘。
四、對於大量及海量數據一般還要建立分區
Ⅷ 如何查表是否有索引 sqlserver
1、本文以表pi_content為例，相應的欄位為（[piid] int, [seqnum] int,[phname] nvarchar(50),[content] nvarchar(MAX)），數據量為百萬級。
Ⅸ sqlserver中這樣的欄位用什麼索引比較好
1、關於索引：數據量不是特別大的情況下，建議不要用索引。因為索引本身也是一種數據，隨著數據的變化，系統也需要維護索引的變動，這需要開銷。不僅僅是空間上的開銷，還有處理時間的開銷。根據經驗，在SQL Server類型的數據表上，如果數據只有幾萬條，不建索引，讓系統全表掃描，並不會比有索引慢多少，有時甚至更快。
2、索引的類別：索引有唯一索引和非唯一索引，還有你說的聚集與非聚集。唯一索引顧名思義，就是該索引欄位所有的值不能重復。對於非唯一索引，允許索引欄位為空。想來聚集的意思你也是懂的了。在一個表上，只能有一個聚集索引。一般聚集索引建立在主鍵上比較好。根據經驗，聚集對數據訪問性能的改善很有限，考慮到聚集對數據變動的性能影響，有時候不建聚集索引，使用唯一索引是非常不錯的選擇。
3、關於你這個表，要看username是個什麼屬性的欄位。根據上述，如果你的數據只有幾千條，沒必要在這個欄位上使用索引。如果數據量上十萬，且是唯一值，最多建一個唯一索引即可。可以自己觀察一下，有索引、與沒有的時候，性能究竟如何。
Ⅹ 如何提高SQL Server大數據條件下的查詢速度
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萬行一樣.
如果還是太慢,還可以考濾分布式分區視圖!這總可以解決問題了吧!
關鍵在於你能否把大表按某種約束分解成子表.