sqlserver查詢速度-九游会j9娱乐平台
如果有時間欄位,建議做分區表,按時間分區,這樣表從物理上是分開的,但是對外還是一張表.
好處有1.原本的代碼結構不用變2.查詢歷史數據的時候,速度仍然有保障3.如果建立觸發器進行自動分區,理論上不管再用多少年,都不會再需要重新建表a2了
② 如何提高sql server大數據條件下的查詢速度
1.關於索引優化
建索引的選擇必須結合sql查詢、修改、刪除語句的需要，一般的說法是在where里經常出現的欄位建索引。如果在where經常是幾個欄位一起出現而且是用and連接的，那就應該建這幾個欄位一起的聯合索引，而且次序也需要考慮，一般是最常出現的放前面，重復率低的放前面。
sql
server提供了一種簡化並自動維護資料庫的工具。這個稱之為資料庫維護計劃向導（database
maintenance
plan
wizard
，dmpw）的工具也包括了對索引的優化。如果你運行這個向導，你會看到關於資料庫中關於索引的統計量，這些統計量作為日誌工作並定時更新，這樣就減輕了手工重建索引或者dbcc
indexdefrag所帶來的工作量。如果你不想自動定期刷新索引統計量，你還可以在dmpw中選擇重新組織數據和數據頁，這將停止舊有索引並按特定的填充因子重建索引。
2.
改善硬體（雙cpu，raid
5，增加內存）
tempdb這個臨時資料庫，它對性能的影響較大。tempdb和其他資料庫一樣可以增大，可以縮小。當數據文件需要增長的時候，通常不能保持剩餘部分的連續性。這時文件就會產生碎片，這種碎片會造成性能下降。這種碎片屬於外來性碎片。要阻止在tempdb中產生外來性碎片，必須保證有足夠的硬碟空間。一般將tempdb的容量放到平均使用容量。而你也應該允許tempdb自動增長，比如你有個一個超大的join操作，它建立了一個超過tempdb容量的時候，該查詢將失敗。你還要設置一個合理的單位增長量。因為如果你設得太小，將會產生許多外來性碎片，反而會佔用更多資源。sqlserver調優最有效的做法之一，就是把爭奪資源的操作獨立出去。tempdb就是一個需要獨立出去的部分而tempdb和其他系統庫一樣是公用的，是存取最可能頻繁的庫，所有處理臨時表、子查詢、group
by、排序、distinct、連接等等。它最適合放到一個具有快速讀寫能力的設備上。比如raid0卷或raid0 1卷上。
查詢語句一定要使用存儲過程；
3、查詢盡量使用top子句
4.將表按一定的約束分成子表,(如按分類)創建約束,在用like
時,先用分類
and
like
,
應該可能解決問題.
而且效果立稈見影!(你要確定sql會認識你建的分區視圖).我一個表有上百萬的記錄(700兆),用分區視圖後,查詢速度基本跟10萬行一樣.
如果還是太慢,還可以考濾分布式分區視圖!這總可以解決問題了吧!
關鍵在於你能否把大表按某種約束分解成子表.
③ sql資料庫容量大，查詢速度慢，有何解決方案
首先應該確定是誰慢的，往往是程序處理方面的問題而不是資料庫的問題。
程序方面應該盡可能的減少數據查詢返回的內容，比如可以查詢返回id，然後再根據id一條一條的查詢具體內容，看似慢了，在數據量達的時候快很多
對於數據可以參照下面幾點
1、優化sql語句，sql語句對查詢速度影響最大
2、對於經常查詢的欄位作索引。但是這樣會增加修改時的壓力
4、優化sqlserver，比如給其分配固定的內存，預先分配查詢內存，調整cpu使用率等。
5、優化硬體資源，比如使用更高的伺服器或者硬碟，獨立安排資料庫的數據文件和索引文件，將數據文件分布於不同的物理硬碟上等等
6、考慮使用分布資料庫或者對大表進行拆分
另外，2g的資料庫應該不算很大了，我處理過18g的資料庫，8000萬條記錄，查詢速度可以被接受
④ 如何優化sqlserver 資料庫性能優化
sql server資料庫查詢速度慢的原因有很多，常見的有以下幾種：
1、沒有索引或者沒有用到索引(這是查詢慢最常見的問題，是資料庫設計的缺陷)
2、i/o吞吐量小，形成了瓶頸效應。
3、沒有創建計算列導致查詢不優化。
4、內存不足
5、網路速度慢
6、查詢出的數據量過大（可以採用多次查詢，其他的方法降低數據量）
7、鎖或者死鎖(這也是查詢慢最常見的問題，是程序設計的缺陷)
8、sp_lock,sp_who,活動的用戶查看,原因是讀寫競爭資源。
9、返回了不必要的行和列
10、查詢語句不好，沒有優化
⑤ sqlserver，表已添加索引，是否仍會隨著數據量不斷不斷增大而查詢越來越慢
無論哪一種資料庫，只要數據量不斷增大都會逐漸變慢，有時候數據到一個量級
速度會斷壁式下跌。
一般是直接從表查詢快。已經是索引列了。但是第一個查詢如果數據不存在還是要遍歷其他的表。這樣速度就大打折扣了。
如果能保證數據一定在指定表中就是第一個快了。
大體分為如下幾種情況會逆襲：
1、這個就是數據不存在，如果挨個遍歷表，速度可能不如使用視圖。
2、使用索引視圖技術，這個跟使用表查詢速度相差不大。
3、sqlserver是高級版本，可以發揮多cpu優勢，這個時候速度也相差不大。
4、索引碎片過多集中在的某三四個表以上，這時候性能都比較沮喪。
看如上，因為我這個是32核cpu，多並行幾個時間只是略多一點，如果單表查詢，那麼執行計劃就是一個分支。
⑥ 請問sqlserver mysql oracle各有什麼優缺點它們一張表最多能容納多少條記錄速度誰最快價格如何呢
sqlserver 使用簡單，界面友好， 而且單從數據處理速度上看，sqlserver最快，要高於mysql 和 oracle 的，
個人做過測試， 千萬級的表，在不做索引的情況下， sqlserver2005 檢查起來不會很費力，
一般的查檢，包括嵌套，搜索時間基本能控制在1分鍾內， 而mysql基本就跑不動， 在建索引的情況下，也不如sqlserver速度快。 而oracle 似乎也不是很理想，速度也不如sqlserver， 也許
億級以上的數據量會比較穩定，但千萬級時沒有sqlserver 快。
缺點：不開源，不跨平台
mysql 好處是開源免費，有能力的話可以自己開發與拓民， 這也是現在為什麼那麼多大企業都用mysql 的原因之一。
缺點：慢慢慢。
oracle 的好處大家都知道了， 大型專業資料庫平台，很多第三方的支持。
⑦ 如何解決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 查詢的優化，添加更合適的索引可以避免性能問題：執行計劃使用索引並不意味著就能執行快。