⑴ sql Server 與 MySQL 性能相差多大
sql server性能優於mysql。測試，一個表三千萬數據，模糊查找，主鍵查找，插入sqlerver所用時間不足mysql一半。均為默認安裝。模糊查找，mysql55秒左右，sqlerver 25秒左右。
⑵ 怎樣查出SQLServer的性能瓶頸
SQLServer性能監控
這套性能優化的清單將至少准科學的幫助你找出你的SQLServer任何明顯的性能問題。說是這樣說，SQLServer的性能調優仍然是很困難的。我試圖用這套清單去找出「容易」的sqlserver性能問題，困難的留待稍後。我這樣做是因為很容易將容易和困難的的性能調優問題搞混。通過列出一個「容易」的性能調優范圍，就很容易的將這些問題解決，一旦解決了這些容易的問題，那麼你就能集中去解決更困難的問題。
使用這個SQLServer性能調優清單的一個好處是，它將不僅僅告訴你目前最容易解決的性能問題是什麼，而且還幫助你正確的去解決。在某種程度上，你可以選擇不同的順序進行。換句話說，你可以故意做出特殊的決定而不是按照清單通常的順序進行。某種意義上說你是對的，不是所有的性能調優建議都適合所有的情形。另外，你的決定是基於你的資源限制，例如沒有足夠的錢去買滿足負荷的硬體。如果真是那樣的話，你就別無選擇了。還有，你的決定可能基於一些政治原因，那是你不得不作出的改變。不管怎樣，你需要知道你能做什麼，使用這個性能調優清單找出你能改變的范圍並做出相應的改變提升你的SQLServer的性能。
一般來說，你將在你的每一個SQL伺服器上執行這個清單。如果遇到清單中的一些問題，這會花掉你一些時間。我建議你從目前性能問題最多的的伺服器開始，然後當你有時間的時候按照自己的思路去解決其他伺服器。
一旦你完成了，可仍然有很多事情要去做。記住，這些只是一些容易的。一旦你完成了這些容易的，接下來你需要花時間去解決更困難問題。這個是另一篇文章要解決的問題了。
怎樣進行你的SQLServer性能調優呢?
為了使其變得容易，我把它們分成了以下幾個部分：
？ 使用性能監視器找出硬體瓶頸
？ SQLServer硬體性能監控列表
？ 操作系統性能監控列表
？ SQLServer2000配置性能監控列表
？ 資料庫配置設置性能監控列表
？ 索引性能監控列表
？ 應用程序和T-SQL性能監控列表
？ SQLServer資料庫作業性能監控列表
？ 使用Profiler找出低效的查詢
？ 怎樣最好的實現SQLServer性能監控
管理你的SQLServe性能的最好方法是首先回顧上面每一部分的內容，把它們列印出來。然後完成每一部分的內容，寫下你收集到的結果。你也可以按照你喜歡的順序進行。上面的步驟僅僅列出了我執行的順序，因為那樣通常能達到一個比較好的效果。
性能監控列表
計數器名稱 均值 最小值 最大值
Memory: Pages/sec
Memory: Available Bytes
Physical Disk: % Disk time
Physical Disk: Avg. Disk Queue Length
Processor: % Processor Time
System: Processor Queue Length
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server General: User Connections
在上表輸入你的結果.
使用性能監視器找出SQLServer硬體瓶頸
開始SQLServer性能調優的最佳地方就是從性能監視器（系統監視器）開始。通過一個24小時的周期對一些關鍵的計數器進行監控，你將對你SQLServer伺服器的硬體瓶頸了如指掌。
一般來說，使用性能監視器去創建一個一些關鍵的計數器的24小時周期的監控日誌。當你決定創建這個日誌的時候，你需要選擇一個典型的24小時的周期，例如，選擇一個典型的比較忙的日期，而不是周日或節假日。
一旦你將這些捕獲的數據形成日誌後，在性能監視器的圖形界面下會顯示計數器的推薦值。你在上表中記下均值、最小值、峰值。做完這些後，用你的結果跟下面的分析比較。通過你的結果和下面的建議值進行比較，你將能快速的找到你的SQLServe正在經歷的潛在的硬體瓶頸。
關鍵性能計數器說明
下面是不同關鍵性能計數器的一個討論，它們的建議值和為了幫助解決硬體瓶頸問題的一些選項。注意我已經限制了性能監視器需要監視的一些關鍵計數器。我這么做是因為在本文我們的目的是為了容易的找到顯而易見的性能問題，許多其他的性能監視器計數器你能在本網站其他地方找到。
Memory: Pages/sec
這個計數器記錄的是每秒鍾內存和磁碟之間交換的頁面數。交換更多的頁面、超過你伺服器承受的更多的I/O，將輪流降低你SQLserver的性能。你的目的就是盡量將頁面減少到最小，而不是消除它。
如果你的伺服器上SQLServer是最主要的應用程序，那麼這個值的理想范圍是0～20之間。可能很多時候你看到的值都會超過20。這個值一般要保持在每秒的平均頁數在20以下。
如果這個值平均總是超過20，其中最大的一個可能是內存瓶頸問題，需要增加內存。通常來說，更多的內存意味著需要執行的頁面更少。
在大多數情況下，伺服器決定SQLServer使用的適當內存的大小，頁面將平均小於20。給SQLServer適當的內存意味著伺服器的緩存命中率（Buffer Hit Cache Ratio 這個稍後會講到）達到99％或者更高。如果在一個24小時的周期里你的sqlserver的緩存命中率達到99％或者更高，但是在這個期間你的頁面數總是超過20，這意味著你或許運行了其他的程序。如果是這樣的情況，建議你移除這些程序，使SQLServer是你的伺服器的最主要的程序。
如果你的sqlserver伺服器沒有運行其他程序，並且在一個24小時的周期里頁面數總是超過20，這說明你應該修改你對SQLServer的內存設置了。將其設置為「動態配置SQLServer的內存」，並且最大內存設置得高一些。為了達到最優，SQLServer將盡可能的獲得多的內存以完成自己的工作，而不是去和其他的程序爭奪內存。
Memory: Available Bytes
另一個檢查SQLServer是否有足夠的物理內存的方法是檢查Memory Object: Available Bytes計數器。 這個值至少大於5M，否則需要添加更多的物理內存。在一個專門的SQLServer伺服器上，SQLServer試圖維持4-10M的自由物理內存，其餘的物理內存被操作系統和SQLServer使用。當可用的物理內存接近5M或者更低時，SQLServer最可能因為缺少內存而遇到性能瓶頸。遇此情況，你需要增加物理內存以減少伺服器的負荷，或者給SQLServer配置一個合適的內存。
Physical Disk: % Disk Time
這個計數器度量磁碟陣列繁忙程度（不是邏輯分區或磁碟陣列上獨立的磁碟）。它提供一個對磁碟陣列繁忙程度相對較好的度量。原則上計數器% Disk Time的值應該小於55%。如果持續超過55%（在你24小時的監控周期里大約超過10分鍾），說明你的SQLServer有I/O瓶頸。如果你只是偶爾看到，也不必太擔心。但是，如果經常發生的話（也就是說，一個小時出現好幾次），就應該著手尋找增加伺服器I/O性能或者減少伺服器負荷的解決之道了。一般是為磁碟陣列增加磁碟，或者更好更快的磁碟，或者給控制器卡增加緩存，或者使用不同版本的RAID，或者更換更快的控制器。
在NT4.0上使用該計數器之前，確認在NT命令提示符下輸入diskperf -y，重啟伺服器，以便手動打開。在NT4.0下第一次必須將該計數器打開，Windows2000默認是打開的。
Physical Disk: Avg. Disk Queue Length
除了觀察物理磁碟的% Disk Time計數器外，還可以用Avg. Disk Queue Length計數器。磁碟陣列中的各個磁碟的該值如果超過2（在你24小時的監控周期里大約超過10分鍾），那麼你的磁碟陣列存在I/O瓶頸問題。象計數器% Disk Time一樣，如果只是偶爾看到，也不必太擔心。但是，如果經常發生的話，就應該著手尋找增加伺服器I/O性能的解決之道了。如前所述。
你需要計算這個值，因為性能監視器不知道你的磁碟陣列中有多少物理磁碟。例如，如果你有一個6個物理磁碟組成的磁碟陣列，它的Avg.
Disk Queue Length值為10，那麼實際每個磁碟的值為1.66（10/6＝1.66），它們都在建議值2以內。
在NT4.0上使用該計數器之前，確認在NT命令提示符下輸入diskperf -y，重啟伺服器，以便手動打開。在NT4.0下第一次必須將該計數器打開，Windows2000默認是打開的。
一起使用這兩個計數器將幫助你找出I/O瓶頸。例如，如果% Disk Time的值超過55%，Avg. Disk Queue Length計數器值超過2，伺服器則存在I/O瓶頸。
Processor: % Processor Time
處理器對象： % Processor Time計數器對每一個CPU可用，並針對每一個CPU進行檢測。同樣對於所有的CPU也可用。這是一個觀察CPU利用率的關鍵計數器。如果% Total Processor Time計數器的值持續超過80%（在你24小時的監控周期里大約超過10分鍾），說明CPU存在瓶頸問題。如果只是偶爾發生，並且你認為對你的伺服器影響不大，那沒問題。如果經常發生，你應該減少伺服器的負載，更換更高頻率的CPU，或者增加CPU的數量或者增加CPU的2級緩存（L2 cache）。
System: Processor Queue Length
根據% Processor Time計數器，你可以監控Processor Queue Length計數器。每個CPU的該值如果持續超過2（在你24小時的監控周期里大約超過10分鍾），那麼你的CPU存在瓶頸問題。例如，如果你的伺服器有4個CPU，Processor Queue Length計數器的值總共不應超過8。
如果Processor Queue Length計數器的值有規律的超過建議的最大值，但是CPU利用率相對不是很高，那麼考慮減少SQLServer的"max worker threads"的配置值。Processor Queue Length計數器的值高的可能原因是有太多的工作線程等待處理。通過減少"maximum worker threads"的值，強迫線程池踢掉某些線程，從而使線程池得到最大的利用。
一起使用計數器Processor Queue Length和計數器% Total Process Time，你可以找到CPU瓶頸，如果都顯示超過它們的建議值，可以確信存在CPU瓶頸問題。
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server Buffer中的計數器Buffer Cache Hit Ratio用來指出SQLServer從緩存中而不是磁碟中獲得數據的頻率。在一個OLTP程序中，該比率應該超過90%，理想值是超過99%。如果你的buffer cache hit ratio低於90%，你需要立即增加內存。如果該比率在90%和99%之間，你應該認真考慮購買更多的內存了。如果接近99%，你的SQLServer性能是比較快的了。某些情況下，如果你的資料庫非常大，你不可能達到99%，即使你在伺服器上配置了最大的內存。你所能做的就是盡可能的添加內存。
在OLAP程序中，由於其本身的工作原理，該比率大大減少。不管怎樣，更多的內存總是能提高SQLServer的性能。
SQL Server General: User Connections
既然sqlserver的使用人數會影響它的性能，你就需要專注於sqlserver的General Statistics Object: User Connections計數器。它顯示sqlserver目前連接的數量，而不是用戶數。
如果該計數器超過255，那麼你需要將sqlserver的"Maximum Worker Threads" 的配置值設置得比預設值255高。如果連接的數量超過可用的線程數，那麼sqlserver將共享線程，這樣會影響性能。"Maximum Worker Threads"需要設置得比你伺服器曾經達到的最大連接數更高。
⑶ SQL Server 與 MySQL 性能相差多大
如果只是基本簡單的存儲和利用沒有太大區別，但是請注意：現在資料庫的國際化指標基本還是三種：Oracle/SQLServer/DB2；
順便說說我自己目前理解的sqlserver比mysql好的地方：
函數，sqlserver很多函數mysql沒有，或者說有但沒有前者直接明了
關聯關系，sqlserver可以和其他資料庫關聯，包括oracle等
大數據處理，這個絕對是肯定的
查詢或者說數據處理優化
其他的我就不清楚了
⑷ MySQL和SQLServer相比，哪個性能更好
MySQL和SQLServer相比，哪個性能更好
主要差別，SQL Server是微軟的，只在Windows里能用。MySQL，各種操作系統都能用。要說性能，Sun公司已經把MySQL做到很好了，可以支持大型系統。但是Oracle以後會不會把MySQL做到能夠威脅Oracle資料庫的程度，就不知道了。
⑸ spotlight on sql server具體監控哪些參數指標
你要閑著沒事，系統的性能監控器里sql server的每個參數都可以看看啊，這要寫可以寫一本書了。
系統
內存: 可用位元組數，page\sec
processor: processor time
physical disk:disk time
需要的話還有網路流量
至於sqlserver的監控，至少有
full scans/sec
cache hit ratio
transaction/sec
user connection
lock
number of dead lock/sec
query...
⑹ 如何測試sqlserver性能
對於DBA來講，我們都會做新伺服器的性能測試。我會從TPC的基準測試入手，使用HammerDB做整體性能評估（前身是HammerOra），跟廠商數據對比。再使用DiskSpd針對性的測試磁碟IO性能指標（前身是SQLIO），再到SQLIOSIM測試存儲的完整性，再到ostress並發壓力測試，對於資料庫伺服器遷移，我們還會收集和回放Profiler Trace，並收集期間關鍵性能計數器做對比。
下面我著重談談使用HammerDB的TPC-C來做SQL Server基準測試。
自己寫負載測試代碼很困難
為了模擬資料庫的負載，你想要有多個應用程序用戶和混合數據讀寫的語句。你不想總是對單一行更新相同的值，或者只是重復插入假的值。
自己動手使用Powershell、C#等語言寫負載測試腳本也不是不可能，只是太消耗時間，你需要創建或者恢復資料庫，並做對應的測試。
免費而簡單的壓測SQL Server：使用HammerDB模擬OLTP資料庫負載
HammerDB是一個免費、開源的工具，允許你針對SQL Server、Oracle、MySQL和PostgreSQL等運行TPC-C和TPC-H基準測試。你可以使用HammerDB來針對一個資料庫生成腳本並導入測試。HammerDB也允許你配置一個測試運行的長度，定義暖機階段，對於每個運行的虛擬用戶的數量。
首先，HammerDB有一個自動化隊列，讓你將多個運行在不同級別的虛擬用戶整合到一個隊列--你可以以此獲得在什麼級別下虛擬用戶性能平穩的結果曲線。你也可以用它來模擬用於示範或研究目的的不同負載。
用於SQL Server上的HammerDB的優缺點
HammerDB是一個免費工具，它也極易訪問和快速的啟動基準測試和模擬負載的方法。它的自動程序特性也是的運行工作負載相當自動。
主要缺點是它有一個學習曲線。用戶界面不是很直觀，需要花費時間去習慣。再你使用這個工具一段時間之後，將會更加容易。
HammerDB也不是運行每一個基準測試。它不運行TPC-E基準，例如，SQL Server更熱衷於當前更具發展的OLTP基準TPC-E。如果你用HammerDB運行一個TPC-C基準，你應該理解它不能直接與供應商提供的TPC-C基準結果相比較。但是，它是免費的、快速的、易用的。
基準測試使用案例
基準測試負載不能精確模擬你的應用程序的特點。每個負載是唯一的，在不同的系統有不同的瓶頸。對於很多使用案例，使用預定義的基準測試仍然是非常有效的,包括以下性能的比較：
多個環境（例如：舊的物理伺服器，新的虛擬環境）
使用各種因素的不同及時點（例如：使用共享存儲和共享主機資源的虛擬機的性能）
在配置改變前後的點
當然，對一個資料庫伺服器運行基準測試可以影響其他SQL Server資料庫或者相同主機上其他虛擬機的性能，在生產環境你確保有完善的測試計劃。
對於自學和研究來說，有預配置的負載非常棒。
開始使用基準測試
你可以從閱讀HammerDB官方文檔的「SQL Server OLTP Load Testing Guide」開始。
⑺ sqlserver 中一些常看的指標和清除緩存的方法
如何查看磁碟I/O操作信息
SET
STATISTICS
IO
ON
命令是一個
使
SQL
Server
顯示有關由
Transact-SQL
語句生成的磁碟活動量的信息。
我們在分析索引性能的時候，會非常有用。
啟用了這個屬性後，我們在執行
SQL
語句後，會收到類似如下的信息，這有利於我們分析SQL的性能：
(3999
row(s)
affected)
表
'ChargeCL'。掃描計數
1，邏輯讀取
9547
次，物理讀取
0
次，預讀
0
次，lob
邏輯讀取
0
次，lob
物理讀取
0
次，lob
預讀
0
次。
其中的
lob
邏輯讀取、lob
物理讀取、lob
預讀
這三個指標是
讀取
text、ntext、image
或大值類型
(varchar(max)、nvarchar(max)、varbinary(max))
時的指標。
而
邏輯讀取、物理讀取、預讀
是對普通數據頁的讀取。
使用
SQL
Server
Management
Studio
Standard
Reports
我們在
SQL
Server
Management
Studio
中，選擇資料庫伺服器，或者具體資料庫，或者Security
--
Logins
時，或者Management
時，Notification
Services
或者
SQL
Server
Agent
對象時候，都會看到SQL
Server
替我們提供的一些現成報表，這些報表的數據，有利於我們分析資料庫的狀態。
比如在
SQL
Server
索引基礎知識(1)---
記錄數據的基本格式
http://blog.joycode.com/ghj/archive/2008/01/02/113290.aspx
中，我們就使用數據表佔用空間的報表
具體報表可以參考以下鏈接：
SQL
Server
Management
Studio
Standard
Reports
-
Overview
http://blogs.msdn.com/buckwoody/archive/2007/10/09/sql-server-management-studio-standard-reports-overview.aspx
測試中，釋放緩存的一些方法
尤其查詢語句性能測試時，數據是否被緩存，這是測試中一個重要點。下面幾個命令幫助我們清除緩存。方便測試。
清除緩存有關的命令：
SQL
2000裡面除了dbcc
unpintable好像就沒有了
而且這個操作也不會立即釋放表內存Buffer
(DBCC
UNPINTABLE
does
not
cause
the
table
to
be
immediately
flushed
from
the
data
cache.
It
specifies
that
all
of
the
pages
for
the
table
in
the
buffer
cache
can
be
flushed
if
space
is
needed
to
read
in
a
new
page
from
disk.)
SQL
2005/2008讓DBA能夠更自由的對SQL所佔用的內存空間做處理
如：
CHECKPOINT
將當前資料庫的全部臟頁寫入磁碟。「臟頁」是已輸入緩存區高速緩存且已修改但尚未寫入磁碟的數據頁。CHECKPOINT
可創建一個檢查點，在該點保證全部臟頁都已寫入磁碟，從而在以後的恢復過程中節省時間。
DBCC
DROPCLEANBUFFERS
從緩沖池中刪除所有清除緩沖區。
DBCC
FREEPROCCACHE
從過程緩存中刪除所有元素。
DBCC
FREESYSTEMCACHE
從所有緩存中釋放所有未使用的緩存條目。SQL
Server
2005
資料庫引擎會事先在後台清理未使用的緩存條目，以使內存可用於當前條目。但是，可以使用此命令從所有緩存中手動刪除未使用的條目。
另外還可以
sp_cursor_list
查看全部游標
DBCC
OPENTRAN查看資料庫打開事務狀態等
⑻ 【查詢優化】怎樣用SQL語句查看查詢的性能指標
（有關TSQL語句查詢所產生的磁碟活動量） --顯示有關由Transact-SQL 語句生成的磁碟活動量的信息 SET STATISTICS IOON--關閉有關由Transact-SQL 語句生成的磁碟活動量的信息 SET STATISTICS IOOFF 顯示的信息如下： （SQL語句為：select * fromnote500）其中： 掃描計數：在查詢中涉及到的表被訪問的次數； 邏輯讀取：從數據緩沖中讀取的數據頁數； 物理讀取：從物理磁碟中往緩沖讀取的數據頁數； 預讀：根據執行計劃從物理磁碟中往緩沖讀取的數據頁數； 其中對於首次查詢一般情況下會有一下關系：邏輯讀取=物理讀取+預讀(其中的具體聯系，由於已經在之前的博客文章中提到，就不再詳細說明（文章名為 【查詢優化】MSSQL查詢執行流程）) 同理，後面的lob邏輯讀取、物理讀取、預讀概念理解差不多，只是是對相應表進行更新或插入操作時體現。 對於掃描計數，以上圖片的查詢沒有連接查詢，因此意義不大。不過，如果連接查詢來說，特別是循環查詢那種，比如說自連接，如果循環次數越多，則掃描次數也就越多，則會使得查詢的效率越低。這是掃描計數是一個比較重要的性能體現參數。 對於邏輯讀取，由於SQLSERVER中對數據進行任何操作都要把數據讀入到緩沖當中，如果邏輯讀取的頁數越多，則查詢的性能越低。為此，邏輯讀取一般都是查詢性能體現的一個重要參數。 二、SET STATISTICSTIME（SQL Server解析和編譯時間） 上面顯示的信息表明，執行這次查詢使用了多少CPU運行時間和運行查詢使用了多少時間。CPU運行時間是對運行查詢所需要的CPU資源的一種相對穩定的測量方法，與CPU的忙閑程度沒有關系。但是，每次運行查詢時這一數字也會有所不同，只是變化的范圍沒有總時間變化大。總時間是對查詢執行所需要的時間（不計算阻塞或讀數據的時間），由於伺服器上的負載是在不斷變化的，因此這一數據的變化范圍有時會相當地大。 總的來說，量化地來看一個查詢語句的性能可以在幾個參數進行比較： 1、CPU時間。比較查詢所要佔用的CPU資源時間； 2、I/O。可以比較查詢的循環掃描次數和邏輯讀取的數據量；