sqlserver大數據優化

1. Net+SqlServer 怎麼解決 大數據量 高並發問題

凡是大型的系統，必然要分庫，也就是根據邏輯進行數據拆分。比如用戶的數據版，你可以權根據用戶所在的省份劃分，一個省份一個資料庫，只有這樣才能真正的保證大數量的並發。
另外要有效的利用讀寫分離，讀寫分離用sql server 2012的話可以直接用always on，一個用來寫，若干用來讀。資料庫自身會保證數據的一致性的，這樣就不會出現查備份庫數據還沒同步過來的問題了。

2. sqlserver大數據量update問題

我拿到sql一看是update語句，想都沒多想直接加並行，但是加了並行發現子查詢根本沒有用到並行，而且整體cost沒有什麼變化。我仔細想了想，這種寫法oracle內部是通過單條跟新的方式進行，從p_t中那出一條記錄去c_t中匹配，c_t中採用索引掃描，然後再通過rowid訪問表取到name。所以優化器計算後，不會對子查詢中的c_t應用並行，因為此時並行會採用全表掃描，效率肯定沒有索引掃描快。語句和執行計劃如下：
update /*+parallel(p_t,4)*/ p_t set name=(select /*+parallel(c_t,4)*/ name from c_t where p_t.id=c_t.id) where p_t.name is null;

3. 如何優化Sql server 大數據量時使用 like 查詢的速度或有什麼別的方法實現模糊查詢

傻逼啊，誰看了這個文章就是誤人子弟 方案1：主鍵Id，默認為聚集索引，不建立其它非聚集索引select * from News where Title like '%"&abigale&"%' or Author like '%"&abigale&"%' order by Id desc從欄位Title和Author中模糊檢索，按Id排序查詢時間：50秒方案2：主鍵Id，默認為聚集索引在Title、Author、Star上建立非聚集索引select * from News where Title like '"&abigale&"%' or Author like '"&abigale&"%' order by Id desc從欄位Title和Author中模糊檢索，按Id排序查詢時間：2 - 2.5秒 看到沒有，那個50秒用的是 '%"&abigale&"%'來的，兩個百分號會引發全表掃描而那個快的是 '"&abigale&"%' ，這樣就使用索引 不用索引和用索引完全兩個概念，尼瑪還在說優化，優化你妹

4. SQLSERVER大資料庫解決方案

在微軟的大數據解決方案中，數據管理是最底層和最基礎的一環。

靈活的數據管理層，可以支持所有數據類型，包括結構化、半結構化和非結構化的靜態或動態數據。

在數據管理層中主要包括三款產品：SQLServer、SQLServer並行數據倉庫和

Hadoop on Windows。

針對不同的數據類型，微軟提供了不同的解決方案。

具體來說，針對結構化數據可以使用SQLServer和SQLServer並行數據倉庫處理。

非結構化數據可以使用Windows Azure和WindowsServer上基於Hadoop的發行版本處理;而流數據可以使用SQLServerStreamInsight管理，並提供接近實時的分析。

1、SQLServer。去年發布的SQLServer2012針對大數據做了很多改進，其中最重要的就是全面支持Hadoop，這也是SQLServer2012與SQLServer2008最重要的區別之一。今年年底即將正式發布的SQLServer2014中，SQLServer進一步針對大數據加入內存資料庫功能，從硬體角度加速數據的處理，也被看為是針對大數據的改進。

2、SQLServer並行數據倉庫。並行數據倉庫(Parallel Data Warehouse Appliance，簡稱PDW)是在SQLServer2008 R2中推出的新產品，目前已經成為微軟主要的數據倉庫產品，並將於今年發布基於SQLServer2012的新款並行數據倉庫一體機。SQLServer並行數據倉庫採取的是大規模並行處理(MPP)架構，與傳統的單機版SQLServer存在著根本上的不同，它將多種先進的數據存儲與處理技術結合為一體，是微軟大數據戰略的重要組成部分。

3、Hadoop on Windows。微軟同時在Windows Azure平台和WindowsServer上提供Hadoop，把Hadoop的高性能、高可擴展與微軟產品易用、易部署的傳統優勢融合到一起，形成完整的大數據解決方案。微軟大數據解決方案還通過簡單的部署以及與Active Directory和System Center等組件的集成，為Hadoop提供了Windows的易用性和可管理性。憑借Windows Azure上基於Hadoop的服務，微軟為其大數據解決方案在雲端提供了靈活性。

5. 如何做SqlServer 數據查詢優化！

影響查詢效率的因素
SQLServer處理查詢計劃的過程是這樣的：在做完查詢語句的詞法、語法檢查之後，將語句提交給SQLServer的查詢優化器，查詢優化器通過檢查索引的存在性、有效性和基於列的統計數據來決定如何處理掃描、檢索和連接，並生成若干執行計劃，然後通過分析執行開銷來評估每個執行計劃，從中選出開銷最小的執行計劃,由預編譯模塊對語句進行處理並生成查詢規劃，然後在合適的時間提交給系統處理執行，最後將執行結果返回給用戶。所以，SQLServer中影響查詢效率的因素主要有以下幾種：
1．沒有索引或者沒有用到索引。索引是資料庫中重要的數據結構，使用索引的目的是避免全表掃描，減少磁碟I/O，以加快查詢速度。
2．沒有創建計算列導致查詢不優化。
3．查詢出的數據量過大（可以採用多次查詢，其他的方法降低數據量）。
4．返回了不必要的行和列。
5．查詢語句不好，沒有優化。其中包括：查詢條件中操作符使用是否得當;查詢條件中的數據類型是否兼容;對多個 表查詢時,數據表的次序是否合理;多個選擇條件查詢時,選擇條件的次序是否合理;是否合理安排聯接選擇運算等。

SQLServer數據查詢優化方法
3.1建立合適的索引索引是資料庫中重要的數據結構，它的根本目的就是為了提高查詢效率。當根據索引碼的值搜索數據時，索引提供了對數據的快速訪問。事實上，沒有索引,資料庫也能根據SELECT語句成功地檢索到結果，但隨著表變得越來越大，使用「適當」的索引的效果就越來越明顯。索引的使用要恰到好處，其使用原則有：
(1)對於基本表，不宜建立過多的索引；
(2)對於那些查詢頻度高，實時性要求高的數據一定要建立索引，而對於其他的數據不考慮建立索引；
(3)在經常進行連接，但是沒有指定為外鍵的列上建立索引；
(4)在頻繁進行排序或分組（即進行groupby或 orderby操作）的列上建立索引；
(5)在條件表達式中經常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。比如在雇員表的「性別」列上只有「男」與「女」兩個不同值，因此就無必要建立索引。如果建立索引不但不會提高查詢效率，反而會嚴重降低更新速度；
(6)如果待排序的列有多個，可以在這些列上建立復合索引。在SQLServer中，索引按索引表達式包含的列分為單列索引和復合索引。檢查查詢語句的where子句，因為這是優化器重要關注的地方。包含在where裡面的每一列都是可能的侯選索引，為能達到最優的性能，例如：對於在where子句中給出了 column1這個列，下面的兩個條件可以提高索引的優化查詢性能！
第一：在表中的column1列上有一個單索引；
第二：在表中有多索引，但是 column1是第一個索引的列。避免定義多索引而column1是第二個或後面的索引，這樣的索引不能優化伺服器性能。例如：下面的例子用了pubs資料庫。SELECTau_id,au_lname,au_fnameFROMauthorsWHEREau_lname=』White』按下面幾個列上建立的索引將會是對優化器有用的索引au_lnameau_lname,au_fname而在下面幾個列上建立的索引將不會對優化器起到好的作用au_addressau_fname,au_lname在SQLServer中，索引按存儲結構分為聚簇索引和非聚簇索引。聚簇索引是按照定義數據列值的順序在物理上對記錄排序，在一個表上只能有一個聚簇索引，聚簇索引查詢速度較快，但缺點是對表進行修改操作時速度較慢，因為為了保證表中記錄的物理順序與索引的順序一致，必須將記錄插入到數據頁的相應位置，從而數據頁中的數據必須重排。在下面的幾個情況下，可以考慮用聚簇索引：
(1)某列包括的不同值的個數是有限的（但是不是極少的）。如顧客表的州名列有50個左右的不同州名的縮寫值，可以使用聚簇索引。
(2)對返回一定范圍內值的列可以使用聚簇索引，如用between,>,>=, Select*fromsaleswhereord_datebetween』5/1/93』and』6/1/93』
(3)對查詢時返回大量結果的列可以使用聚簇索引。SELECT*FROMphonebookWHERElast_name=』Smith』當有大量的行正在被插入表中時，要避免在本表一個自然增長（例如，identity列）的列上建立聚簇索引。如果你建立了聚簇的索引，那麼insert的性能就會大大降低。因為每一個插入的行必須到表的最後，表的最後一個數據頁。
非聚簇索引指定表中的邏輯順序，一個表上可以建立多達249個非聚簇索引，它查詢的速度比不建立索引快，但比聚簇索引慢，插入數據比聚簇索引快，因為紀錄直接被追加到數據末尾。可以在以下情況下考慮使用非聚簇索引。
(1)在有很多不同值的列上可以考慮使用非聚簇索引，如employee表中的emp_id列可以建立非聚簇索引。
(2)查詢結果集返回的是少量或單行的結果集。例如
select*fromemployeewhereemp_id=』pcm9809f』
(3)查詢語句中orderby子句的列上可以考慮使用非聚簇索引。

3.2常用的計算欄位(如總計、最大值等)可以考慮存儲到資料庫實體中。例如倉庫管理系統中有材料入庫表，其欄位為:材料編號、材料名稱、型號，單價，數量…，而金額是用戶經常需要在查詢和報表中用到的，在表的記錄量很大時，有必要把金額作為一個獨立的欄位加入到表中。這里可以採用觸發器以在客戶端保持數據的一致性。

3.3用where子句來限制必須處理的行數。在執行一個查詢時，用一個where子句來限制必須處理的行數，除非完全需要，否則應該避免在一個表中無限制地讀並處理所有的行。例如：||| select qty from sales where stor_id=』7131』是很有效的，比無限制的查詢selectqtyfromsales有效，避免給客戶的最後數據選擇返回大量的結果集。當然也可以用TOP限制返回結果集的行數。

3.4盡量使用數字型欄位。一部分開發人員和資料庫管理人員喜歡把包含數值信息的欄位設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接回逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。

3.5查詢語句的優化。對於一條復雜的查詢語句來說，對相同查詢條件的實現一般總可以有多種不同的表達方法，而不同的表達會使資料庫的響應速度大相徑庭。據統計，約有80%以上的性能問題是由於使用了不恰當的查詢語句造成的，因此SQL語句的質量對整個系統效率有重大關系。
下面介紹查詢語句優化方面的一些技巧:
(1)避免使用不兼容的數據類型。例如float和int、char和varchar、 binary和varbinary是不兼容的。數據類型的不兼容可能使優化器無法執行一些本來可以進行的優化操作。例如: ＞60000在這條語句中,如salary欄位是money型的,則優化器很難對其進行優化,因為60000是個整型數。這條語句可以改為：＞$60000
(2)盡量避免在Where條件里使用非聚合表達式,因為非聚合表達式很難利用到索引，通常SQLServer不得不進行大規模的掃描。像!=或＜＞、 ISNULL或ISNOTNULL、IN，NOTIN等這樣的操作符構成的表達式都是非聚合表達式。非聚合表達式會導致查詢效率大大降低。例如: SELECTidFROMemployeeWHEREid!='B%'優化器將無法通過索引來確定將要命中的行數,因此需要搜索該表的所有行。
(3)盡量避免在WHERE子句中對欄位進行函數或表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
SELECT*FROMemployeeWHEREsalary/2=100應改為:
SELECT*FROMemployeeWHEREsalary=100*2 SELECT*FROMemployeeWHERESUBSTRING(emp_id,1,3)=』PCM』應改為:
SELECT*FROMemployeeWHEREemp_idLIKE『5378%』 SELECTmember_number,first_name,last_nameFROMmembers WHEREDATEDIFF(yy,datofbirth,GETDATE())>21應改為:
SELECT member_number,first_name,last_name FROM members WHERE dateofbirth即：任何對列的操作都將導致表掃描，它包括資料庫函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊。
(4)避免使用LEFTJOIN SQL的一個有價值的常用功能是LEFTJOIN。它可以用於檢索第一個表中的所有行、第二個表中所有匹配的行、以及第二個表中與第一個表中不匹配的所有行。例如，如果希望返回每個客戶及其定單，使用LEFTJOIN則可以顯示有定單和沒有定單的客戶。LEFTJOIN消耗的資源非常之多，因為它們包含與 NULL（不存在）數據匹配的數據。因此在構造查詢語句時盡量避免使用LEFTJOIN。
(5)盡量避免在索引過的字元數據中，使用非打頭字母搜索。這也使得引擎無法利用索引。見如下例子：
SELECT*FROMmembersWHEREfirst_nameLIKE『%MA%』 SELECT*FROMmembersWHERESUBSTING(first_name,3,1)=』MA』 SELECT*FROMmembersWHEREfirst_nameLIKE『MA%』即使NAME欄位建有索引，前兩個查詢依然無法利用索引完成加快操作，引擎不得不對全表所有數據逐條操作來完成任務。而第三個查詢能夠使用索引來加快操作。(6)避免相關子查詢一個列的標簽同時在主查詢和 WHERE子句中的查詢中出現，那麼很可能當主查詢中的列值改變之後，子查詢必須重新查詢一次。查詢嵌套層次越多，效率越低，因此應當盡量避免子查詢。可 以採用子查詢「展平」技術，將子查詢轉變為連接,半連接或反連接,從而達到優化查詢的目的。例如查詢找出有工資超過10000的職工所在的部門名稱。 SELECT部門名FROM部門WHERE部門號IN(SELECT部門號FROM職工WHERE工資>10000)此查詢將掃描部門表的 每一行查找所有滿足子查詢條件的職工記錄。可以將部門表作為連接的內表,在這種情況下,查詢作為通常的連接來執行,首先對職工表進行唯一的部門號篩選,以 消除冗餘的部門號，轉化後的語句為:SELECTB.部門名FROM(SELECTDISTINCT部門號FROM職工WHERE工 資>10000,部門DWHEREB.部門號=D.部門號對於SQL語句的優化方法還有很多，在這里就不一一例舉了。

6. 如何提高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萬行一樣.
如果還是太慢,還可以考濾分布式分區視圖!這總可以解決問題了吧!
關鍵在於你能否把大表按某種約束分解成子表.