优化数据库的思想：
優化數據庫的思想： ?
? ================ ?
? 1、關鍵字段建立索引。 ?
? 2、使用存儲過程，它使SQL變得更加靈活和高效。 ?
? 3、備份數據庫和清除垃圾數據。 ?
? 4、SQL語句語法的優化。（可以用Sybase的SQL ? Expert，可惜我沒找到unexpired的 ?
? 序列號） ?
? 5、清理刪除日志。 ?
? ?
? SQL語句優化的原則： ?
? ================== ?
? 1、使用索引來更快地遍歷表。 ?
? ? ? ? 缺省情況下建立的索引是非群集索引，但有時它并不是最佳的。在非群集索引 ?
? 下，數據在物理上隨機存放在數據頁上。合理的索引設計要建立在 ?
? 對各種查詢的分析和預測上。一般來說：①.有大量重復值、且經常有范圍查詢 ?
? （between, ? > ? ,< ? ? ，> ? =,< ? ? =）和order ? by、group ? by發生的列，可考 ?
? 慮建立群集索引；②.經常同時存取多列，且每列都含有重復值可考慮建立組合索引 ?
? ；③.組合索引要盡量使關鍵查詢形成索引覆蓋，其前導列一定 ?
? 是使用最頻繁的列。索引雖有助于提高性能但不是索引越多越好，恰好相反過多的索 ?
? 引會導致系統低效。用戶在表中每加進一個索引，維護索引集 ?
? 合就要做相應的更新工作。 ?
? 2、IS ? NULL ? 與 ? IS ? NOT ? NULL ?
? ? ? ? 不能用null作索引，任何包含null值的列都將不會被包含在索引中。即使索引有 ?
? 多列這樣的情況下，只要這些列中有一列含有null，該列就會從 ?
? 索引中排除。也就是說如果某列存在空值，即使對該列建索引也不會提高性能。任何 ?
? 在where子句中使用is ? null或is ? not ? null的語句優化器是不允 ?
? 許使用索引的。 ?
? 3、IN和EXISTS ?
? ? ? ? EXISTS要遠比IN的效率高。里面關系到full ? table ? scan和range ? scan。幾乎將所 ?
? 有的IN操作符子查詢改寫為使用EXISTS的子查詢。 ?
? 4、在海量查詢時盡量少用格式轉換。 ?
? 5、當在SQL ? SERVER ? 2000中，如果存儲過程只有一個參數，并且是OUTPUT類型的，必 ?
? 須在調用這個存儲過程的時候給這個參數一個初始的值，否則 ?
? 會出現調用錯誤。 ?
? 6、ORDER ? BY和GROPU ? BY ?
? ? ? ? 使用ORDER ? BY和GROUP ? BY短語，任何一種索引都有助于SELECT的性能提高。注意 ?
? 如果索引列里面有NULL值，Optimizer將無法優化。 ?
? 7、任何對列的操作都將導致表掃描，它包括數據庫函數、計算表達式等等，查詢時 ?
? 要盡可能將操作移至等號右邊。 ?
? 8、IN、OR子句常會使用工作表，使索引失效。如果不產生大量重復值，可以考慮把 ?
? 子句拆開。拆開的子句中應該包含索引。 ?
? 9、SET ? SHOWPLAN_ALL ? ON ? 查看執行方案。DBCC檢查數據庫數據完整性。 ?
? DBCC(DataBase ? Consistency ? Checker）是一組用于驗證 ? SQL ? Server ? 數據 ?
? 庫完整性的程序。 ?
? 10、慎用游標 ?
? ? ? ? 在某些必須使用游標的場合，可考慮將符合條件的數據行轉入臨時表中，再對臨 ?
? 時表定義游標進行操作，這樣可使性能得到明顯提高。 ?
? 總結：所謂優化即WHERE子句利用了索引，不可優化即發生了表掃描或額外開銷。經 ?
? 驗顯示，SQL ? Server性能的最大改進得益于邏輯的數據庫設計、 ?
? 索引設計和查詢設計方面。反過來說，最大的性能問題常常是由其中這些相同方面中 ?
? 的不足引起的。其實SQL優化的實質就是在結果正確的前提下， ?
? 用優化器可以識別的語句，充份利用索引，減少表掃描的I/O次數，盡量避免表搜索 ?
? 的發生。其實SQL的性能優化是一個復雜的過程，上述這些只是 ?
? 在應用層次的一種體現，深入研究還會涉及數據庫層的資源配置、網絡層的流量控制 ?
? 以及操作系統層的總體設計。Top
2 樓CrazyFor（冬眠的鼴鼠）回復于 2003-12-02 22:04:28 得分 0
?
? ?
? SQL ? Server中有幾個可以讓你檢測、調整和優化SQL ? Server性能的工具。在本文中，我將說明如何用SQL ? Server的工具來優化數據庫索引的使用，本文還涉及到有關索引的一般性知識。 ?
? ?
? 關于索引的常識 ?
? ? ? ?
? 影響到數據庫性能的最大因素就是索引。由于該問題的復雜性，我只可能簡單的談談這個問題，不過關于這方面的問題，目前有好幾本不錯的書籍可供你參閱。我在這里只討論兩種SQL ? Server索引，即clustered索引和nonclustered索引。當考察建立什么類型的索引時，你應當考慮數據類型和保存這些數據的column。同樣，你也必須考慮數據庫可能用到的查詢類型以及使用的最為頻繁的查詢類型。 ?
? ?
? 索引的類型 ?
? ?
? 如果column保存了高度相關的數據，并且常常被順序訪問時，最好使用clustered索引，這是因為如果使用clustered索引，SQL ? Server會在物理上按升序（默認）或者降序重排數據列，這樣就可以迅速的找到被查詢的數據。同樣，在搜尋控制在一定范圍內的情況下，對這些column也最好使用clustered索引。這是因為由于物理上重排數據，每個表格上只有一個clustered索引。 ?
? ?
? 與上面情況相反，如果columns包含的數據相關性較差，你可以使用nonculstered索引。你可以在一個表格中使用高達249個nonclustered索引——盡管我想象不出實際應用場合會用的上這么多索引。 ?
? ?
? 當表格使用主關鍵字（primary ? keys），默認情況下SQL ? Server會自動對包含該關鍵字的column(s)建立一個獨有的cluster索引。很顯然，對這些column(s)建立獨有索引意味著主關鍵字的唯一性。當建立外關鍵字（foreign ? key）關系時，如果你打算頻繁使用它，那么在外關鍵字cloumn上建立nonclustered索引不失為一個好的方法。如果表格有clustered索引，那么它用一個鏈表來維護數據頁之間的關系。相反，如果表格沒有clustered索引，SQL ? Server將在一個堆棧中保存數據頁。 ?
? ?
? 數據頁 ?
? ?
? 當索引建立起來的時候，SQLServer就建立數據頁（datapage），數據頁是用以加速搜索的指針。當索引建立起來的時候，其對應的填充因子也即被設置。設置填充因子的目的是為了指示該索引中數據頁的百分比。隨著時間的推移，數據庫的更新會消耗掉已有的空閑空間，這就會導致頁被拆分。頁拆分的后果是降低了索引的性能，因而使用該索引的查詢會導致數據存儲的支離破碎。當建立一個索引時，該索引的填充因子即被設置好了，因此填充因子不能動態維護。 ?
? ?
? 為了更新數據頁中的填充因子，我們可以停止舊有索引并重建索引，并重新設置填充因子（注意：這將影響到當前數據庫的運行，在重要場合請謹慎使用）。DBCC ? INDEXDEFRAG和DBCC ? DBREINDEX是清除clustered和nonculstered索引碎片的兩個命令。INDEXDEFRAG是一種在線操作（也就是說，它不會阻塞其它表格動作，如查詢），而DBREINDEX則在物理上重建索引。在絕大多數情況下，重建索引可以更好的消除碎片，但是這個優點是以阻塞當前發生在該索引所在表格上其它動作為代價換取來得。當出現較大的碎片索引時，INDEXDEFRAG會花上一段比較長的時間，這是因為該命令的運行是基于小的交互塊（transactional ? block）。 ?
? ?
? 填充因子 ?
? ?
? 當你執行上述措施中的任何一個，數據庫引擎可以更有效的返回編入索引的數據。關于填充因子（fillfactor）話題已經超出了本文的范疇，不過我還是提醒你需要注意那些打算使用填充因子建立索引的表格。 ?
? ?
? 在執行查詢時，SQL ? Server動態選擇使用哪個索引。為此，SQL ? Server根據每個索引上分布在該關鍵字上的統計量來決定使用哪個索引。值得注意的是，經過日常的數據庫活動（如插入、刪除和更新表格），SQL ? Server用到的這些統計量可能已經“過期”了，需要更新。你可以通過執行DBCC ? SHOWCONTIG來查看統計量的狀態。當你認為統計量已經“過期”時，你可以執行該表格的UPDATE ? STATISTICS命令，這樣SQL ? Server就刷新了關于該索引的信息了。 ?
? ?
? 建立數據庫維護計劃 ?
? ?
? SQL ? Server提供了一種簡化并自動維護數據庫的工具。這個稱之為數據庫維護計劃向導（Database ? Maintenance ? Plan ? Wizard ? ，DMPW）的工具也包括了對索引的優化。如果你運行這個向導，你會看到關于數據庫中關于索引的統計量，這些統計量作為日志工作并定時更新，這樣就減輕了手工重建索引所帶來的工作量。如果你不想自動定期刷新索引統計量，你還可以在DMPW中選擇重新組織數據和數據頁，這將停止舊有索引并按特定的填充因子重建索引。 ? ?
? Top
3 樓txlicenhe（馬可）回復于 2003-12-02 22:57:39 得分 0
http://expert.csdn.net/Expert/topic/2455/2455540.xml?temp=.9766046 ?
? SQL ? 調優 ?
? 大力Top
4 樓txlicenhe（馬可）回復于 2003-12-02 22:58:32 得分 0
/***************************************** ?
? 如何讓你的SQL運行得更快(轉貼) ? ?
? ---- ? 人們在使用SQL時往往會陷入一個誤區，即太關注于所得的結果是否正確，而忽略 ?
? 了不同的實現方法之間可能存在的性能差異，這種性能差異在大型的或是復雜的數據庫 ?
? 環境中（如聯機事務處理OLTP或決策支持系統DSS）中表現得尤為明顯。筆者在工作實踐 ?
? 中發現，不良的SQL往往來自于不恰當的索引設計、不充份的連接條件和不可優化的whe ?
? re子句。在對它們進行適當的優化后，其運行速度有了明顯地提高！下面我將從這三個 ?
? 方面分別進行總結： ?
? ---- ? 為了更直觀地說明問題，所有實例中的SQL運行時間均經過測試，不超過１秒的均 ?
? 表示為（< ? 1秒）。 ?
? ---- ? 測試環境-- ?
? ---- ? 主機：HP ? LH ? II ?
? ---- ? 主頻：330MHZ ?
? ---- ? 內存：128兆 ?
? ---- ? 操作系統：Operserver5.0.4 ?
? ----數據庫：Sybase11.0.3 ?
? 一、不合理的索引設計 ?
? ----例：表record有620000行，試看在不同的索引下，下面幾個 ? SQL的運行情況： ?
? ---- ? 1.在date上建有一非個群集索引 ?
? select ? count(*) ? from ? record ? where ? date ? > ?
? '19991201' ? and ? date ? < ? '19991214'and ? amount ? > ?
? 2000 ? (25秒) ?
? select ? date,sum(amount) ? from ? record ? group ? by ? date ?
? (55秒) ?
? select ? count(*) ? from ? record ? where ? date ? > ?
? '19990901' ? and ? place ? in ? ('BJ','SH') ? (27秒) ?
? ---- ? 分析： ?
? ----date上有大量的重復值，在非群集索引下，數據在物理上隨機存放在數據頁上，在 ?
? 范圍查找時，必須執行一次表掃描才能找到這一范圍內的全部行。 ?
? ---- ? 2.在date上的一個群集索引 ?
? select ? count(*) ? from ? record ? where ? date ? > ?
? '19991201' ? and ? date ? < ? '19991214' ? and ? amount ? > ?
? 2000 ? （14秒） ?
? select ? date,sum(amount) ? from ? record ? group ? by ? date ?
? （28秒） ?
? select ? count(*) ? from ? record ? where ? date ? > ?
? '19990901' ? and ? place ? in ? ('BJ','SH')（14秒） ?
? ---- ? 分析： ?
? ---- ? 在群集索引下，數據在物理上按順序在數據頁上，重復值也排列在一起，因而在范 ?
? 圍查找時，可以先找到這個范圍的起末點，且只在這個范圍內掃描數據頁，避免了大范 ?
? 圍掃描，提高了查詢速度。 ?
? ---- ? 3.在place，date，amount上的組合索引 ?
? select ? count(*) ? from ? record ? where ? date ? > ?
? '19991201' ? and ? date ? < ? '19991214' ? and ? amount ? > ?
? 2000 ? （26秒） ?
? select ? date,sum(amount) ? from ? record ? group ? by ? date ?
? （27秒） ?
? select ? count(*) ? from ? record ? where ? date ? > ?
? '19990901' ? and ? place ? in ? ('BJ, ? 'SH')（< ? 1秒） ?
? ---- ? 分析： ?
? ---- ? 這是一個不很合理的組合索引，因為它的前導列是place，第一和第二條SQL沒有引 ?
? 用place，因此也沒有利用上索引；第三個SQL使用了place，且引用的所有列都包含在組 ?
? 合索引中，形成了索引覆蓋，所以它的速度是非常快的。 ?
? ---- ? 4.在date，place，amount上的組合索引 ?
? select ? count(*) ? from ? record ? where ? date ? > ?
? '19991201' ? and ? date ? < ? '19991214' ? and ? amount ? > ?
? 2000(< ? 1秒) ?
? select ? date,sum(amount) ? from ? record ? group ? by ? date ?
? （11秒） ?
? select ? count(*) ? from ? record ? where ? date ? > ?
? '19990901' ? and ? place ? in ? ('BJ','SH')（< ? 1秒） ?
? ---- ? 分析： ?
? ---- ? 這是一個合理的組合索引。它將date作為前導列，使每個SQL都可以利用索引，并 ?
? 且在第一和第三個SQL中形成了索引覆蓋，因而性能達到了最優。 ?
? ---- ? 5.總結： ?
? ---- ? 缺省情況下建立的索引是非群集索引，但有時它并不是最佳的；合理的索引設計要 ?
? 建立在對各種查詢的分析和預測上。一般來說： ?
? ---- ? ①.有大量重復值、且經常有范圍查詢 ?
? （between, ? >,< ? ，>=,< ? =）和order ? by ?
? 、group ? by發生的列，可考慮建立群集索引； ?
? ---- ? ②.經常同時存取多列，且每列都含有重復值可考慮建立組合索引； ?
? ---- ? ③.組合索引要盡量使關鍵查詢形成索引覆蓋，其前導列一定是使用最頻繁的列。 ?
? ?
? 二、不充份的連接條件： ?
? ---- ? 例：表card有7896行，在card_no上有一個非聚集索引，表account有191122行，在 ?
? account_no上有一個非聚集索引，試看在不同的表連接條件下，兩個SQL的執行情況： ?
? ?
? select ? sum(a.amount) ? from ? account ? a, ?
? card ? b ? where ? a.card_no ? = ? b.card_no（20秒） ?
? ---- ? 將SQL改為： ?
? select ? sum(a.amount) ? from ? account ? a, ?
? card ? b ? where ? a.card_no ? = ? b.card_no ? and ? a. ?
? account_no=b.account_no（< ? 1秒） ?
? ---- ? 分析： ?
? ---- ? 在第一個連接條件下，最佳查詢方案是將account作外層表，card作內層表，利用 ?
? card上的索引，其I/O次數可由以下公式估算為： ?
? ---- ? 外層表account上的22541頁+（外層表account的191122行*內層表card上對應外層 ?
? 表第一行所要查找的3頁）=595907次I/O ?
? ---- ? 在第二個連接條件下，最佳查詢方案是將card作外層表，account作內層表，利用 ?
? account上的索引，其I/O次數可由以下公式估算為： ?
? ---- ? 外層表card上的1944頁+（外層表card的7896行*內層表account上對應外層表每一 ?
? 行所要查找的4頁）= ? 33528次I/O ?
? ---- ? 可見，只有充份的連接條件，真正的最佳方案才會被執行。 ?
? ---- ? 總結： ?
? ---- ? 1.多表操作在被實際執行前，查詢優化器會根據連接條件，列出幾組可能的連接方 ?
? 案并從中找出系統開銷最小的最佳方案。連接條件要充份考慮帶有索引的表、行數多的 ?
? 表；內外表的選擇可由公式：外層表中的匹配行數*內層表中每一次查找的次數確定，乘 ?
? 積最小為最佳方案。 ?
? ---- ? 2.查看執行方案的方法-- ? 用set ? showplanon，打開showplan選項，就可以看到連 ?
? 接順序、使用何種索引的信息；想看更詳細的信息，需用sa角色執行dbcc(3604,310,30 ?
? 2)。 ?
? 三、不可優化的where子句 ?
? ---- ? 1.例：下列SQL條件語句中的列都建有恰當的索引，但執行速度卻非常慢： ?
? select ? * ? from ? record ? where ?
? substring(card_no,1,4)='5378'(13秒) ?
? select ? * ? from ? record ? where ?
? amount/30< ? 1000（11秒） ?
? select ? * ? from ? record ? where ?
? convert(char(10),date,112)='19991201'（10秒） ?
? ---- ? 分析： ?
? ---- ? where子句中對列的任何操作結果都是在SQL運行時逐列計算得到的，因此它不得不 ?
? 進行表搜索，而沒有使用該列上面的索引；如果這些結果在查詢編譯時就能得到，那么 ?
? 就可以被SQL優化器優化，使用索引，避免表搜索，因此將SQL重寫成下面這樣： ?
? select ? * ? from ? record ? where ? card_no ? like ?
? '5378%'（< ? 1秒） ?
? select ? * ? from ? record ? where ? amount ?
? < ? 1000*30（< ? 1秒） ?
? select ? * ? from ? record ? where ? date= ? '1999/12/01' ?
? （< ? 1秒） ?
? ---- ? 你會發現SQL明顯快起來！ ?
? ---- ? 2.例：表stuff有200000行，id_no上有非群集索引，請看下面這個SQL： ?
? select ? count(*) ? from ? stuff ? where ? id_no ? in('0','1') ?
? （23秒） ?
? ---- ? 分析： ?
? ---- ? where條件中的'in'在邏輯上相當于'or'，所以語法分析器會將in ? ('0','1')轉化 ?
? 為id_no ? ='0' ? or ? id_no='1'來執行。我們期望它會根據每個or子句分別查找，再將結果 ?
? 相加，這樣可以利用id_no上的索引；但實際上（根據showplan）,它卻采用了"OR策略" ?
? ，即先取出滿足每個or子句的行，存入臨時數據庫的工作表中，再建立唯一索引以去掉 ?
? 重復行，最后從這個臨時表中計算結果。因此，實際過程沒有利用id_no上索引，并且完 ?
? 成時間還要受tempdb數據庫性能的影響。 ?
? ---- ? 實踐證明，表的行數越多，工作表的性能就越差，當stuff有620000行時，執行時 ?
? 間竟達到220秒！還不如將or子句分開： ?
? select ? count(*) ? from ? stuff ? where ? id_no='0' ?
? select ? count(*) ? from ? stuff ? where ? id_no='1' ?
? ---- ? 得到兩個結果，再作一次加法合算。因為每句都使用了索引，執行時間只有3秒， ?
? 在620000行下，時間也只有4秒。或者，用更好的方法，寫一個簡單的存儲過程： ?
? create ? proc ? count_stuff ? as ?
? declare ? @a ? int ?
? declare ? @b ? int ?
? declare ? @c ? int ?
? declare ? @d ? char(10) ?
? begin ?
? select ? @a=count(*) ? from ? stuff ? where ? id_no='0' ?
? select ? @b=count(*) ? from ? stuff ? where ? id_no='1' ?
? end ?
? select ? @c=@a+@b ?
? select ? @d=convert(char(10),@c) ?
? print ? @d ?
? ---- ? 直接算出結果，執行時間同上面一樣快！ ?
? ---- ? 總結： ?
? ---- ? 可見，所謂優化即where子句利用了索引，不可優化即發生了表掃描或額外開銷。 ?
? ?
? ---- ? 1.任何對列的操作都將導致表掃描，它包括數據庫函數、計算表達式等等，查詢時 ?
? 要盡可能將操作移至等號右邊。 ?
? ---- ? 2.in、or子句常會使用工作表，使索引失效；如果不產生大量重復值，可以考慮把 ?
? 子句拆開；拆開的子句中應該包含索引。 ?
? ---- ? 3.要善于使用存儲過程，它使SQL變得更加靈活和高效。 ?
? ---- ? 從以上這些例子可以看出，SQL優化的實質就是在結果正確的前提下，用優化器可 ?
? 以識別的語句，充份利用索引，減少表掃描的I/O次數，盡量避免表搜索的發生。其實S ?
? QL的性能優化是一個復雜的過程，上述這些只是在應用層次的一種體現，深入研究還會 ?
? 涉及數據庫層的資源配置、網絡層的流量控制以及操作系統層的總體設計。 ?
? ?
? 文/交通銀行長春分行電腦部 ? 任亮 ? 摘自計算機日報Top
5 樓txlicenhe（馬可）回復于 2003-12-02 22:58:43 得分 0
?
? 速度，影響它的因數太多了，且數據量越大越明顯。 ?
? 1、存儲 ?
? ? ? ? 將硬盤分成NTFS格式，NTFS比FAT32快，并看你的數據文件大小，1G以上你可以采用多數據庫文件，這樣可以將存取負載分散到多個物理硬盤或磁盤陣列上。 ?
? ?
? 2、tempdb ?
? ? ? ? tempdb也應該被單獨的物理硬盤或磁盤陣列上,建議放在RAID ? 0上，這樣它的性能最高,不要對它設置最大值讓它自動增長 ?
? ?
? 3、日志文件 ?
? ? ? ? 日志文件也應該和數據文件分開在不同的理硬盤或磁盤陣列上，這樣也可以提高硬盤I/O性能。 ?
? ?
? 4、分區視圖 ?
? ? ? ? 就是將你的數據水平分割在集群服務器上，它適合大規模OLTP,SQL群集上，如果你數據庫不是訪問特別大不建議使用。 ?
? ?
? 5、簇索引 ?
? ? ? ? 你的表一定有個簇索引，在使用簇索引查詢的時候，區塊查詢是最快的，如用between，應為他是物理連續的，你應該盡量減少對它的updaet,應為這可以使它物理不連續。 ?
? ?
? 6、非簇索引 ?
? ? ? ? 非簇索引與物理順序無關，設計它時必須有高度的可選擇性，可以提高查詢速度，但對表update的時候這些非簇索引會影響速度，且占用空間大，如果你愿意用空間和修改時間換取速度可以考慮。 ?
? ?
? 7、索引視圖 ?
? ? ? ? 如果在視圖上建立索引,那視圖的結果集就會被存儲起來，對與特定的查詢性能可以提高很多，但同樣對update語句時它也會嚴重減低性能，一般用在數據相對穩定的數據倉庫中。 ?
? ?
? 8、維護索引 ?
? ? ? ? 你在將索引建好后，定期維護是很重要的，用dbcc ? showcontig來觀察頁密度、掃描密度等等，及時用dbcc ? indexdefrag來整理表或視圖的索引,在必要的時候用dbcc ? dbreindex來重建索引可以受到良好的效果。 ?
? ?
總結
- 上一篇： 技术贴]强大的DELPHI RTTI–兼
- 下一篇： linux cmake编译源码,linu