⑴ sql server 在佔用伺服器內存居高不下怎麼辦
SQL Server對伺服器內存的使用策略是用多少內存就佔用多少內存，只用在伺服器內存不足時，才會釋放一點佔用的內存，所以SQL Server 伺服器內存往往會佔用很高。
清除SQL Server伺服器內存的方法：
1、清除所有緩存
DBCC DROPCLEANBUFFERS
2、調整可使用物理內存
把最大伺服器內存改成1G，確定後內存就會被強制釋放，然後把最大伺服器內存改成合適的值。
⑵ sql 同樣一條查詢腳本,在2個伺服器里執行耗費的時間差很多,為什麼
暫時能想到的：
一。有可能是伺服器性能不一樣。
二。有可能是資料庫使用的數據引擎不一樣，比如innodb引擎和myisam的數據處理結果是不一樣的
⑶ 如何解決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 查詢的優化，添加更合適的索引可以避免性能問題：執行計劃使用索引並不意味著就能執行快。
⑷ MSSQL資料庫.MDF太大導致一查詢伺服器資源佔用非常厲害，如何是好
有多少條記錄？
如果mssql不行，可以用oracle
我不知道你的mssql有沒有打補丁，如果中了sql蠕蟲機器也會變慢的。
⑸ 大家有沒有做過,定時sqlserver把sql查詢出來的結果保存在伺服器的一個文件夾下,用csv方式.
在sql管理器中，打開sqlserver代理，選擇作業，--》新增作業。根據步驟，輸入導出文件的語句，設置執行排程。啟用就可以了
導出文件語句參考：http://wenku..com/link?url=I0tuXfQUM55qA2_RmY-DOGXrx21UgpXf2b7D_
⑹ sql資料庫伺服器，內存佔用過大怎麼辦
SqlServer系統內存管理在沒有配置內存最大值，很多時候我們會發現運行SqlServer的系統內存往往居高不下。這是由於他對於內存使用的策略是有多少閑置的內存就佔用多少，直到內存使用慮達到系統峰值時（預留內存根據系統默認預留使用為准，至少4M），才會清除一些緩存釋放少量的內存為新的緩存騰出空間。
這些內存一般都是SqlServer運行時候用作緩存的，例如你運行一個select語句，執行個存儲過程，調用函數；
1.數據緩存：執行個查詢語句，SqlServer會將相關的數據頁（SqlServer操作的數據都是以頁為單位的）載入到內存中來，下一次如果再次請求此頁的數據的時候，就無需讀取磁碟了，大大提高了速度。
2.執行命令緩存：在執行存儲過程，自定函數時，SqlServer需要先二進制編譯再運行，編譯後的結果也會緩存起來，再次調用時就無需再次編譯。
在我們執行完相應的查詢語句，或存儲過程，如果我們不在需要這些緩存，我可以將它清除，DBCC管理命令緩存清除如下：
--清除存儲過程緩存
DBCCFREEPROCCACHE
--註：方便記住關鍵字FREEPROCCACHE可以拆解成FREE(割捨，清除)PROC（存儲過程關鍵字簡寫），CACHE（緩存）
--清除會話緩存
DBCCFREESESSIONCACHE
--註：FREE(割捨，清除)SESSION（會話）CACHE（緩存）
--清除系統緩存
DBCCFREESYSTEMCACHE('All')
--註：FREESYSTEMCACHE
--清除所有緩存
DBCCDROPCLEANBUFFERS
--註：DROPCLEANBUFFERS
⑺ SQL資料庫容量大，查詢速度慢，有何解決方案
首先應該確定是誰慢的，往往是程序處理方面的問題而不是資料庫的問題。
程序方面應該盡可能的減少數據查詢返回的內容，比如可以查詢返回ID，然後再根據ID一條一條的查詢具體內容，看似慢了，在數據量達的時候快很多
對於數據可以參照下面幾點
1、優化SQL語句，SQL語句對查詢速度影響最大
2、對於經常查詢的欄位作索引。但是這樣會增加修改時的壓力
4、優化SQLServer，比如給其分配固定的內存，預先分配查詢內存，調整CPU使用率等。
5、優化硬體資源，比如使用更高的伺服器或者硬碟，獨立安排資料庫的數據文件和索引文件，將數據文件分布於不同的物理硬碟上等等
6、考慮使用分布資料庫或者對大表進行拆分
另外，2G的資料庫應該不算很大了，我處理過18G的資料庫，8000萬條記錄，查詢速度可以被接受
⑻ 伺服器負載量過大，怎樣處理
一，確認伺服器硬體是否足夠支持當前的流量。
二，優化資料庫訪問。
伺服器的負載過大，一個重要的原因是CPU負荷過大，降低伺服器CPU的負荷，才能夠有效打破瓶頸。而使用靜態頁面可以使得CPU的負荷最小化。前台實現完全的靜態化當然最好，可以完全不用訪問資料庫，不過對於頻繁更新的網站，靜態化往往不能滿足某些功能。
緩存技術就是另一個解決方案，就是將動態數據存儲到緩存文件中，動態網頁直接調用這些文件，而不必再訪問資料庫，WordPress和Z-Blog都大量使用這種緩存技術。
如果確實無法避免對資料庫的訪問，那麼可以嘗試優化資料庫的查詢SQL.避免使用Select *from這樣的語句，每次查詢只返回自己需要的結果，避免短時間內的大量SQL查詢。
三，禁止外部的盜鏈。
外部網站的圖片或者文件盜鏈往往會帶來大量的負載壓力，因此應該嚴格限制外部對於自身的圖片或者文件盜鏈，好在目前可以簡單地通過refer來控制盜鏈，Apache自己就可以通過配置來禁止盜鏈，IIS也有一些第三方的ISAPI可以實現同樣的功能。當然，偽造refer也可以通過代碼來實現盜鏈，不過目前蓄意偽造refer盜鏈的還不多，可以先不去考慮，或者使用非技術手段來解決，比如在圖片上增加水印。
四，控制大文件的下載。
大文件的下載會佔用很大的流量，並且對於非SCSI硬碟來說，大量文件下載會消耗CPU，使得網站響應能力下降。因此，盡量不要提供超過2M的大文件下載，如果需要提供，建議將大文件放在另外一台伺服器上。
⑼ sql如何查詢一段時間內每個周期裡面數值最大的數據
10秒計算公式如下
select
sysdate,sysdate+
10/24/60/60
from
al；
select
*
from
table_name
where
欄位>=sysdate
and
欄位
<=
sysdate+
10/24/60/60
;
如果要進行10秒為周期查詢一次數據，數據需要寫入到臨時表，資料庫會專壓力很大
需要做個定時運
屬行
就可以了