典型的無限分類,如果欄目實在太多,要避免一次讀取所有欄目。每次只讀需要的。字段多到還沒見什么影響。記錄多才影響速度,做好索引
創新互聯建站-專業網站定制、快速模板網站建設、高性價比秦安網站開發、企業建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式秦安網站制作公司更省心,省錢,快速模板網站建設找我們,業務覆蓋秦安地區。費用合理售后完善,十多年實體公司更值得信賴。
當創建sybase表時不帶索引,則使用堆結構存儲表。可以為表創建一個聚簇索引和多個非聚簇索引。當為表創建聚簇索引時,表中數據以索引中鍵的順序進行物理存儲。對非聚簇索引,sybase只支持b-樹結構。對每個索引,可指定填充因子和每頁必須存儲的行數,可以將單個的表和索引分布到不同的物理設備中去———實際上,可以將非聚簇表的索引頁放在與其數據獨立的物理設備上。也可以劃分表,為表創建多個“頁鏈”。劃分會減少對表的最后一頁的訪問,并允許對大型表操作時用并行i/o。
SQL Server數據庫查詢速度慢的原因有很多,常見的有以下幾種:
1、沒有索引或者沒有用到索引(這是查詢慢最常見的問題,是數據庫設計的缺陷)
2、I/O吞吐量小,形成了瓶頸效應。
3、沒有創建計算列導致查詢不優化。
4、內存不足
5、網絡速度慢
6、查詢出的數據量過大(可以采用多次查詢,其他的方法降低數據量)
7、鎖或者死鎖(這也是查詢慢最常見的問題,是程序設計的缺陷)
8、sp_lock,sp_who,活動的用戶查看,原因是讀寫競爭資源。
9、返回了不必要的行和列
10、查詢語句不好,沒有優化
●可以通過以下方法來優化查詢 :
1、把數據、日志、索引放到不同的I/O設備上,增加讀取速度,以前可以將Tempdb應放在RAID0上,SQL2000不在支持。數據量(尺寸)越大,提高I/O越重要。
2、縱向、橫向分割表,減少表的尺寸(sp_spaceuse)
3、升級硬件
4、根據查詢條件,建立索引,優化索引、優化訪問方式,限制結果集的數據量。注意填充因子要適當(最好是使用默認值0)。索引應該盡量小,使用字節數小的列建索引好(參照索引的創建),不要對有限的幾個值的字段建單一索引如性別字段。
5、提高網速。
6、擴大服務器的內存,Windows 2000和SQL server 2000能支持4-8G的內存。
配置虛擬內存:虛擬內存大小應基于計算機上并發運行的服務進行配置。運行 Microsoft SQL Server? 2000時,可考慮將虛擬內存大小設置為計算機中安裝的物理內存的1.5倍。如果另外安裝了全文檢索功能,并打算運行Microsoft搜索服務以便執行全文索引和查詢,可考慮:將虛擬內存大小配置為至少是計算機中安裝的物理內存的3倍。將SQL Server max server memory服務器配置選項配置為物理內存的1.5倍(虛擬內存大小設置的一半)。
7、增加服務器CPU個數;但是必須 明白并行處理串行處理更需要資源例如內存。使用并行還是串行程是MSSQL自動評估選擇的。單個任務分解成多個任務,就可以在處理器上運行。例如耽擱查詢 的排序、連接、掃描和GROUP BY字句同時執行,SQL SERVER根據系統的負載情況決定最優的并行等級,復雜的需要消耗大量的CPU的查詢最適合并行處理。但是更新操作UPDATE,INSERT, DELETE還不能并行處理。
8、如果是使用like進行查詢的話,簡單的使用index是不行的,但是全文索引,耗空間。 like ''a%'' 使用索引 like ''%a'' 不使用索引用 like ''%a%'' 查詢時,查詢耗時和字段值總長度成正比,所以不能用CHAR類型,而是VARCHAR。對于字段的值很長的建全文索引。
9、DB Server 和APPLication Server 分離;OLTP和OLAP分離
10、分布式分區視圖可用于實現數據庫服務器聯合體。
聯合體是一組分開管理的服務器,但它們相互協作分擔系統的處理負荷。這種通過分區數據形成數據庫服務器聯合體的機制能夠擴大一組服務器,以支持大型的多層 Web 站點的處理需要。有關更多信息,參見設計聯合數據庫服務器。(參照SQL幫助文件''分區視圖'')
a、在實現分區視圖之前,必須先水平分區表
b、 在創建成員表后,在每個成員服務器上定義一個分布式分區視圖,并且每個視圖具有相同的名稱。這樣,引用分布式分區視圖名的查詢可以在任何一個成員服務器上 運行。系統操作如同每個成員服務器上都有一個原始表的復本一樣,但其實每個服務器上只有一個成員表和一個分布式分區視圖。數據的位置對應用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數據和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 設置自動收縮日志.對于大的數據庫不要設置數據庫自動增長,它會降低服務器的性能。
在T-sql的寫法上有很大的講究,下面列出常見的要點:首先,DBMS處理查詢計劃的過程是這樣的:
1、 查詢語句的詞法、語法檢查
2、 將語句提交給DBMS的查詢優化器
3、 優化器做代數優化和存取路徑的優化
4、 由預編譯模塊生成查詢規劃
5、 然后在合適的時間提交給系統處理執行
6、 最后將執行結果返回給用戶。
其次,看一下SQL SERVER的數據存放的結構:一個頁面的大小為8K(8060)字節,8個頁面為一個盤區,按照B樹存放。
一頁,好像一頁是64K吧,插入數據的時候,可能會根據B樹中要求的索引情況不停的調整頁面數據
我一不太會優化,提供你一些優化的方法吧
操作符優化
in 操作符
用in寫出來的sql的優點是比較容易寫及清晰易懂,這比較適合現代軟件開發的風格。
但是用in的sql性能總是比較低的,從oracle執行的步驟來分析用in的sql與不用in的sql有以下區別:
oracle試圖將其轉換成多個表的連接,如果轉換不成功則先執行in里面的子查詢,再查詢外層的表記錄,如果轉換成功則直接采用多個表的連接方式查詢。由此可見用in的sql至少多了一個轉換的過程。一般的sql都可以轉換成功,但對于含有分組統計等方面的sql就不能轉換了。
推薦方案:在業務密集的sql當中盡量不采用in操作符。
not in操作符
此操作是強列推薦不使用的,因為它不能應用表的索引。
推薦方案:用not exists 或(外連接+判斷為空)方案代替
操作符(不等于)
不等于操作符是永遠不會用到索引的,因此對它的處理只會產生全表掃描。
推薦方案:用其它相同功能的操作運算代替,如
a0 改為 a0 or a0
a’’ 改為 a’’
is null 或is not null操作(判斷字段是否為空)
判斷字段是否為空一般是不會應用索引的,因為b樹索引是不索引空值的。
推薦方案:用其它相同功能的操作運算代替,如
a is not null 改為 a0 或a’’等。
不允許字段為空,而用一個缺省值代替空值,如業擴申請中狀態字段不允許為空,缺省為申請。
建立位圖索引(有分區的表不能建,位圖索引比較難控制,如字段值太多索引會使性能下降,多人更新操作會增加數據塊鎖的現象)
及 操作符(大于或小于操作符)
大于或小于操作符一般情況下是不用調整的,因為它有索引就會采用索引查找,但有的情況下可以對它進行優化,如一個表有100萬記錄,一個數值型字段a,30萬記錄的a=0,30萬記錄的a=1,39萬記錄的a=2,1萬記錄的a=3。那么執行a2與a=3的效果就有很大的區別了,因為a2時oracle會先找出為2的記錄索引再進行比較,而a=3時oracle則直接找到=3的記錄索引。
like操作符
like操作符可以應用通配符查詢,里面的通配符組合可能達到幾乎是任意的查詢,但是如果用得不好則會產生性能上的問題,如like ‘%5400%’ 這種查詢不會引用索引,而like ‘x5400%’則會引用范圍索引。一個實際例子:用yw_yhjbqk表中營業編號后面的戶標識號可來查詢營業編號 yy_bh like ‘%5400%’ 這個條件會產生全表掃描,如果改成yy_bh like ’x5400%’ or yy_bh like ’b5400%’ 則會利用yy_bh的索引進行兩個范圍的查詢,性能肯定大大提高。
union操作符
union在進行表鏈接后會篩選掉重復的記錄,所以在表鏈接后會對所產生的結果集進行排序運算,刪除重復的記錄再返回結果。實際大部分應用中是不會產生重復的記錄,最常見的是過程表與歷史表union。如:
select * from gc_dfys
union
select * from ls_jg_dfys
這個sql在運行時先取出兩個表的結果,再用排序空間進行排序刪除重復的記錄,最后返回結果集,如果表數據量大的話可能會導致用磁盤進行排序。
推薦方案:采用union all操作符替代union,因為union all操作只是簡單的將兩個結果合并后就返回。
select * from gc_dfys
union all
select * from ls_jg_dfys
sql語句索引的利用
對條件字段的一些優化
采用函數處理的字段不能利用索引,如:
substr(hbs_bh,1,4)=’5400’,優化處理:hbs_bh like ‘5400%’
trunc(sk_rq)=trunc(sysdate), 優化處理:
sk_rq=trunc(sysdate) and sk_rq
進行了顯式或隱式的運算的字段不能進行索引,如:
ss_df+2050,優化處理:ss_df30
‘x’||hbs_bh’x5400021452’,優化處理:hbs_bh’5400021542’
sk_rq+5=sysdate,優化處理:sk_rq=sysdate-5
hbs_bh=5401002554,優化處理:hbs_bh=’ 5401002554’,注:此條件對hbs_bh 進行隱式的to_number轉換,因為hbs_bh字段是字符型。
條件內包括了多個本表的字段運算時不能進行索引,如:
ys_dfcx_df,無法進行優化
qc_bh||kh_bh=’5400250000’,優化處理:qc_bh=’5400’ and kh_bh=’250000’
應用oracle的hint(提示)處理
提示處理是在oracle產生的sql分析執行路徑不滿意的情況下要用到的。它可以對sql進行以下方面的提示
目標方面的提示:
cost(按成本優化)
rule(按規則優化)
choose(缺省)(oracle自動選擇成本或規則進行優化)
all_rows(所有的行盡快返回)
first_rows(第一行數據盡快返回)
執行方法的提示:
use_nl(使用nested loops方式聯合)
use_merge(使用merge join方式聯合)
use_hash(使用hash join方式聯合)
索引提示:
index(table index)(使用提示的表索引進行查詢)
其它高級提示(如并行處理等等)
oracle的提示功能是比較強的功能,也是比較復雜的應用,并且提示只是給oracle執行的一個建議,有時如果出于成本方面的考慮oracle也可能不會按提示進行。根據實踐應用,一般不建議開發人員應用oracle提示,因為各個數據庫及服務器性能情況不一樣,很可能一個地方性能提升了,但另一個地方卻下降了,oracle在sql執行分析方面已經比較成熟,如果分析執行的路徑不對首先應在數據庫結構(主要是索引)、服務器當前性能(共享內存、磁盤文件碎片)、數據庫對象(表、索引)統計信息是否正確這幾方面分析。
分享文章:sqlserverb樹,sqlserver b樹
文章出自:http://m.newbst.com/article2/dsijooc.html
成都網站建設公司_創新互聯,為您提供品牌網站設計、微信公眾號、微信小程序、搜索引擎優化、全網營銷推廣、網站建設
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯