Ⅰ sql server性能優化與管理藝術 sql server性能調優實戰 哪個好
各主流資料庫用法如下： sqlserver： alter table 表名 drop column 列名;oracle： alter table 表名 drop column 列名;mysql： alter table 表名 drop column 列名;總結：在主流資料庫下，刪除列的語法是一致的，並無差別。
Ⅱ 如何進行SQL性能優化
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樹存放。
Ⅲ sql server性能優化與管理藝術 sql server性能調優實戰 哪個好
本書是一線dba技術專家精心之作。積作者多年的經驗結晶和*佳實踐。
也是目前市場上為數不多通過存儲原理來講解性能優化，剖析sql
server架構，從而幫助讀者快速高效調優資料庫的圖書。
Ⅳ Sql server 安全,性能優化的15條方案
1．1 基本概念 與資料庫技術密切相關的基本概念包括：數據、資料庫、資料庫管理系統和資料庫系統四大概念。1. 數據（Data） 數據是對客觀事物的一種描述，是由能被計算機識別與處理的數值、字元等符號構成的集合，即數據是指描述事物的符號記錄。 廣義地說，數據是一種物理符號的序列，用於記錄事物的情況，是對客觀事物及其屬性進行的一種抽象化及符號化的描述。數據的概念應包括數據的內容和形式兩個方面。數據的內容是指所描述的客觀事物的具體特性，也就是通常所說的數據的「值」；數據的形式則是指數據內容所存儲的具體形式，即數據的「類型」。故此，數據可以用數據類型和值來表示。2. 資料庫（Data Base，DB） 資料庫是指長期存儲在計算機內部、有組織的、可共享的數據集合，即在計算機系統中按一定的數據模型組織、存儲和使用的相關聯的數據集合成為資料庫。 資料庫中的數據按照一定的數據模型組織、描述和存儲，具有較小的冗餘度、較高的數據獨立性、易擴展性、集中性和共享性，以文件的形式存儲在存儲介質上的。資料庫中的數據由資料庫管理系統進行統一管理和控制，用戶對資料庫進行的各種數據操作都是通過資料庫管理系統實現。3. 資料庫管理系統（Data Base Management System，DBMS） 資料庫管理系統是資料庫系統的核心，是為資料庫的建立、使用和維護而配置的軟體，是位於操作系統與用戶之間的一層數據管理軟體。主要功能是對資料庫進行定義、操作、控制和管理。1) 數據定義 數據的定義包括：定義構成資料庫結構的外模式、模式和內模式，定義各個外模式和模式之間的映射，定義模式與內模式之間的映射，定義有關的約束條件。2) 數據處理對數據的處理操作主要包括對資料庫數據的檢索、插入、修改和刪除等基本操作。3) 安全管理 對資料庫的安全管理主要體現在：對資料庫進行並發控制、安全性檢查、完整性約束條件的檢查和執行、資料庫的內部維護（如索引、數據字典的自動維護）等。並且能夠管理和監督用戶的許可權，防止擁護有任何破壞或者惡意的企圖。4) 數據的組織、存儲和管理 負責分類地組織、存儲和管理資料庫數據，確定以何種文件結構和存取方式物理地組織數據，如何實現數據之間的聯系，以便提高存儲空間利用以及提高隨機查找、順序查找、增加、刪除和查改等操作的時間效率。5) 建立和維護資料庫 建立資料庫包括資料庫數據的初始化與數據轉換等。維護資料庫包括資料庫的轉儲與恢復、資料庫的重組織與重構造、性能的監視與分析等。6) 數據通信介面提供與其他軟體系統進行通信的功能。4. 資料庫系統（Data Base System，DBS） 資料庫系統指在計算機系統中引入資料庫後的系統構成，一般有資料庫、資料庫管理系統、應用系統、資料庫管理員和用戶構成。1．2 資料庫系統的特點 資料庫系統的點主要有：數據的結構化、高共享性、低冗餘度、易擴充、較高的獨立性（物理數據獨立、邏輯數據獨立）以及數據由DBMS統一管理和控制（數據的安全性Security保護、數據的完整性Integrity保護、並發Concurrency控制、資料庫恢復Recovery）等。第二章 資料庫性能優化 資料庫作為一種獨立的、有組織、的可共享的數據集合，數據的查詢訪問是數據操作中頻度最高的操作。當數據量和訪問頻率達到一定程度的時候，系統的響應速度就至關重要了，這時候就需要對資料庫數據存儲的結構和方式進行優化，使其滿足系統需要的訪問響應速度。2．1 性能影響因素 常見的影響數據訪問速度的因素，有以下幾種：1. 沒有索引或者沒有用到索引 資料庫索引就像書籍中目錄一樣，使用戶在訪問資料庫數據時，不必遍歷所有數據就可以找到需要的數據。創建索引後，可以保證每行數據的唯一性，極大地提高數據檢索效率，這是一中犧牲空間換取性能的方法。沒有索引或者沒有用到索引是數據訪問速度慢最常見的因素，也是程序設計的一個缺陷所在。2. I/O吞吐量小，形成了瓶頸效應 I/O吞吐量是影響數據訪問速度的客觀因素（硬體因素）。在一定的硬體環境下，利用優化的部署方案可適當提高I/O吞吐量。3. 沒有創建計算列導致查詢不優化 計算列是一個比較特殊的列，不填寫任何設計類型，用戶不可以改變該列的值。計算列的值是通過一定的函數公式等以另一個或多個列的值為輸入值計算出的結果。如果沒相應的計算列，在一些數據查詢的時候需要對已有數據進行計算，從而浪費一部分性能。4. 內存不足 對資料庫數據的查詢訪問毫無疑問會佔用大量的內存空間，當內存不足的情況下，數據的訪問速度會受到明顯的影響甚至訪問出現超時情況，是影響數據訪問速度的客觀因素。5. 網路速度慢 網路速度慢是影響數據訪問速度的客觀因素。可通過提高網路訪問的位寬來解決。6. 查詢出的數據量過大 當查詢出的數據量過大時，內存的佔用、系統時間的佔用等都影響數據訪問的速度。可以採用多次查詢、定位查詢、和查詢數據量控制來解決。7. 鎖或者死鎖 鎖或者死鎖在資料庫數據訪問時會造成訪問者等待時間過程或者永久無法獲取到資源。這是查詢慢最常見的因素之一，是程序設計的缺陷，要盡量避免。8. 返回不必要的行和列 在一般的數據查詢中，都盡可能多的獲取數據信息，這樣造成了不必要的數據遍歷，大大的增加了數據訪問的響應的時間。所以在一般的查詢中，盡量查詢少的行和列，將數據遍歷時間降到最低以滿足數據輸出需求。9. 查詢語句不夠優化 在數據查詢訪問過程中，使用最頻繁的是使用自定義的查詢語句進行數據輸出的。所以編寫優化的查詢語句能夠很大程度上提高數據查詢訪問的速度。2．2 性能優化 資料庫性能優化主要是提高數據訪問的速度，即提高資料庫響應速度的性能指標。性能優化主要分為主觀因素和客觀因素兩部分的優化。這里主要針對影響性能的客觀因素進行優化。2．2．1 主觀因素優化 主觀因素主要是指伺服器的硬體環境。主要優化有以下幾個方面：1、 把數據、日誌、索引放到不同的I/O設備上，增加讀取速度，數據量越大，提高I/O吞吐量越重要；2、 縱向、橫向分割表，減少表的尺寸（sp_spaceuse）；3、 升級硬體；4、 提高網路訪問速度；5、 擴大伺服器的內存；配置虛擬內存：虛擬內存大小應基於計算機上並發運行的服務進行配置，一般設置為物理內存的1.5倍；如果安裝了全文檢索功能，並打算運行Microsoft搜索服務以便執行全文索引和查詢，可考慮將虛擬內存大小設置為至少計算機中物理內存的3倍；6、 增加伺服器CPU個數；其中並行處理比串列處理更需要資源。SQL SERVER根據系統負載情況決定最優的並行等級，復雜的需要消耗大量的CPU的查詢適合並行處理。不過更新操作UPDATE、INSERT、DELETE不能進行並行處理。 2．2．2 客觀因素優化 客觀因素主要指的是由於設計和開發中存在的缺陷和漏洞；主要優化有以下幾個方面：1. 優化索引（1） 根據查詢條件建立優化的索引、優化訪問方式，限制結果集的數據量。注意填充因子要適當（最好是使用默認值0）。索引應該盡量小，使用位元組數小的列建里索引（參照索引的創建），不要對有限的幾個值的欄位建立單一索引（如性別欄位）。（2） 如果使用LIKE進行查詢的話，簡單的使用INDEX是不行的，全文索引又太耗費空間。LIKE 『N%』使用索引，LIKE 『%N』不使用索引。用LIKE『%N%』查詢時，查詢耗時和欄位值總長度成正比，所以不能用CHAR類型而採用VARCHAR。對於欄位的值很長的欄位建立全文索引。（3） 重建索引DBCC REINDEX，DBCC INDEXDEFRAG，收縮數據和日誌DBCC SHRINKDB，DBCC SHRINKFILE。設置自動收縮日誌，對與大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能。2. 資料庫部署優化（1） DB SERVER和APPLICATION SERVER分離，OLTP和OLAP分離；（2） 使用分區視圖。分布式分區視圖可用於實現資料庫伺服器聯合體，聯合體是一組分開管理的伺服器，他們互相協作分擔系統的處理負荷。A、在實現分區視圖之前，必須先水平分區表。B、在創建成員表後，在每個伺服器上定義一個分布式分區視圖，並且每個視圖具有相同的名稱。這樣引用分布式分區視圖名的查詢可以在任何一個成員伺服器上運行。系統操作如同每個成員伺服器都有一個原始表的復本一樣，不過每個伺服器上其實只有一個成員表和一個分布式分區視圖。數據的位置對應用程序是透明的。3. 查詢語句優化 T-SQL的寫法上有很大的講究，DBMS處理查詢計劃的過程是：a、查詢語句的詞法、語法檢查；b、將語句提交給DBMS的查詢優化器；c、優化器做代數優化和存取路徑的優化；d、由預編譯模塊生成查詢規劃；e、在合適的時間提交給系統處理執行；f、將執行結果返回給用戶。（1） COMMIT和ROLLBACK的區別：ROLLBACK回滾所有的事務；COMMIT提交當前的事務。在動態語句中寫事務，請將事務寫在外面，如：BEGIN TRAN EXEC（@SQL） COMMIT TRANS或者將動態SQL寫成函數或者存儲過程。（2） 在大數據兩的查詢輸出SELECT語句中盡量不要使用自定義函數，調用自定義函數的函數時系統調用是一個迭代過程，很影響查詢輸出性能的。在查詢欄位時盡可能使用小欄位兩輸出，並在WHERE子句或者使用SELECT TOP 10/1 PERCENT來限制返回的記錄數，使用SET ROWCOUNT來限制操作的記錄數，避免整表掃描。返回不必要的數據，不但浪費了伺服器的I/O資源，加重了網路的負擔，如果表很大的話，在表掃描期間將表鎖住，禁止其他的聯接訪問，後過很嚴重的。（3） SQL的注釋申明對執行查詢輸出沒有任何影響。（4） 使用計算列對數據進行簡單計算，盡量避免在查詢語句中對數據進行運算。（5） 盡可能不使用游標，它會佔用大量的資源。如果需要ROW-BY-ROW地執行，盡量採用非游標技術，如：客戶端循環、臨時表、TABLE變數、子查詢、CASE語句等等。（6） 使用PROFILER來跟蹤查詢，得到查詢所需的時間，找出SQL的問題所在，用索引優化器優化索引。（7） 注意UNION和UNION ALL的區別。在沒有必要的時候不要用DISINCT，它同UNION一樣會降低查詢速度，重復的記錄在查詢里是沒有問題的。（8） 用sp_configure 『query governor cost limit』或者 SET QUERY_COVERNOR_COST_LIMIT來限制查詢消耗的資源。當評估查詢消耗的 資源超出限制時，伺服器自動取消查詢，在查詢之前就扼殺掉。SET LOCKTIME 設置鎖的時間。（9） 不要在WHERE子句中列名加函數，如CONVERT，SUBSTRING等，如果必須用函數的時候，創建計算列在創建索引來替代。NOT IN會多次掃描表，使用EXISTS、NOT EXISTS、IN、LEFT OUTER JOIN來替代，其中EXISTS比IN更快，最慢的NOT操作。（10） 使用QUERY ANALYZER，查看SQL語句的查詢計劃和評估分析是否是優化的SQL。一般20%的代碼佔用了80%的資源，優化的重點就是這些慢的地方。（11） 如果使用了IN或者OR等時發現查詢沒有走索引，使用顯式申明指定索引，如：Select * From FA01(INDEX=IX_SEX) Where AA0107 IN(『01』,『02』)。（12） 在需要對已有數據進行比較復雜計算才能獲得查詢的結果數據時,將需要查詢的結果預先計算好放在表中,查詢的時候在SELECT。（13） 資料庫有一個原則是代碼離數據越近越好，所有有限選擇DEFAULT，依次為RULES，CONSTRAINT，PROCEDURE來編寫程序的質量高，速度快。如果要插入大的二進制到IMAGE列，使用存儲過程，千萬不要用內嵌INSERT直接插入。因為這樣應用程序首先將二進制轉換成字元串，伺服器收到字元後又將他轉換成二進制。存儲過程直接傳入二進制參數即可，處理速度明顯改善，如：CREATE PROCEDURE image_insert @image varbinary as Insert into table(fImage) values(@image)。（14） Between在某些時候比IN速度更快，更快地根據索引找到范圍。由於IN會比較多次，所以有時會慢些。（15） 盡量不要建沒有作用的事務例如產生報表時，浪費資源，只有在必須使用事務時才建立合適的事務。（16） 用OR的字句可以分解成多個查詢，並通過UNION連接多個查詢。速度取決與是否使用索引。如果查詢需要用聯合索引，用UNION ALL執行的效率更高些。（17） 盡量少用視圖，視圖的效率低。對視圖操作比直接對表操作慢，可以用SRORED PROCEDURE來代替。特別是不要用視圖嵌套，嵌套視圖增加了尋找原始資料的難度。視圖是存放在伺服器上的被優化好了的已經產生查詢規劃的SQL。對單表數據檢索時，不要使用指向多表的視圖，否則增加了不必要的系統開銷，查詢也會受到干擾。沒有必要時不要用DISTINCT和ORDER BY，這些動作可以改在客戶端執行，增加了額外的開銷，這同UNION和UNION ALL原理相同。（18） 當使用SELECT INTO和CREATE TABLE時，會鎖住系統表（SYSOBJECTS，SYSINDEXES等），從而阻塞其他的連接的存取。所以千萬不要在事務內部使用。如果經常要用到臨時表時請使用實表或者臨時表變數。盡量少用臨時表，用結果集和TABLE類型的變數來代替。（19） 在使用GROUP BY HAVING子句時，在使用前剔除多餘的行，盡量避免使用HAVING子句剔除行工作。剔除行最優的執行順序是：SELECT的WHERE子句選擇所有合適的行，GROUP
Ⅳ 如何優化sql server 伺服器性能
你可以通過profiler和性能工具，跟蹤一段時間，然後分析一個瓶頸是什麼，再對瓶頸進行處理。
一般來說，增加足夠大的內存能讓性能快速提高。
使用更快的硬碟。
把資料庫分離業務，比如A業務訪問A資料庫，B業務訪問B資料庫。
Ⅵ sql server性能優化與管理的藝術 怎麼樣
全書共15章，分為三部分，第一部分（第1～2章）為概述部分，闡述SQL Server方面的「性能」及相關概念。並給出常規的性能及性能相關的問題偵測的「方法論」，讀者可以通過這兩章的介紹，對SQL Server性能問題有一個高層次的認識。第二部分（第3～10章）為知識准備部分，這部分介紹了SQL Server性能相關的基礎知識。只有了解了性能及影響性能的相關部分，才能准確地、高效地進行優化。第三部分（第11~15章）為工具使用及優化演示，在多伺服器、大數據的環境下，不應該再使用原始的故障偵測方法，借用各種工具能更全面、更高效地找到問題並且解決問題。
通過這三部分的介紹，可以使讀者有一個清晰的性能優化及管理方面的認識，並且通過大量演示，讓讀者能夠較快地進入實戰階段。《SQL Server 性能優化與管理的藝術》的重點主要集中在第二部分，既介紹了性能相關的部分，以便後續使用，也給出了一個後續深入學習的「清單」，讀者不應止步於本書，可以根據書中的知識點，進行更深入的學習。
Ⅶ 手機server介面的性能如何優化
在查詢分析階段，SQL Server優化器查看每一個由正規查詢樹代表的子句，並判斷它是否能被優化。SQL Server優化一般會盡量優化那些限制掃描的子句。例如，搜索和/或合並子句。但是不是所有合法的SQL語法都可以分成可優化的子句，如含有SQL不等關系符「<>」的子句。
因為「<>」是1個排斥性的操作符，而不是1個包括性的操作符，所在掃描整個表之前無法確定子句的選擇范圍會有多大。當1個關系型查詢中含有不可SQL Server優化的子句時，執行計劃用表掃描來訪問查詢的這個部分，對於查詢樹中可優化的SQL Server子句，則由優化器執行索引選擇。
2.索引選擇
對於每個可優化的子句，優化器都查看資料庫系統表，以確定是否有相關的索引能用於訪問數據。只有當索引中的列的1個前綴與查詢子句中的列完全匹配時，這個索引才被認為是有用的。因為索引是根據列的順序構造的，所以要求匹配是精確的匹配。
所以在設計過程中，要根據查詢設計准則仔細檢查所有的查詢，以查詢的優化特點為基礎設計索引。
(1)比較窄的索引具有比較高的效率。對於比較窄的索引來說，每頁上能存放較多的索引行，而且索引的級別也較少。所以，緩存中能放置更多的索引頁，這樣也減少了I/O操作。
(2)SQL Server優化器能分析大量的索引和合並可能性。所以與較少的寬索引相比，較多的窄索引能向優化器提供更多的選擇。但是不要保留不必要的索引，因為它們將增加存儲和維護的開支。對於復合索引、組合索引或多列索引，SQL Server優化器只保留最重要的列的分布統計信息，這樣，索引的第1列應該有很大的選擇性。
(3)表上的索引過多會影響UPDATE、INSERT和DELETE的性能，因為所有的索引都必須做相應的調整。另外，所有的分頁操作都被記錄在日誌中，這也會增加I/O操作。
(4)對1個經常被更新的列建立索引，會嚴重影響性能。
(5)由於存儲開支和I/O操作方面的原因，較小的自組索引比較大的索引性能更好一些。但它的缺點是要維護自組的列。
(6)盡量分析出每一個重要查詢的使用頻度，這樣可以找出使用最多的索引，然後可以先對這些索引進行適當的優化。
(7)查詢中的WHERE子句中的任何列都很可能是個索引列，因為優化器重點處理這個子句。
(8)對小於1個范圍的小型表進行索引是不劃算的，因為對於小表來說表掃描往往更快而且費用低。
(9)與「ORDER BY」或「GROUP BY」一起使用的列一般適於做分族索引。如果「ORDER BY」命令中用到的列上有分簇索引，那麼就不會再生成1個工作表了，因為行已經排序了。「GROUP BY」命令則一定產生1個工作表。
(10)分簇索引不應該構造在經常變化的列上，因為這會引起整行的移動。
Ⅷ 談談Tempdb對SQL Server性能優化有何影響
先給大家鞏固tempdb的基礎知識
簡介：
tempdb是SQLServer的系統資料庫一直都是SQLServer的重要組成部分，用來存儲臨時對象。可以簡單理解tempdb是SQLServer的速寫板。應用程序與資料庫都可以使用tempdb作為臨時的數據存儲區。一個實例的所有用戶都共享一個Tempdb。很明顯，這樣的設計不是很好。當多個應用程序的資料庫部署在同一台伺服器上的時候，應用程序共享tempdb，如果開發人員不注意對Tempdb的使用就會造成這些資料庫相互影響從而影響應用程序。
特性：
1、 tempdb中的任何數據在系統重新啟動之後都不會持久存在。因為實際上每次SQLServer啟動的時候都會重新創建tempdb。這個特性就說明tempdb不需要恢復。
2、 tempdb始終設置為「simple」的恢復模式，當你嘗試修改時都會報錯。也就是說已提交事務的事務日誌記錄在每個檢查點後都標記為重用。
3、 tempdb也只能有一個filegroup，不能增加更多文件組。
4、 tempdb被用來存儲三種類型的對象：用戶對象，內部對象、版本存儲區
接下來圍繞主題展示問題分析：
1.SQL Server系統資料庫介紹
SQL Server有四個重要的系統級資料庫:master,model,msdb,tempdb.
master:記錄SQL Server系統的所有系統級信息,包括實例范圍的元數據,端點,鏈接伺服器和系統配置設置,還記錄其他資料庫是否存在以及這些數據問文件的位置等等.如果master不可用,資料庫將不能啟動.
model:用在SQL Server 實例上創建的所有資料庫的模板。因為每次啟動 SQL Server 時都會創建 tempdb，所以 model 資料庫必須始終存在於 SQL Server 系統中。
msdb:由SQL Server 代理用來計劃警報和作業。
tempdb:是連接到 SQL Server 實例的所有用戶都可用的全局資源，它保存所有臨時表,臨時工作表,臨時存儲過程,臨時存儲大的類型,中間結果集,表變數和游標等。另外，它還用來滿足所有其他臨時存儲要求.
2.tempdb內在運行原理
與其他SQL Server資料庫不同的是,tempdb在SQL Server停掉,重啟時會自動的drop,re-create. 根據model資料庫會默認建立一個新的8MB(mdf file:8MB;ldf file:1MB, autogtouth設置為10%)大小recovery model為simple的tempdb資料庫.
tempdb資料庫建立之後,DBA可以在其他的資料庫中建立數據對象,臨時表,臨時存儲過程,表變數等會加到tempdb中.在tempdb活動很頻繁時,能夠自動的增長,因為是simple的recovery model,會最小化日誌記錄,日誌也會不斷的截斷.
3.如何合理的優化tempdb以提高SQL Server的性能
如果SQL Server對tempdb訪問不頻繁,tempdb對資料庫不會產生影響;相反如果訪問很頻繁,loading就會加重,tempdb的性能就會對整個DB產生重要的影響.優化tempdb的性能變的很重要的,尤其對於大型資料庫.
注:在優化tempdb之前,請先考慮tempdb對SQL Server性能產生多大的影響,評估遇到的問題以及可行性.
3.1最小化的使用tempdb
SQL Server中很多的活動都活發生在tempdb中,所以在某種情況可以減少多對tempdb的過度使用,以提高SQL Server的整體性能.
如下有幾處用到tempdb的地方:
(1)用戶建立的臨時表.如果能夠避免不用,就盡量避免. 如果使用臨時表儲存大量的數據且頻繁訪問,考慮添加index以增加查詢效率.
(2)Schele jobs.如DBCC CHECKDB會佔用系統較多的資源,較多的使用tempdb.最好在SQL Server loading比較輕的時候做.
(3)Cursors.游標會嚴重影響性能應當盡量避免使用.
(4)CTE(Common Table Expression).也會在tempdb中執行.
(5)SORT_INT_TEMPDB.建立index時會有此選項.
(6)Index online rebuild.
(7)臨時工作表及中間結果集.如JOIN時產生的.
(8)排序的結果.
(9)AFTER and INSTEAD OF triggers.
不可能避免使用tempdb,如果有tempdb的瓶頸或issue,就該返回來考慮這些問題了.
3.2重新分配tempdb的空間大小
在SQL Server重啟時會自動建立8MB大小的tempdb,自動增長默認為10%. 對於小型的資料庫來說,8MB大小已經足夠了.但是對於較大型的資料庫來說,8MB遠遠不能滿足SQL Server頻繁活動的需要,因此會按照10%的比例增加,比如說需要1GB,則會需要較長的時間,此段時間會嚴重影響SQL Server的性能. 建議在SQL Server啟動時設置tempdb的初始化的大小(如下圖片設置為MDF:300MB,LDF:50MB),也可以通過ALTER DATABASE來實現. 這樣在SQL Server在重啟時tempdb就會有足夠多的空間可利用,從而提高效率.
Ⅸ 如何優化Windows OS使SQL Server性能最優化
怎樣查出SQLServer的性能瓶頸QLServer性能監控這套性能優化的清單將至少准科學的幫助你找出你的SQLServer任何明顯的性能問題。說是這樣說，SQLServer的性能調優仍然是很困難的。我試圖用這套清單去找出「容易」的sqlserver性能問題，困難的留待稍後。我這樣做是因為很容易將容易和困難的的性能調優問題搞混。通過列出一個「容易」的性能調優范圍，就很容易的將這些問題解決，一旦解決了這些容易的問題，那麼你就能集中去解決更困難的問題。使用這個SQLServer性能調優清單的一個好處是，它將不僅僅告訴你目前最容易解決的性能問題是什麼，而且還幫助你正確的去解決。在某種程度上，你可以選擇不同的順序進行。換句話說，你可以故意做出特殊的決定而不是按照清單通常的順序進行。某種意義上說你是對的，不是所有的性能調優建議都適合所有的情形。另外，你的決定是基於你的資源限制，例如沒有足夠的錢去買滿足負荷的硬體。如果真是那樣的話，你就別無選擇了。還有，你的決定可能基於一些政治原因，那是你不得不作出的改變。不管怎樣，你需要知道你能做什麼，使用這個性能調優清單找出你能改變的范圍並做出相應的改變提升你的SQLServer的性能。一般來說，你將在你的每一個SQL伺服器上執行這個清單。如果遇到清單中的一些問題，這會花掉你一些時間。我建議你從目前性能問題最多的的伺服器開始，然後當你有時間的時候按照自己的思路去解決其他伺服器。一旦你完成了，可仍然有很多事情要去做。記住，這些只是一些容易的。一旦你完成了這些容易的，接下來你需要花時間去解決更困難問題。這個是另一篇文章要解決的問題了。怎樣進行你的SQLServer性能調優呢?為了使其變得容易，我把它們分成了以下幾個部分：？使用性能監視器找出硬體瓶頸？SQLServer硬體性能監控列表？操作系統性能監控列表？SQLServer2000配置性能監控列表？資料庫配置設置性能監控列表？索引性能監控列表？應用程序和T-SQL性能監控列表？SQLServer資料庫作業性能監控列表？使用Profiler找出低效的查詢？怎樣最好的實現SQLServer性能監控管理你的SQLServe性能的最好方法是首先回顧上面每一部分的內容，把它們列印出來。然後完成每一部分的內容，寫下你收集到的結果。你也可以按照你喜歡的順序進行。上面的步驟僅僅列出了我執行的順序，因為那樣通常能達到一個比較好的效果。性能監控列表計數器名稱均值最小值最大值Memory:Pages/secMemory:AvailableBytesPhysicalDisk:%DisktimePhysicalDisk:Avg.DiskQueueLengthProcessor:%ProcessorTimeSystem:::UserConnections在上表輸入你的結果.使用性能監視器找出SQLServer硬體瓶頸開始SQLServer性能調優的最佳地方就是從性能監視器（系統監視器）開始。通過一個24小時的周期對一些關鍵的計數器進行監控，你將對你SQLServer伺服器的硬體瓶頸了如指掌。一般來說，使用性能監視器去創建一個一些關鍵的計數器的24小時周期的監控日誌。當你決定創建這個日誌的時候，你需要選擇一個典型的24小時的周期，例如，選擇一個典型的比較忙的日期，而不是周日或節假日。一旦你將這些捕獲的數據形成日誌後，在性能監視器的圖形界面下會顯示計數器的推薦值。你在上表中記下均值、最小值、峰值。做完這些後，用你的結果跟下面的分析比較。通過你的結果和下面的建議值進行比較，你將能快速的找到你的SQLServe正在經歷的潛在的硬體瓶頸。
Ⅹ SQL Server 2005 性能優化
1.索引功能加強。聯機索引選項允許在執行索引數據定義語言時，對基礎表或聚集索引數據及任何關聯的索引進行並發修改。用戶可以再不幹預對表或其他現有索引的訪問的情況下添加索引
2.可收縮性的改進。對大型表和索引的分區功能顯著地增強了大型資料庫的查詢性能。
3.表和索引分區吧資料庫分成更小、更易管理的塊，從而簡化了大型數據的管理
4.Transact-SQL增強