A. 如何釋放sql server佔用的資源內存
sql server 在查詢大數據量的數據時,總會佔用大量的內存,並且居高不下,一不小心就會死機。
下面這個是我從網上找到的:
當你查詢數據的數據量比較大時,sqlserver會把查詢結果緩存在內存中,保證你下次查詢同樣的記錄時會很快得到結果,所以內存使用量會激增。
在你完成此次查詢後,sqlserver不會馬上釋放內存,數據會仍然放在內存中,這是sqlserver的優化策略,sqlserver會不斷地佔用你的系統內存,來加快sqlserver的運行速度,當你的系統中的其它服務也需要內存時,它才會自動釋放部分內存。一句話,sqlserver不會讓你的系統有閑置的內存,除非你設置sqlserver的最大內存使用量。這樣也沒什麼不好,如果你的系統很大,單獨給sqlserver一台機器,這樣會提高它的性能。
如果你只是開發用,要想讓sqlserver釋放內存,重啟sqlserver的服務就行了。如果不想讓sqlserver佔用太多內存,設置sqlserver的最大內存佔用量.
B. 如何做SqlServer 數據查詢優化!
一、建立索引
二、建立存儲過程
三、只查詢您所需要的數據,不要把所有數據都查詢出來,防止數據冗餘。
四、對於大量及海量數據一般還要建立分區
C. 怎樣進行sql資料庫的優化
1、資料庫空間是個概述,在sqlserver里,使用語句 exec sp_spaceused 'TableName' 這個語句來查。
D. 如何對sqlserver進行簡單的優化
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)。索引應該盡量小,使用位元組數小的列建索引好(參照索引的創建),不要對有限的幾個值的欄位建單一索引如性別欄位。
E. sql server資料庫查詢慢怎麼優化
在安裝有SQLServer資料庫的計算機上,我們在使用資料庫的過程中,有時候會在任務管理器里發現sqlservr.exe這個進程的內存和CPU佔用率較高。
接下來我們來看一下,如何解決上面這個問題,需要設置SQLServer資料庫的內存配置。登錄資料庫,這里使用的是SQLServer2008,右鍵點擊最上方的伺服器名,在彈出的菜單中,點擊【屬性】
打開伺服器屬性窗口。默認顯示的是第一項【常規】內容,點擊第二項【內存】進行內存配置。
點擊【內存】後,打開伺服器內存選項配置界面。這里的【使用AWE分配內存】可以對內存進行擴展支持,我們要做的是更改下方的最大伺服器內存。這個數值根據自己伺服器內存大小來做適當設置。
5
個人建議設置本機內存的一半或稍微高一點,如機器內存為2G,那麼我們這里填寫1000。需要注意的是內存設置調小以後,在資料庫執行較復雜SQL語句的時候,可能會比較慢,出現這種情況,我們再適當上調最大內存配置大小。
F. SQL優化問題
問題1,2,3,其實效率是一樣高的,因為現在的sqlserver,oracle,都有sql語句優化分析器,語句不同的寫法,到最後編譯之後,其實是一樣的。
4,如果對欄位like,而且是%key%這樣的方式,索引就不起作用了,所以加上索引也沒用。
G. 如何優化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正在經歷的潛在的硬體瓶頸。
H. sql server速度慢影響因素
首先應該確定是誰慢的,往往是程序處理方面的問題而不是資料庫的問題。
程序方面應該盡可能的減少數據查詢返回的內容,減少IO壓力,磁碟IO和網路IO是非常非常慢的。比如可以查詢返回ID,然後再根據ID一條一條的查詢具體內容,看似慢了,在數據量大的時候快很多
對於數據可以參照下面幾點
1、優化SQL語句,SQL語句對查詢速度影響最大的
2、對於經常查詢的欄位作索引。但是這樣會增加修改時的壓力
4、優化SQLServer,比如給其分配固定的內存,預先分配查詢內存,調整CPU使用率等。SQL Server 可以佔用幾乎所有Windows的內存,但是申請內存開銷很大。因此可以設定其使用固定大小內存,比如啟動就分配1G以上內存。
5、優化硬體資源,比如使用更高的伺服器或者硬碟,獨立安排資料庫的數據文件和索引文件,將數據文件分布於不同的物理硬碟上等等
6、考慮使用分布資料庫或者對大表進行拆分
I. 求優化sqlserver語句,使它查詢效率提高。(要求:分組查詢每組最新的一條數據,數據量非常大,幾十萬)
關於題主的SQL語句提高效率的問題,請留意一下幾點
1) 輸出的欄位列表裡只有來自表「dbo.tunnel_online_monitoring 」里的欄位信息,沒有任何來欄位取自表「dbo.Threshold_ElectronicPool」,而且語句也沒為這兩張表指定連接條件,因此將表「dbo.Threshold_ElectronicPool」引入語句中就沒有任何必要,加入該表只會大大增加系統開銷,而無得益,應予以剔除;
2)row_number()函數的系統開銷是比較大的,能不用盡量別用它。
如果dbo.tunnel_online_monitoring.Id是唯一的,可以不使用row_number()函數,建議語句修改如下:
selectId,CreationDate,LastUpdate,tunnel_name,
SDMC,DT,DZSC1,DZSC2,DZSC3from
tunnel_online_monitoringwhereidin(
selectmax(a.id)fromdbo.tunnel_online_monitoringa,
(selecttunnel_name,max(CreationDate)asCreationDatefrom
dbo.tunnel_online_monitoringgroupbytunnel_name)b
wherea.tunnel_name=b.tunnel_nameanda.CreationDate
=b.CreationDategroupbyb.tunnel_name);
如果dbo.tunnel_online_monitoring.Id是自增ID,那麼可以根據ID的大小來判定那條記錄是最新的,這樣就不需要比對時間欄位的先後了,語句可簡化如下:
selectId,CreationDate,LastUpdate,tunnel_name,
SDMC,DT,DZSC1,DZSC2,DZSC3from
tunnel_online_monitoringwhereidin(
selectmax(id)fromdbo.tunnel_online_monitoring
groupbytunnel_name);
如果dbo.tunnel_online_monitoring.Id不是唯一的,那就還是得利用回row_number()函數了。
J. 如何解決SQL查詢速度太慢
1. 執行計劃中明明有使用到索引,為什麼執行還是這么慢?
2. 執行計劃中顯示掃描行數為 644,為什麼 slow log 中顯示 100 多萬行?
a. 我們先看執行計劃,選擇的索引 「INDX_BIOM_ELOCK_TASK3(TASK_ID)」。結合 sql 來看,因為有 "ORDER BY TASK_ID DESC" 子句,排序通常很慢,如果使用了文件排序性能會更差,優化器選擇這個索引避免了排序。
那為什麼不選 possible_keys:INDX_BIOM_ELOCK_TASK 呢?原因也很簡單,TASK_DATE 欄位區分度太低了,走這個索引需要掃描的行數很大,而且還要進行額外的排序,優化器綜合判斷代價更大,所以就不選這個索引了。不過如果我們強制選擇這個索引(用 force index 語法),會看到 SQL 執行速度更快少於 10s,那是因為優化器基於代價的原則並不等價於執行速度的快慢;
b. 再看執行計劃中的 type:index,"index" 代表 「全索引掃描」,其實和全表掃描差不多,只是掃描的時候是按照索引次序進行而不是行,主要優點就是避免了排序,但是開銷仍然非常大。
Extra:Using where 也意味著掃描完索引後還需要回表進行篩選。一般來說,得保證 type 至少達到 range 級別,最好能達到 ref。
在第 2 點中提到的「慢日誌記錄Rows_examined: 1161559,看起來是全表掃描」,這里更正為「全索引掃描」,掃描行數確實等於表的行數;
c. 關於執行計劃中:「rows:644」,其實這個只是估算值,並不準確,我們分析慢 SQL 時判斷准確的掃描行數應該以 slow log 中的 Rows_examined 為准。
4. 優化建議:添加組合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)
優化過程:
TASK_DATE 欄位存在索引,但是選擇度很低,優化器不會走這個索引,建議後續可以刪除這個索引:
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+
在這個 sql 中 REL_DEVID 欄位從命名上看選擇度較高,通過下面 sql 來檢驗確實如此:
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+
由於有排序,所以得把 task_id 也加入到新建的索引中,REL_DEVID,task_id 組合選擇度 100%:
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+
在測試環境添加 REL_DEVID,TASK_ID 組合索引,測試 sql 性能:alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引後執行計劃:
這里還要注意一點「隱式轉換」:REL_DEVID 欄位數據類型為 varchar,需要在 sql 中加引號:AND T.REL_DEVID = 000000025xxx >> AND T.REL_DEVID = '000000025xxx'
執行時間從 10s+ 降到 毫秒級別:
1 row in set (0.00 sec)
結論
一個典型的 order by 查詢的優化,添加更合適的索引可以避免性能問題:執行計劃使用索引並不意味著就能執行快。