1.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
2.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。優化器簡悉將無法通過索引來確定將要命中的行數,因此需要搜索該表的所有行。
3.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
4.in 和 not in 也要慎用，因為IN會使系統無法使用索引,而只能直接搜索表中的數據。如：
select id from t where num in(1,2,3)
對於連續的數值，能用 beeen 就不要用 in 了：
select id from t where num beeen 1 and 3
5.盡量避免在索引過的字元數據中，使用非打頭字母搜索。這也使得引擎無法利用索引。
見如下例子：
SELECT * FROM T1 WHERE NAME LIKE 『%L%』
SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=』L』
SELECT * FROM T1 WHERE NAME LIKE 『L%』
即使NAME欄位建有索引，前兩個查詢依然無法利用索引完成加快操作，引擎不得不對全表所有數據逐條操作來完成任務。而第三個查詢能夠使用索引來加快操作。
6.必要時強制查詢優化器使用某個索引，如在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變數的值還是未散罩知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id from t where num=@num
可以改為強制查詢使用索引：
select id from t with(index(索引名)) where num=@num
7.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
SELECT * FROM T1 WHERE F1/2=100
應改為:
SELECT * FROM T1 WHERE F1=100*2
SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=』5378』
應改為:
SELECT * FROM RECORD WHERE CARD_NO LIKE 『5378%』
SELECT member_number, first_name, last_name FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21
應改為:
SELECT member_number, first_name, last_name FROM members
WHERE dateofbirth < DATEADD(yy,-21,GETDATE())
即：任何對列的操作都將導致表掃描，它包括資料庫函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊。
8.應盡量避免在where子句中對欄位進行沖咐鬧函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)='abc'--name以abc開頭的id
select id from t where datediff(day,createdate,-11-30')=0--『2005-11-30』生成的id
應改為:
select id from t where name like 'abc%'
select id from t where createdate>=-11-30' and createdate<-12-1'
9.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
10.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致。
11.很多時候用 exists是一個好的選擇：
elect num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
SELECT SUM(T1.C1)FROM T1 WHERE(
(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)
SELECT SUM(T1.C1) FROM T1WHERE EXISTS(
SELECT * FROM T2 WHERE T2.C2=T1.C2)
兩者產生相同的結果，但是後者的效率顯然要高於前者。因為後者不會產生大量鎖定的表掃描或是索引掃描。
Statement stmt = null;
ResultSet rs = null;
String query = "select 列名 from 表名 where id=11 and fname='xx' order by 列名 desc limit 1";
stmt = conn.createStatement();
rs = stmt.executeQuery(query);
if (rs.next()) {
result = rs.getInt("列名");
}
樓上的 拼寫錯誤，我來修正 ^^
select count(*) from 表名
傳統資料庫處理大數據很困難吧，不建議使用傳統資料庫來處理大數據。
建議研究下，Hadoop，Hive等，可處理大數據。
如果有預算，可以使用一些商業大數據產品，國內的譬如永洪科技的大數據BI產品，不僅能高性能處理大數據，還可做數據分析。
當然如果是簡單的查詢，傳統資料庫如果做好索引，可能可以提高性能。
有兩種方法
方法1：
select 100 * from tbllendlist where fldserialNo not in ( select 300100 fldserialNo from tbllendlist order by fldserialNo ) order by fldserialNo
方法2：
SELECT TOP 100 * FROM tbllendlist WHERE (fldserialNo > (SELECT MAX(fldserialNo) FROM (SELECT TOP 300100 fldserialNo FROM tbllendlist ORDER BY fldserialNo) AS T)) ORDER BY fldserialNo
影響命中率的因素有四種：字典表活動、臨時段活動、回滾段活動、表掃描， 應用DBA可以對這四種因素進行分析，找出資料庫命中率低的症結所在。 1)字典表活動 當一個SQL語句第一次到達Oracle內核時資料庫對SQL語句進行分析，包含在查詢中的數據字典對象被分解，產生SQL執行路徑。如果SQL語句指向一個不在SGA中的對象?表或視圖，Oracle執行SQL語句到數據典中查詢有關對象的信息。數據塊從數據字典表被讀取到SGA的數據緩存中。由於每個數據字典都很小，因此，我們可緩存這些表以提高對這些表的命中率。但是由於數據字典表的數據塊在SGA中占據空間，當增加全部的命中率時，它們會降低表數據塊的可用空間， 所以若查詢所需的時間字典信息已經在SGA緩存中，那麼就沒有必要遞歸調用。 2)臨時段的活動 當用戶執行一個需要排序的查詢時，Oracle設法對內存中排序區內的所有行進行排序，排序區的大小由資料庫的init.ora文件的數確定。如果排序區域不夠大，資料庫就會在排序操作期間開辟臨時段。臨時段會人為地降低OLTP(online transaction processing）應用命中率,也會降低查詢進行排序的性能。如果能在內存中完成全部排序操作，就可以消除向臨時段寫數據的開銷。所以應將SORT_AREA_SIZE設置得足夠大，以避免對臨時段的需要。這個參數的具體調整方法是:查詢相關數據，以確定這個參數的調整。 select * from v$sysstat where name='sorts(disk)'or name='sorts(memory); 大部分排序是在內存中進行的，但還有小部分發生在臨時段， 需要調整 值，查看init.ora文件的 SORT_AREA_SIZE值，參數為：SORT_AREA_SIZE＝65536;將其調整到SORT_AREA_SIZE＝131072、這個值調整後，重啟ORACLE資料庫即可生效。 3)回滾段的活動 回滾段活動分為回滾活動和回滾段頭活動。對回滾段頭塊的訪問會降低應用的命中率， 對OLTP系統命中率的影響最大。為確認是否因為回滾段影響了命中率，可以查看監控輸出報表中的「數據塊相容性讀一重寫記錄應用」 的統計值，這些統計值是用來確定用戶從回滾段中訪問數據的發生次數。 4)表掃描 通過大掃描讀得的塊在數據塊緩存中不會保持很長時間， 因此表掃描會降低命中率。為了避免不必要的全表掃描，首先是根據需要建立索引，合理的索引設計要建立人對各種查詢的分析和預測上，筆者會在SQL優化中詳細談及；其次是將經常用到的表放在內存中，以降低磁碟讀寫次數。
1. SQL優化的原則是：將一次操作需要讀取的BLOCK數減到最低,即在最短的時間達到最大的數據吞吐量。
調整不良SQL通常可以從以下幾點切入：
? 檢查不良的SQL，考慮其寫法是否還有可優化內容
? 檢查子查詢 考慮SQL子查詢是否可以用簡單連接的方式進行重新書寫
? 檢查優化索引的使用
? 考慮資料庫的優化器
2. 避免出現SELECT * FROM table 語句，要明確查出的欄位。
3. 在一個SQL語句中，如果一個where條件過濾的資料庫記錄越多，定位越准確，則該where條件越應該前移。
4. 查詢時盡可能使用索引覆蓋。即對SELECT的欄位建立復合索引，這樣查詢時只進行索引掃描，不讀取數據塊。
5. 在判斷有無符合條件的記錄時建議不要用SELECT COUNT （*）和select 1 語句。
6. 使用內層限定原則，在拼寫SQL語句時，將查詢條件分解、分類，並盡量在SQL語句的最里層進行限定，以減少數據的處理量。
7. 應絕對避免在order by子句中使用表達式。
8. 如果需要從關聯表讀數據，關聯的表一般不要超過7個。
9. 小心使用 IN 和 OR，需要注意In集合中的數據量。建議集合中的數據不超過200個。
10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，這樣可以有效的利用索引。
11. 在查詢時盡量減少對多餘數據的讀取包括多餘的列與多餘的行。
12. 對於復合索引要注意，例如在建立復合索引時列的順序是F1，F2，F3，則在where或order by子句中這些欄位出現的順序要與建立索引時的欄位順序一致，且必須包含第一列。只能是F1或F1，F2或F1，F2，F3。否則不會用到該索引。
13. 多表關聯查詢時，寫法必須遵循以下原則，這樣做有利於建立索引，提高查詢效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值條件（=）) and (table1的非等值條件) and (table2與table1的關聯條件) and (table2的等值條件) and (table2的非等值條件) and (table3與table2的關聯條件) and (table3的等值條件) and (table3的非等值條件)。
注:關於多表查詢時from 後面表的出現順序對效率的影響還有待研究。
14. 子查詢問題。對於能用連接方式或者視圖方式實現的功能，不要用子查詢。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。應該用如下語句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。
15. 在WHERE 子句中，避免對列的四則運算，特別是where 條件的左邊，嚴禁使用運算與函數對列進行處理。比如有些地方 substring 可以用like代替。
16. 如果在語句中有not in（in）操作，應考慮用not exists（exists）來重寫,最好的辦法是使用外連接實現。
17. 對一個業務過程的處理，應該使事物的開始與結束之間的時間間隔越短越好，原則上做到資料庫的讀操作在前面完成，資料庫寫操作在後面完成，避免交叉。
18. 請小心不要對過多的列使用列函數和order by,group by等，謹慎使用disti軟體開發t。
19. 用union all 代替 union，資料庫執行union操作，首先先分別執行union兩端的查詢，將其放在臨時表中，然後在對其進行排序，過濾重復的記錄。
當已知的業務邏輯決定query A和query B中不會有重復記錄時，應該用union all代替union，以提高查詢效率。
數據更新的效率
1. 在一個事物中，對同一個表的多個insert語句應該集中在一起執行。
2. 在一個業務過程中，盡量的使insert,update,delete語句在業務結束前執行，以減少死鎖的可能性。
資料庫物理規劃的效率
為了避免I/O的沖突，我們在設計資料庫物理規劃時應該遵循幾條基本的原則(以ORACLE舉例)：
?? table和index分離：table和index應該分別放在不同的tablespace中。
?? Rollback Segment的分離：Rollback Segment應該放在獨立的Tablespace中。
?? System Tablespace的分離：System Tablespace中不允許放置任何用戶的object。（mssql中primary filegroup中不允許放置任何用戶的object）
?? Temp Tablesace的分離：建立單獨的Temp Tablespace，並為每個user指定default Temp Tablespace
??避免碎片：但segment中出現大量的碎片時，會導致讀數據時需要訪問的block數量的增加。對經常發生DML操作的segemeng來說，碎片是不能完全避免的。所以，我們應該將經常做DML操作的表和很少發生變化的表分離在不同的Tablespace中。
當我們遵循了以上原則後，仍然發現有I/O沖突存在，我們可以用數據分離的方法來解決。
?? 連接Table的分離：在實際應用中經常做連接查詢的Table，可以將其分離在不同的Taclespace中，以減少I/O沖突。
?? 使用分區：對數據量很大的Table和Index使用分區，放在不同的Tablespace中。
在實際的物理存儲中，建議使用RAID。日誌文件應放在單獨的磁碟中。
給出你的查詢，然後才可以對其進行優化
如果你的查詢比較固定，並且查詢的條件區別度較高，可以建立相應的索引。
其他的一些規則，比如使用exists代替 in都可以試試
查詢速度慢的原因很多，常見如下幾種：
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）。索引應該盡量小，使用位元組數小的列建索引好（參照索引的創建）,不要對有限的幾個值的欄位建單一索引如性別欄位
5、提高網速;
6、擴大伺服器的內存,Windows 2000和SQL server 2000能支持4-8G的內存。配置虛擬內存：虛擬內存大小應基於計算機上並發運行的服務進行配置。運行 Microsoft SQL Server? 2000 時，可考慮將虛擬內存大小設置為計算機中安裝的物理內存的 1.5 倍。如果另外安裝了全文檢索功能，並打算運行 Microsoft 搜索服務以便執行全文索引和查詢，可考慮：將虛擬內存大小配置為至少是計算機中安裝的物理內存的 3 倍。將 SQL Server max server memory 伺服器配置選項配置為物理內存的 1.5 倍（虛擬內存大小設置的一半）。
7、增加伺服器 CPU個數; 但是必須明白並行處理串列處理更需要資源例如內存。使用並行還是串列程是MsSQL自動評估選擇的。單個任務分解成多個任務，就可以在處理器上運行。例如耽擱查詢的排序、連接、掃描和GROUP BY字句同時執行，SQL SERVER根據系統的負載情況決定最優的並行等級，復雜的需要消耗大量的CPU的查詢最適合並行處理。但是更新操作Update,Insert， Delete還不能並行處理。
8、如果是使用like進行查詢的話，簡單的使用index是不行的，但是全文索引，耗空間。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查詢時，查詢耗時和欄位值總長度成正比,所以不能用CHAR類型，而是VARCHAR。對於欄位的值很長的建全文索引。
9、DB Server 和APPLication Server 分離；OLTP和OLAP分離
10、分布式分區視圖可用於實現資料庫伺服器聯合體。聯合體是一組分開管理的伺服器，但它們相互協作分擔系統的處理負荷。這種通過分區數據形成資料庫伺服器聯合體的機制能夠擴大一組伺服器，以支持大型的多層 Web 站點的處理需要。有關更多信息，參見設計聯合資料庫伺服器。（參照SQL幫助文件'分區視圖'）
a、在實現分區視圖之前，必須先水平分區表
b、在創建成員表後，在每個成員伺服器上定義一個分布式分區視圖，並且每個視圖具有相同的名稱。這樣，引用分布式分區視圖名的查詢可以在任何一個成員伺服器上運行。系統操作如同每個成員伺服器上都有一個原始表的復本一樣，但其實每個伺服器上只有一個成員表和一個分布式分區視圖。數據的位置對應用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數據和日誌 DBCC SHRINKDB,DBCC SHRINKFILE. 設置自動收縮日誌.對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能。在T-sql的寫法上有很大的講究，下面列出常見的要點：首先，DBMS處理查詢計劃的過程是這樣的：
1、 查詢語句的詞法、語法檢查
2、 將語句提交給DBMS的查詢優化器
3、 優化器做代數優化和存取路徑的優化
4、 由預編譯模塊生成查詢規劃
5、 然後在合適的時間提交給系統處理執行
6、 最後將執行結果返回給用戶其次，看一下SQL SERVER的數據存放的結構：一個頁面的大小為8K(8060)位元組，8個頁面為一個盤區，按照B樹存放。
12、Commit和rollback的區別 Rollback:回滾所有的事物。 Commit:提交當前的事物. 沒有必要在動態SQL里寫事物，如果要寫請寫在外面如： begin tran exec(@s) mit trans 或者將動態SQL 寫成函數或者存儲過程。
13、在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的數據，浪費了伺服器的I/O資源，加重了網路的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。
14、SQL的注釋申明對執行沒有任何影響
15、盡可能不使用游標，它佔用大量的資源。如果需要row-by-row地執行，盡量採用非游標技術,如：在客戶端循環，用臨時表，Table變數，用子查詢，用Case語句等等。游標可以按照它所支持的提取選項進行分類： 只進 必須按照從第一行到最後一行的順序提取行。FETCH NEXT 是唯一允許的提取操作,也是默認方式。可滾動性可以在游標中任何地方隨機提取任意行。游標的技術在SQL2000下變得功能很強大，他的目的是支持循環。有四個並發選項 READ_ONLY：不允許通過游標定位更新(Update)，且在組成結果集的行中沒有鎖。 OPTIMISTIC WITH valueS:樂觀並發控制是事務控制理論的一個標准部分。樂觀並發控制用於這樣的情形，即在打開游標及更新行的間隔中，只有很小的機會讓第二個用戶更新某一行。當某個游標以此選項打開時，沒有鎖控制其中的行，這將有助於最大化其處理能力。如果用戶試圖修改某一行，則此行的當前值會與最後一次提取此行時獲取的值進行比較。如果任何值發生改變，則伺服器就會知道其他人已更新了此行，並會返回一個錯誤。如果值是一樣的，伺服器就執行修改。選擇這個並發選項OPTIMISTIC WITH ROW VERSIONING:此樂觀並發控制選項基於行版本控制。使用行版本控制，其中的表必須具有某種版本標識符，伺服器可用它來確定該行在讀入游標後是否有所更改。在 SQL Server 中，這個性能由 timestamp 數據類型提供，它是一個二進制數字，表示資料庫中更改的相對順序。每個資料庫都有一個全局當前時間戳值：@@DBTS。每次以任何方式更改帶有 timestamp 列的行時，SQL Server 先在時間戳列中存儲當前的 @@DBTS 值，然後增加 @@DBTS 的值。如果某 個表具有 timestamp 列，則時間戳會被記到行級。伺服器就可以比較某行的當前時間戳值和上次提取時所存儲的時間戳值，從而確定該行是否已更新。伺服器不必比較所有列的值，只需比較 timestamp 列即可。如果應用程序對沒有 timestamp 列的表要求基於行版本控制的樂觀並發，則游標默認為基於數值的樂觀並發控制。 SCROLL LOCKS 這個選項實現悲觀並發控制。在悲觀並發控制中，在把資料庫的行讀入游標結果集時，應用程序將試圖鎖定資料庫行。在使用伺服器游標時，將行讀入游標時會在其上放置一個更新鎖。如果在事務內打開游標，則該事務更新鎖將一直保持到事務被提交或回滾；當提取下一行時，將除去游標鎖。如果在事務外打開游標，則提取下一行時，鎖就被丟棄。因此，每當用戶需要完全的悲觀並發控制時，游標都應在事務內打開。更新鎖將阻止任何其它任務獲取更新鎖或排它鎖，從而阻止其它任務更新該行。然而，更新鎖並不阻止共享鎖，所以它不會阻止其它任務讀取行，除非第二個任務也在要求帶更新鎖的讀取。滾動鎖根據在游標定義的 Select 語句中指定的鎖提示，這些游標並發選項可以生成滾動鎖。滾動鎖在提取時在每行上獲取，並保持到下次提取或者游標關閉，以先發生者為准。下次提取時，伺服器為新提取中的行獲取滾動鎖，並釋放上次提取中行的滾動鎖。滾動鎖獨立於事務鎖，並可以保持到一個提交或回滾操作之後。如果提交時關閉游標的選項為關，則 COMMIT 語句並不關閉任何打開的游標，而且滾動鎖被保留到提交之後，以維護對所提取數據的隔離。所獲取滾動鎖的類型取決於游標並發選項和游標 Select 語句中的鎖提示。鎖提示 只讀 樂觀數值 樂觀行版本控制 鎖定無提示 未鎖定 未鎖定 未鎖定 更新 NOLOCK 未鎖定 未鎖定未鎖定 未鎖定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 錯誤 更新 更新 更新 TABLOCKX 錯誤 未鎖定 未鎖定更新其它 未鎖定 未鎖定 未鎖定 更新 *指定 NOLOCK 提示將使指定了該提示的表在游標內是只讀的。
16、用Profiler來跟蹤查詢，得到查詢所需的時間，找出SQL的問題所在; 用索引優化器優化索引
17、注意UNion和UNion all 的區別。UNION all好
18、注意使用DISTINCT，在沒有必要時不要用，它同UNION一樣會使查詢變慢。重復的記錄在查詢里是沒有問題的
19、查詢時不要返回不需要的行、列
20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT來限制查詢消耗的資源。當評估查詢消耗的資源超出限制時，伺服器自動取消查詢,在查詢之前就扼殺掉。 SET LOCKTIME設置鎖的時間
21、用select 100 / 10 Percent 來限制用戶返回的行數或者SET ROWCOUNT來限制操作的行
22、在SQL2000以前，一般不要用如下的字句: "IS NULL", "＜＞", "!=", "!＞", "!＜", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'"，因為他們不走索引全是表掃描。也不要在Where字句中的列名加函數，如Convert，substring等,如果必須用函數的時候，創建計算列再創建索引來替代.還可以變通寫法：Where SUBSTRING(firstname,1,1) = 'm'改為Where firstname like 'm%'（索引掃描），一定要將函數和列名分開。並且索引不能建得太多和太大。NOT IN會多次掃描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 來替代，特別是左連接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，現在2000的優化器能夠處理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能優化她，而"＜＞"等還是不能優化，用不到索引。
23、使用Query Analyzer，查看SQL語句的查詢計劃和評估分析是否是優化的SQL。一般的20%的代碼占據了80%的資源，我們優化的重點是這些慢的地方。
24、如果使用了IN或者OR等時發現查詢沒有走索引，使用顯示申明指定索引： Select * FROM PersonMember (INDEX = IX_Title) Where processid IN ('男'，'女')
25、將需要查詢的結果預先計算好放在表中，查詢的時候再Select。這在SQL7.0以前是最重要的手段。例如醫院的住院費計算。
26、MIN() 和 MAX()能使用到合適的索引。
27、資料庫有一個原則是代碼離數據越近越好，所以優先選擇Default,依次為Rules,Triggers, Constraint（約束如外健主健CheckUNIQUE……,數據類型的最大長度等等都是約束）,Procere.這樣不僅維護工作小，編寫程序質量高，並且執行的速度快。
28、如果要插入大的二進制值到Image列，使用存儲過程，千萬不要用內嵌Insert來插入(不知JAVA是否)。因為這樣應用程序首先將二進制值轉換成字元串（尺寸是它的兩倍），伺服器受到字元後又將他轉換成二進制值.存儲過程就沒有這些動作: 方法：Create procere p_insert as insert into table(Fimage) values (@image), 在前台調用這個存儲過程傳入二進制參數，這樣處理速度明顯改善
B. 如何優化操作大數據量資料庫
下面以關系資料庫系統Informix為例，介紹改善用戶查詢計劃的方法。
1．合理使用索引
索引是資料庫中重要的數據結構，它的根本目的就是為了提高查詢效率。現在大多數的資料庫產品都採用IBM最先提出的ISAM索引結構。索引的使用要恰到好處，其使用原則如下：
●在經常進行連接，但是沒有指定為外鍵的列上建立索引，而不經常連接的欄位則由優化器自動生成索引。
●在頻繁進行排序或分組（即進行group by或order by操作）的列上建立索引。
●在條件表達式中經常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。比如在雇員表的「性別」列上只有「男」與「女」兩個不同值，因此就無必要建立索引。如果建立索引不但不會提高查詢效率，反而會嚴重降低更新速度。
●如果待排序的列有多個，可以在這些列上建立復合索引（compound index）。
●使用系統工具。如Informix資料庫有一個tbcheck工具，可以在可疑的索引上進行檢查。在一些資料庫伺服器上，索引可能失效或者因為頻繁操作而使得讀取效率降低，如果一個使用索引的查詢不明不白地慢下來，可以試著用tbcheck工具檢查索引的完整性，必要時進行修復。另外，當資料庫表更新大量數據後，刪除並重建索引可以提高查詢速度。
2．避免或簡化排序
應當簡化或避免對大型表進行重復的排序。當能夠利用索引自動以適當的次序產生輸出時，優化器就避免了排序的步驟。以下是一些影響因素：
●索引中不包括一個或幾個待排序的列；
●group by或order by子句中列的次序與索引的次序不一樣；
●排序的列來自不同的表。
為了避免不必要的排序，就要正確地增建索引，合理地合並資料庫表（盡管有時可能影響表的規范化，但相對於效率的提高是值得的）。如果排序不可避免，那麼應當試圖簡化它，如縮小排序的列的范圍等。
3．消除對大型錶行數據的順序存取
在嵌套查詢中，對表的順序存取對查詢效率可能產生致命的影響。比如採用順序存取策略，一個嵌套3層的查詢，如果每層都查詢1000行，那麼這個查詢就要查詢10億行數據。避免這種情況的主要方法就是對連接的列進行索引。例如，兩個表：學生表（學號、姓名、年齡……）和選課表（學號、課程號、成績）。如果兩個表要做連接，就要在「學號」這個連接欄位上建立索引。
還可以使用並集來避免順序存取。盡管在所有的檢查列上都有索引，但某些形式的where子句強迫優化器使用順序存取。下面的查詢將強迫對orders表執行順序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
雖然在customer_num和order_num上建有索引，但是在上面的語句中優化器還是使用順序存取路徑掃描整個表。因為這個語句要檢索的是分離的行的集合，所以應該改為如下語句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
這樣就能利用索引路徑處理查詢。
4．避免相關子查詢
一個列的標簽同時在主查詢和where子句中的查詢中出現，那麼很可能當主查詢中的列值改變之後，子查詢必須重新查詢一次。查詢嵌套層次越多，效率越低，因此應當盡量避免子查詢。如果子查詢不可避免，那麼要在子查詢中過濾掉盡可能多的行。
5．避免困難的正規表達式
MATCHES和LIKE關鍵字支持通配符匹配，技術上叫正規表達式。但這種匹配特別耗費時間。例如：SELECT ＊ FROM customer WHERE zipcode LIKE 「98_ _ _」
即使在zipcode欄位上建立了索引，在這種情況下也還是採用順序掃描的方式。如果把語句改為SELECT ＊ FROM customer WHERE zipcode >「98000」，在執行查詢時就會利用索引來查詢，顯然會大大提高速度。
另外，還要避免非開始的子串。例如語句：SELECT ＊ FROM customer WHERE zipcode[2，3]>「80」，在where子句中採用了非開始子串，因而這個語句也不會使用索引。
6．使用臨時表加速查詢
把表的一個子集進行排序並創建臨時表，有時能加速查詢。它有助於避免多重排序操作，而且在其他方面還能簡化優化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>「98000」
ORDER BY cust.name
如果這個查詢要被執行多次而不止一次，可以把所有未付款的客戶找出來放在一個臨時文件中，並按客戶的名字進行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然後以下面的方式在臨時表中查詢：
SELECT ＊ FROM cust_with_balance
WHERE postcode>「98000」
臨時表中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了磁碟I/O，所以查詢工作量可以得到大幅減少。
注意：臨時表創建後不會反映主表的修改。在主表中數據頻繁修改的情況下，注意不要丟失數據。
7．用排序來取代非順序存取
非順序磁碟存取是最慢的操作，表現在磁碟存取臂的來回移動。SQL語句隱藏了這一情況，使得我們在寫應用程序時很容易寫出要求存取大量非順序頁的查詢。
有些時候，用資料庫的排序能力來替代非順序的存取能改進查詢。
實例分析
下面我們舉一個製造公司的例子來說明如何進行查詢優化。製造公司資料庫中包括3個表，模式如下所示：
1．part表
零件號?????零件描述????????其他列
（part_num）?（part_desc）??????（other column）
102，032???Seageat 30G disk?????……
500，049???Novel 10M network card??……
……
2．vendor表
廠商號??????廠商名??????其他列
（vendor _num）?（vendor_name） （other column）
910，257?????Seageat Corp???……
523，045?????IBM Corp?????……
……
3．parven表
零件號?????廠商號?????零件數量
（part_num）?（vendor_num）?（part_amount）
102，032????910，257????3,450,000
234，423????321，001????4，000，000
……
下面的查詢將在這些表上定期運行，並產生關於所有零件數量的報表：
SELECT part_desc，vendor_name，part_amount
FROM part，vendor，parven
WHERE part.part_num=parven.part_num
AND parven.vendor_num = vendor.vendor_num
ORDER BY part.part_num
如果不建立索引，上述查詢代碼的開銷將十分巨大。為此，我們在零件號和廠商號上建立索引。索引的建立避免了在嵌套中反復掃描。關於表與索引的統計信息如下：
表?????行尺寸???行數量?????每頁行數量???數據頁數量
（table）?(row size)?（Row count）?（Rows/Pages）?（Data Pages）
part????150?????10，000????25???????400
Vendor???150?????1，000???? 25???????40
Parven???13????? 15，000????300?????? 50
索引?????鍵尺寸???每頁鍵數量???頁面數量
（Indexes）?(Key Size)?（Keys/Page)???(Leaf Pages）
part?????4??????500???????20
Vendor????4??????500???????2
Parven????8??????250???????60
看起來是個相對簡單的3表連接，但是其查詢開銷是很大的。通過查看系統表可以看到，在part_num上和vendor_num上有簇索引，因此索引是按照物理順序存放的。parven表沒有特定的存放次序。這些表的大小說明從緩沖頁中非順序存取的成功率很小。此語句的優化查詢規劃是：首先從part中順序讀取400頁，然後再對parven表非順序存取1萬次，每次2頁（一個索引頁、一個數據頁），總計2萬個磁碟頁，最後對vendor表非順序存取1.5萬次，合3萬個磁碟頁。可以看出在這個索引好的連接上花費的磁碟存取為5.04萬次。
C. 如何提高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萬行一樣.
如果還是太慢,還可以考濾分布式分區視圖!這總可以解決問題了吧!
關鍵在於你能否把大表按某種約束分解成子表.
D. 大數據量實時統計排序分頁查詢(並發數較小時)的幾點建議
大數據量實時統計排序分頁查詢的瓶頸不是函數（count，sum等）執行，
不是having, 也不是order by，甚至不是表join, 導致慢的原因就在於「數據量太大本身」
就是將表劃分為M份相互獨立的部分,可以是分表，也可以是不分表但冗餘一個取模結果欄位
實際結果是不分表比分表更加靈活，只需稍加配置，就可以動態切分大表，隨意更改M的大小。
將1條慢sql（大於30秒）拆分成為N條查詢速度巨快的sql(單條sql執行時間控制在20毫秒以內)
然後再web應用中以適當的線程數去並發查詢這些執行時間快的N條小sql再匯總結果
第一步查詢中去並發執行這N條小sql, 只取排序欄位和標識欄位，其他欄位一律丟棄
匯總結果後定位出當前頁面要顯示的pageNum條數據，再進行第二步查詢，取出頁面上需要展示的所有欄位
PS：這一點是至關重要的，其他幾點都可以不看，這點是最關鍵的。慢慢解釋一下：
有三種方式統計所有的記錄，
a) 第一種方式是把資料庫中所有記錄（只取排序欄位和標識欄位並且不做任何sum，count having order by等操作）
全部拉到web應用中，在web應用中完成所有的計算
b) 第二種方式是把資料庫中所有記錄做sum count having等操作之後的所有行數拉到web應用中，在web應用中完成剩餘計算
c) 第三種方式是把資料庫中所有記錄做sum count having order by等操作之後把limit後的數據拉到web應用中，
在web應用中對limit後的數據再計算
顯然，第一種方式 資料庫什麼活都不做只取數據 是不可行的。以lg_order_count_seller為例，1500萬行，
如果只算id, seller_id和order_count 這三個bigint類型，至少需要拉8*3*1500 0000 = 360000000=340M,
拉到內存中之後存儲需要8*4*15000000= 460M,這還不算List是的2的n次方這個特點和計算排序等的內存開銷，
不僅資料庫與web應用機器IO扛不住，就是應用自身恐怕也要OOM了。
第二種方式，所有記錄做sum count having等操作之後,由於是group by seller_id的，總得數據量變為100萬（就是賣家總數），
這樣子一來，共需要拉8*3*100 0000 = 23M,拉到內存之後，需要8*4*100 0000 = 30M, 再算上List是的2的n次方這個特點和
計算排序等的內存開銷也不會超過100M, IO的時間和內存開銷勉強可以考慮接受。
第三種方式，所有記錄做sum count having order by等操作之後把limit後的數據拉到web應用中，因為做了limit，所以，
數據量很小了，無論是IO還是內存開銷都已經很小了。可以忽略。
綜合以上三種，第三種方式適用於頁面的前n頁和後n頁，因為這個limit的數據量隨著頁數的增大而增大，
當大到每個切分後的小表的數據量時就轉為第二種方式了。
第二種方式適用於頁面的第[n+1, totaoPageNum-n]頁。
① 問題描述：
優化之前，還是是一條大慢sql查詢時，由於資料庫排序是穩定排序，
所以當兩條記錄排序欄位值相同時他們在頁面上的頁碼位置是固定的。
優化之後，當並行執行這N條小sql時，由於無法控制這些小sql的先後執行順序，
導致在web應用中當兩條記錄的排序欄位值相同時在頁面上的頁碼位置是隨機的。
② 解決辦法：
除了拉標識欄位(seller_id)和排序欄位(order_count_sum)之外，再取一個unique（id）的欄位，當兩條記錄的排序欄位值相同時，
再用這個unique的欄位（在賣家監控中這個欄位是id）進行第二次排序.這樣就解決了排序不穩定的問題。
③ 也許，看到這里會有疑問，為什麼不用seller_id？seller_id也是唯一， 這樣子不是少取id這個欄位，減少IO了？
seller_id雖然也是唯一，可以輔助排序，但是不要忘記資料庫的排序規則是：
如果兩列的值相等，那麼序號在前的排在前面，這里的序號就是主鍵(自動生成，autoincrement),
如果用seller_id的話還是不能保證排序的穩定性，只能用主鍵id.
把資料庫的連接，掃表，計算等資源優先讓給用戶關注的主要元素，次要元素可等主要元素載入完成之後再載入。
反應在賣家監控頁面中，查數據和查頁頁碼的sql語句基本相同，是在競爭同一資源，
所以，需要做一個策略，優先把資源讓給查數，數據查完之後再去查頁碼。
由於多線程取數據並沒有從本質上提高資料庫性能，所以必須針對大數據量實時統計排序分頁查詢做限流
我這里打個比方：食堂有6個窗口，物流團隊吃飯要買6個菜，平均每買1個菜需要1分鍾的時間，
如果派我一個人去一個窗口買的話需要6分鍾的時間
假如派6個人分別去6個窗口買這6個菜，只需要1分鍾的時間
但是，如果除了物流團隊，再來其他5個團隊呢，也就是說6個團隊每個團隊買6個菜共買36個菜，
這樣子有的團隊先買完，有的團隊後買完，但平均時間還是6分鍾。本質上沒有變化。
所以，對於特定的查詢條件，必須進行限流。讓每分鍾至多有6個團隊買菜，這樣子能使得情況變得不至於太糟糕。
這一點從目前來看只能是展望了，比如mysql資料庫換更為強大的oracle資料庫，
或更換InnoDb引擎為其他，或更換SATA硬碟為SSD 。。。。。。
相同的查詢條件，原來一個頁面查詢時間由於超過60秒超時了，根據1-6點建議優化之後，查詢時間變為2秒至3.5秒之間。
E. 如何提高上百萬級記錄MySQL資料庫查詢速度
關於mysql處理百萬級以上的數據時如何提高其查詢速度的方法
最近一段時間由於工作需要，開始關注針對Mysql資料庫的select查詢語句的相關優化方法。
由於在參與的實際項目中發現當mysql表的數據量達到百萬級時，普通SQL查詢效率呈直線下降，而且如果where中的查詢條件較多時，其查詢速度簡直無法容忍。曾經測試對一個包含400多萬條記錄（有索引）的表執行一條條件查詢，其查詢時間竟然高達40幾秒，相信這么高的查詢延時，任何用戶都會抓狂。因此如何提高sql語句查詢效率，顯得十分重要。以下是網上流傳比較廣泛的30種SQL查詢語句優化方法：
1、應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
2、對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
3、應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
4、盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
5、下面的查詢也將導致全表掃描：(不能前置百分號)
select id from t where name like 『%c%』
若要提高效率，可以考慮全文檢索。
6、in 和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
7、如果在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然 而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id from t where num=@num
可以改為強制查詢使用索引：
select id from t with(index(索引名)) where num=@num
8、應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where num/2=100
應改為:
select id from t where num=100*2
9、應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)=』abc』–name以abc開頭的id
select id from t where datediff(day,createdate,』2005-11-30′)=0–』2005-11-30′生成的id
應改為:
select id from t where name like 『abc%』
select id from t where createdate>=』2005-11-30′ and createdate<』2005-12-1′
10、不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
11、在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使 用，並且應盡可能的讓欄位順序與索引順序相一致。
12、不要寫一些沒有意義的查詢，如需要生成一個空表結構：
select col1,col2 into #t from t where 1=0
這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：
create table #t(…)
13、很多時候用 exists 代替 in 是一個好的選擇：
select num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
14、並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有欄位 sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。
15、索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有 必要。
16.應盡可能的避免更新 clustered 索引數據列，因為 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引數據列，那麼需要考慮是否應將該索引建為 clustered 索引。
17、盡量使用數字型欄位，若只含數值信息的欄位盡量不要設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會 逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。
18、盡可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長欄位存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的欄位內搜索效率顯然要高些。
19、任何地方都不要使用 select * from t ，用具體的欄位列表代替「*」，不要返回用不到的任何欄位。
20、盡量使用表變數來代替臨時表。如果表變數包含大量數據，請注意索引非常有限（只有主鍵索引）。
21、避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
22、臨時表並不是不可使用，適當地使用它們可以使某些常式更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使 用導出表。
23、在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數據量不大，為了緩和系統表的資源，應先create table，然後insert。
24、如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。
25、盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那麼就應該考慮改寫。
26、使用基於游標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
27、與臨時表一樣，游標並不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括「合計」的常式通常要比使用游標執行的速度快。如果開發時 間允許，基於游標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。
28、在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。
29、盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
30、盡量避免大事務操作，提高系統並發能力。
F. 澶勭悊涓婄櫨涓囨潯鐨勬暟鎹搴撳備綍鎻愰珮澶勭悊鏌ヨ㈤熷害_MySQL
1銆佸規煡璇㈣繘琛屼紭鍖栵紝搴斿敖閲忛伩鍏嶅叏琛ㄦ壂鎻忥紝棣栧厛搴旇冭檻鍦 where 鍙 order by 娑夊強鐨勫垪涓婂緩絝嬬儲寮曘
2銆佸簲灝介噺閬垮厤鍦 where 瀛愬彞涓瀵瑰瓧孌佃繘琛 null 鍊煎垽鏂錛屽惁鍒欏皢瀵艱嚧寮曟搸鏀懼純浣跨敤緔㈠紩鑰岃繘琛屽叏琛ㄦ壂鎻忥紝濡傦細
select id from t where num is null
鍙浠ュ湪num涓婅劇疆榛樿ゅ0錛岀『淇濊〃涓璶um鍒楁病鏈塶ull鍊礆紝鐒跺悗榪欐牱鏌ヨ錛
select id from t where num=0
3銆佸簲灝介噺閬垮厤鍦 where 瀛愬彞涓浣跨敤!=鎴栨搷浣滅︼紝鍚﹀垯灝嗗紩鎿庢斁寮冧嬌鐢ㄧ儲寮曡岃繘琛屽叏琛ㄦ壂鎻忋
4銆佸簲灝介噺閬垮厤鍦 where 瀛愬彞涓浣跨敤 or 鏉ヨ繛鎺ユ潯浠訛紝鍚﹀垯灝嗗艱嚧寮曟搸鏀懼純浣跨敤緔㈠紩鑰岃繘琛屽叏琛ㄦ壂鎻忥紝濡傦細
select id from t where num=10 or num=20
鍙浠ヨ繖鏍鋒煡璇錛
select id from t where num=10
union all
select id from t where num=20
5銆乮n 鍜 not in 涔熻佹厧鐢錛屽惁鍒欎細瀵艱嚧鍏ㄨ〃鎵鎻忥紝濡傦細
select id from t where num in(1,2,3)
瀵逛簬榪炵畫鐨勬暟鍊礆紝鑳界敤 between 灝變笉瑕佺敤 in 浜嗭細
select id from t where num between 1 and 3
6銆佷笅闈㈢殑鏌ヨ涔熷皢瀵艱嚧鍏ㄨ〃鎵鎻忥細
select id from t where name like '%abc%'
鑻ヨ佹彁楂樻晥鐜囷紝鍙浠ヨ冭檻鍏ㄦ枃媯緔銆
7銆佸傛灉鍦 where 瀛愬彞涓浣跨敤鍙傛暟錛屼篃浼氬艱嚧鍏ㄨ〃鎵鎻忋傚洜涓篠QL鍙鏈夊湪榪愯屾椂鎵嶄細瑙ｆ瀽灞閮ㄥ彉閲忥紝浣嗕紭鍖栫▼搴忎笉鑳藉皢璁塊棶璁″垝鐨勯夋嫨鎺ㄨ繜鍒拌繍琛屾椂錛涘畠蹇呴』鍦ㄧ紪璇戞椂榪涜岄夋嫨銆傜劧鑰岋紝濡傛灉鍦ㄧ紪璇戞椂寤虹珛璁塊棶璁″垝錛屽彉閲忕殑鍊艱繕鏄鏈鐭ョ殑錛屽洜鑰屾棤娉曚綔涓虹儲寮曢夋嫨鐨勮緭鍏ラ」銆傚備笅闈㈣鍙ュ皢榪涜屽叏琛ㄦ壂鎻忥細
select id from t where num=@num
鍙浠ユ敼涓哄己鍒舵煡璇浣跨敤緔㈠紩錛
select id from t with(index(緔㈠紩鍚)) where num=@num
8銆佸簲灝介噺閬垮厤鍦 where 瀛愬彞涓瀵瑰瓧孌佃繘琛岃〃杈懼紡鎿嶄綔錛岃繖灝嗗艱嚧寮曟搸鏀懼純浣跨敤緔㈠紩鑰岃繘琛屽叏琛ㄦ壂鎻忋傚傦細
select id from t where num/2=100
搴旀敼涓:
select id from t where num=100*2
9銆佸簲灝介噺閬垮厤鍦╳here瀛愬彞涓瀵瑰瓧孌佃繘琛屽嚱鏁版搷浣滐紝榪欏皢瀵艱嚧寮曟搸鏀懼純浣跨敤緔㈠紩鑰岃繘琛屽叏琛ㄦ壂鎻忋傚傦細
select id from t where substring(name,1,3)='abc'--name浠abc寮澶寸殑id
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’鐢熸垚鐨剗d
搴旀敼涓:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate
10銆佷笉瑕佸湪 where 瀛愬彞涓鐨“=”宸﹁竟榪涜屽嚱鏁般佺畻鏈榪愮畻鎴栧叾浠栬〃杈懼紡榪愮畻錛屽惁鍒欑郴緇熷皢鍙鑳芥棤娉曟ｇ『浣跨敤緔㈠紩銆
11銆佸湪浣跨敤緔㈠紩瀛楁典綔涓烘潯浠舵椂錛屽傛灉璇ョ儲寮曟槸澶嶅悎緔㈠紩錛岄偅涔堝繀欏諱嬌鐢ㄥ埌璇ョ儲寮曚腑鐨勭涓涓瀛楁典綔涓烘潯浠舵椂鎵嶈兘淇濊瘉緋葷粺浣跨敤璇ョ儲寮曪紝鍚﹀垯璇ョ儲寮曞皢涓嶄細琚浣跨敤錛屽苟涓斿簲灝藉彲鑳界殑璁╁瓧孌甸『搴忎笌緔㈠紩欏哄簭鐩鎬竴鑷淬
12銆佷笉瑕佸啓涓浜涙病鏈夋剰涔夌殑鏌ヨ錛屽傞渶瑕佺敓鎴愪竴涓絀鴻〃緇撴瀯錛
select col1,col2 into #t from t where 1=0
榪欑被浠ｇ爜涓嶄細榪斿洖浠諱綍緇撴灉闆嗭紝浣嗘槸浼氭秷鑰楃郴緇熻祫婧愮殑錛屽簲鏀規垚榪欐牱錛
create table #t(...)
13銆佸緢澶氭椂鍊欑敤 exists 浠ｆ浛 in 鏄涓涓濂界殑閫夋嫨錛
select num from a where num in(select num from b)
鐢ㄤ笅闈㈢殑璇鍙ユ浛鎹錛
select num from a where exists(select 1 from b where num=a.num)錛
14銆佸苟涓嶆槸鎵鏈夌儲寮曞規煡璇㈤兘鏈夋晥錛孲QL鏄鏍規嵁琛ㄤ腑鏁版嵁鏉ヨ繘琛屾煡璇浼樺寲鐨勶紝褰撶儲寮曞垪鏈夊ぇ閲忔暟鎹閲嶅嶆椂錛孲QL鏌ヨ㈠彲鑳戒笉浼氬幓鍒╃敤緔㈠紩錛屽備竴琛ㄤ腑鏈夊瓧孌祍ex錛宮ale銆乫emale鍑犱箮鍚勪竴鍗婏紝閭ｄ箞鍗充嬌鍦╯ex涓婂緩浜嗙儲寮曚篃瀵規煡璇㈡晥鐜囪搗涓嶄簡浣滅敤銆
15銆佺儲寮曞苟涓嶆槸瓚婂氳秺濂斤紝緔㈠紩鍥虹劧鍙浠ユ彁楂樼浉搴旂殑 select 鐨勬晥鐜囷紝浣嗗悓鏃朵篃闄嶄綆浜 insert 鍙 update 鐨勬晥鐜囷紝鍥犱負 insert 鎴 update 鏃舵湁鍙鑳戒細閲嶅緩緔㈠紩錛屾墍浠ユ庢牱寤虹儲寮曢渶瑕佹厧閲嶈冭檻錛岃嗗叿浣撴儏鍐佃屽畾銆備竴涓琛ㄧ殑緔㈠紩鏁版渶濂戒笉瑕佽秴榪6涓錛岃嫢澶澶氬垯搴旇冭檻涓浜涗笉甯鎬嬌鐢ㄥ埌鐨勫垪涓婂緩鐨勭儲寮曟槸鍚︽湁蹇呰併
16銆佸簲灝藉彲鑳界殑閬垮厤鏇存柊 clustered 緔㈠紩鏁版嵁鍒楋紝鍥犱負 clustered 緔㈠紩鏁版嵁鍒楃殑欏哄簭灝辨槸琛ㄨ板綍鐨勭墿鐞嗗瓨鍌ㄩ『搴忥紝涓鏃﹁ュ垪鍊兼敼鍙樺皢瀵艱嚧鏁翠釜琛ㄨ板綍鐨勯『搴忕殑璋冩暣錛屼細鑰楄垂鐩稿綋澶х殑璧勬簮銆傝嫢搴旂敤緋葷粺闇瑕侀戠箒鏇存柊 clustered 緔㈠紩鏁版嵁鍒楋紝閭ｄ箞闇瑕佽冭檻鏄鍚﹀簲灝嗚ョ儲寮曞緩涓 clustered 緔㈠紩銆
17銆佸敖閲忎嬌鐢ㄦ暟瀛楀瀷瀛楁碉紝鑻ュ彧鍚鏁板間俊鎮鐨勫瓧孌靛敖閲忎笉瑕佽捐′負瀛楃﹀瀷錛岃繖浼氶檷浣庢煡璇㈠拰榪炴帴鐨勬ц兘錛屽苟浼氬炲姞瀛樺偍寮閿銆傝繖鏄鍥犱負寮曟搸鍦ㄥ勭悊鏌ヨ㈠拰榪炴帴鏃朵細閫愪釜姣旇緝瀛楃︿覆涓姣忎竴涓瀛楃︼紝鑰屽逛簬鏁板瓧鍨嬭岃█鍙闇瑕佹瘮杈冧竴嬈″氨澶熶簡銆
18銆佸敖鍙鑳界殑浣跨敤 varchar/nvarchar 浠ｆ浛 char/nchar 錛屽洜涓洪栧厛鍙橀暱瀛楁靛瓨鍌ㄧ┖闂村皬錛屽彲浠ヨ妭鐪佸瓨鍌ㄧ┖闂達紝鍏舵″逛簬鏌ヨ㈡潵璇達紝鍦ㄤ竴涓鐩稿硅緝灝忕殑瀛楁靛唴鎼滅儲鏁堢巼鏄劇劧瑕侀珮浜涖
19銆佷換浣曞湴鏂歸兘涓嶈佷嬌鐢 select * from t 錛岀敤鍏蜂綋鐨勫瓧孌靛垪琛ㄤ唬鏇“*”錛屼笉瑕佽繑鍥炵敤涓嶅埌鐨勪換浣曞瓧孌點
20銆佸敖閲忎嬌鐢ㄨ〃鍙橀噺鏉ヤ唬鏇誇復鏃惰〃銆傚傛灉琛ㄥ彉閲忓寘鍚澶ч噺鏁版嵁錛岃鋒敞鎰忕儲寮曢潪甯告湁闄愶紙鍙鏈変富閿緔㈠紩錛夈
21銆侀伩鍏嶉戠箒鍒涘緩鍜屽垹闄や復鏃惰〃錛屼互鍑忓皯緋葷粺琛ㄨ祫婧愮殑娑堣椼
22銆佷復鏃惰〃騫朵笉鏄涓嶅彲浣跨敤錛岄傚綋鍦頒嬌鐢ㄥ畠浠鍙浠ヤ嬌鏌愪簺渚嬬▼鏇存湁鏁堬紝渚嬪傦紝褰撻渶瑕侀噸澶嶅紩鐢ㄥぇ鍨嬭〃鎴栧父鐢ㄨ〃涓鐨勬煇涓鏁版嵁闆嗘椂銆備絾鏄錛屽逛簬涓嬈℃т簨浠訛紝鏈濂戒嬌鐢ㄥ煎嚭琛ㄣ
23銆佸湪鏂板緩涓存椂琛ㄦ椂錛屽傛灉涓嬈℃ф彃鍏ユ暟鎹閲忓緢澶э紝閭ｄ箞鍙浠ヤ嬌鐢 select into 浠ｆ浛 create table錛岄伩鍏嶉犳垚澶ч噺 log 錛屼互鎻愰珮閫熷害錛涘傛灉鏁版嵁閲忎笉澶э紝涓轟簡緙撳拰緋葷粺琛ㄧ殑璧勬簮錛屽簲鍏坈reate table錛岀劧鍚巌nsert銆
24銆佸傛灉浣跨敤鍒頒簡涓存椂琛錛屽湪瀛樺偍榪囩▼鐨勬渶鍚庡姟蹇呭皢鎵鏈夌殑涓存椂琛ㄦ樉寮忓垹闄わ紝鍏 truncate table 錛岀劧鍚 drop table 錛岃繖鏍峰彲浠ラ伩鍏嶇郴緇熻〃鐨勮緝闀挎椂闂撮攣瀹氥
25銆佸敖閲忛伩鍏嶄嬌鐢ㄦ父鏍囷紝鍥犱負娓告爣鐨勬晥鐜囪緝宸錛屽傛灉娓告爣鎿嶄綔鐨勬暟鎹瓚呰繃1涓囪岋紝閭ｄ箞灝卞簲璇ヨ冭檻鏀瑰啓銆
26銆佷嬌鐢ㄥ熀浜庢父鏍囩殑鏂規硶鎴栦復鏃惰〃鏂規硶涔嬪墠錛屽簲鍏堝繪壘鍩轟簬闆嗙殑瑙ｅ喅鏂規堟潵瑙ｅ喅闂棰橈紝鍩轟簬闆嗙殑鏂規硶閫氬父鏇存湁鏁堛
27銆佷笌涓存椂琛ㄤ竴鏍鳳紝娓告爣騫朵笉鏄涓嶅彲浣跨敤銆傚瑰皬鍨嬫暟鎹闆嗕嬌鐢 FAST_FORWARD 娓告爣閫氬父瑕佷紭浜庡叾浠栭愯屽勭悊鏂規硶錛屽挨鍏舵槸鍦ㄥ繀欏誨紩鐢ㄥ嚑涓琛ㄦ墠鑳借幏寰楁墍闇鐨勬暟鎹鏃躲傚湪緇撴灉闆嗕腑鍖呮嫭“鍚堣”鐨勪緥紼嬮氬父瑕佹瘮浣跨敤娓告爣鎵ц岀殑閫熷害蹇銆傚傛灉寮鍙戞椂闂村厑璁革紝鍩轟簬娓告爣鐨勬柟娉曞拰鍩轟簬闆嗙殑鏂規硶閮藉彲浠ュ皾璇曚竴涓嬶紝鐪嬪摢涓縐嶆柟娉曠殑鏁堟灉鏇村ソ銆
28銆佸湪鎵鏈夌殑瀛樺偍榪囩▼鍜岃Е鍙戝櫒鐨勫紑濮嬪勮劇疆 SET NOCOUNT ON 錛屽湪緇撴潫鏃惰劇疆 SET NOCOUNT OFF 銆傛棤闇鍦ㄦ墽琛屽瓨鍌ㄨ繃紼嬪拰瑙﹀彂鍣ㄧ殑姣忎釜璇鍙ュ悗鍚戝㈡埛絝鍙戦 DONE_IN_PROC 娑堟伅銆
29銆佸敖閲忛伩鍏嶅ぇ浜嬪姟鎿嶄綔錛屾彁楂樼郴緇熷苟鍙戣兘鍔涖
30銆佸敖閲忛伩鍏嶅悜瀹㈡埛絝榪斿洖澶ф暟鎹閲忥紝鑻ユ暟鎹閲忚繃澶э紝搴旇ヨ冭檻鐩稿簲闇奼傛槸鍚﹀悎鐞嗐
G. asp.net 查詢大數據量（百萬條以上）如何快
1、索引2、你用存儲過程，存儲過程里還不是要寫語句的？有區別？如果每次查詢條件不一樣，可以用動態sql，用sp_executesql執行，效率還不錯，比exec執行動態sql快
H. 網貸大數據如何進行改善
如果不是因為逾期而造成的黑戶，那麼就要找找其他的原因了，比如說是不是申請網貸頻率過高，如果不知道可以在微信中瑞數據上檢測一下。只有知道是什麼原因導致自己成為黑戶，才能根據原因來改善網貸大數據。
因為網貸申請頻率過高，那麼建議半年內不要再去申請貸款了，名下已經貸款成功的網貸也要按時還款，這樣經過一段時間，大數據就會慢慢恢復。