【正文】 ”記錄。Recordset沒有包含其他內(nèi)容，因此你很快就能找到你需要的記錄這樣就大大降低了處理時間。再談隨機數(shù)現(xiàn)在你下定決心要榨干Random 函數(shù)的最后一滴油，那么你可能會一次取出多條隨機記錄或者想采用一定隨機范圍內(nèi)的記錄。把上面的標準Random 示例擴展一下就可以用SQL應(yīng)對上面兩種情況了。為了取出幾條隨機選擇的記錄并存放在同一recordset內(nèi)，你可以存儲三個隨機數(shù)，然后查詢數(shù)據(jù)庫獲得匹配這些數(shù)字的記錄：SQL = “SELECT * FROM Customers WHERE ID = ” amp。 RNumber amp。 “ OR ID = ” amp。 RNumber2 amp。 “ OR ID = ” amp。 RNumber3假如你想選出10條記錄（也許是每次頁面裝載時的10條鏈接的列表），你可以用BETWEEN 或者數(shù)學等式選出第一條記錄和適當數(shù)量的遞增記錄。這一操作可以通過好幾種方式來完成，但是 SELECT 語句只顯示一種可能（這里的ID 是自動生成的號碼）：SQL = “SELECT * FROM Customers WHERE ID BETWEEN ” amp。 RNumber amp。 “ AND ” amp。 RNumber amp。 “+ 9”注意：以上代碼的執(zhí)行目的不是檢查數(shù)據(jù)庫內(nèi)是否有9條并發(fā)記錄。隨機讀取若干條記錄，測試過Access語法：SELECT top 10 * From 表名 ORDER BY Rnd(id)Sql server:select top n * from 表名 order by newid()mysqlelect * From 表名 Order By rand()Limit nAccess左連接語法(最近開發(fā)要用左連接,Access幫助什么都沒有,網(wǎng)上沒有Access的SQL說明,只有自己測試, 現(xiàn)在記下以備后查)語法elect ,table1,fd2, From table1 left join table2 on , where...使用SQL語句 用...代替過長的字符串顯示語法：SQL數(shù)據(jù)庫：select case when len(field)10 then left(field,10)+39。...39。 else field end as news_name,news_id from tablenameAccess數(shù)據(jù)庫：SELECT iif(len(field)2,left(field,2)+39。...39。,field)FROM tablename。Execute方法該方法用于執(zhí)行SQL語句。根據(jù)SQL語句執(zhí)行后是否返回記錄集，該方法的使用格式分為以下兩種：1．執(zhí)行SQL查詢語句時，將返回查詢得到的記錄集。用法為：Set 對象變量名=(“SQL 查詢語言”)Execute方法調(diào)用后，會自動創(chuàng)建記錄集對象，并將查詢結(jié)果存儲在該記錄對象中，通過Set方法，將記錄集賦給指定的對象保存，以后對象變量就代表了該記錄集對象。2．執(zhí)行SQL的操作性語言時，沒有記錄集的返回。此時用法為： “SQL 操作性語句” [, RecordAffected][, Option]RecordAffected 為可選項，此出可放置一個變量，SQL語句執(zhí)行后，所生效的記錄數(shù)會自動保存到該變量中。通過訪問該變量，就可知道SQL語句隊多少條記錄進行了操作。Option 可選項，該參數(shù)的取值通常為adCMDText，它用于告訴ADO，應(yīng)該將Execute方法之后的第一個字符解釋為命令文本。通過指定該參數(shù)，可使執(zhí)行更高效。BeginTrans、RollbackTrans、CommitTrans方法這三個方法是連接對象提供的用于事務(wù)處理的方法。BeginTrans用于開始一個事物；RollbackTrans用于回滾事務(wù)；CommitTrans用于提交所有的事務(wù)處理結(jié)果，即確認事務(wù)的處理。事務(wù)處理可以將一組操作視為一個整體，只有全部語句都成功執(zhí)行后，事務(wù)處理才算成功；若其中有一個語句執(zhí)行失敗，則整個處理就算失敗，并恢復(fù)到處里前的狀態(tài)。BeginTrans和 CommitTrans用于標記事務(wù)的開始和結(jié)束，在這兩個之間的語句，就是作為事務(wù)處理的語句。判斷事務(wù)處理是否成功，可通過連接對象的Error集合來實現(xiàn)，若Error集合的成員個數(shù)不為0，則說明有錯誤發(fā)生，事務(wù)處理失敗。Error集合中的每一個Error對象，代表一個錯誤信息。常用SQL語句書寫技巧(轉(zhuǎn))關(guān)鍵詞： SQLSQL結(jié)構(gòu)化查詢字符串的改寫，是實現(xiàn)數(shù)據(jù)庫查詢性能提升的最現(xiàn)實、最有效的手段，有時甚至是唯一的手段，比如在不允許大幅度修改現(xiàn)有數(shù)據(jù)庫結(jié)構(gòu)的情況下。通過優(yōu)化SQL語句提高查詢性能的關(guān)鍵是：l 根據(jù)實際需求情況，建立合適的索引； l 使用一切可能的方式去利用好索引，避免全表掃描；l 盡量減少內(nèi)存及數(shù)據(jù)I/O方面的開銷一、建立索引（一）建立“適當”的索引，是快速查詢的基礎(chǔ)。索引（index）是除表之外另一重要的、用戶定義的存儲在物理介質(zhì)上的數(shù)據(jù)結(jié)構(gòu)。當根據(jù)索引碼的值搜索數(shù)據(jù)時，索引提供了對數(shù)據(jù)的快速訪問。事實上，沒有索引，數(shù)據(jù)庫也能根據(jù)SELECT語句成功地檢索到結(jié)果，但隨著表變得越來越大，使用“適當”的索引的效果就越來越明顯。注意，在這句話中，我們用了“適當”這個詞，這是因為，如果使用索引時不認真考慮其實現(xiàn)過程，索引既可以提高也會破壞數(shù)據(jù)庫的工作性能。索引實際上是一種特殊的目錄，SQL SERVER提供了兩種索引：l 聚集索引（clustered index，也稱聚類索引、簇集索引）我們把這種正文內(nèi)容本身就是一種按照一定規(guī)則排列的目錄稱為“聚集索引”。例如：漢語字典中按拼音查某一個字，就是使用“聚集索引”，實際上，你根本用不著查目錄，直接在字典正文里找，就能很快找到需要的漢字（假設(shè)你知道發(fā)音）。l 非聚集索引（nonclustered index，也稱非聚類索引、非簇集索引）我們把目錄純粹是目錄，正文純粹是正文的排序方式稱為“非聚集索引”。例如：漢語字典中按部首查某一個字，部首目錄和正文一定要刻意的通過頁碼才能聯(lián)系到一起，其順序不是天然一致的。聚集索引與非聚集索引的最大區(qū)別就在于：聚集索引是對原數(shù)據(jù)表進行排序，因此只要符合索引條件，就能夠直接連續(xù)的讀取數(shù)據(jù)記錄，幾乎可以達到對數(shù)據(jù)表的零掃描；而非聚集索引僅僅只是另外建了一張索引表，取數(shù)據(jù)的時候，從索引表取得結(jié)果后，還需要到指針所指的數(shù)據(jù)行讀取相應(yīng)數(shù)據(jù)，因此，在性能上，聚集索引會大大優(yōu)于非聚集索引。但是在一張表中，聚集索引只允許一個，是比較寶貴的，因此要盡可能的用于那些使用頻率最高的索引上。另外，查詢時必需要用到索引的起始列，否則索引無效。另外，起始列也必需是使用頻繁的列，那樣的索引性能才會達到最優(yōu)化。（二）表：何時應(yīng)使用聚集索引或非聚集索引動作描述 使用聚集索引 使用非聚集索引列經(jīng)常被分組排序 ○ ○返回某范圍內(nèi)的數(shù)據(jù) ○一個或極少不同值小數(shù)目的不同值 ○大數(shù)目的不同值 ○頻繁更新的列 ○外鍵列 ○ ○主鍵列 ○ ○頻繁修改索引列 ○（三）索引建立的一些注意項不要把聚集索引浪費在主鍵上，除非你只按主鍵查詢雖然SQL SERVER默認是在主鍵上建立聚集索引的，但實際應(yīng)用中，這樣做比較浪費。通常，我們會在每個表中都建立一個ID列，以區(qū)分每條數(shù)據(jù)，并且這個ID列是自動增大的，步長一般為1。此時，如果我們將這個列設(shè)為主鍵，SQL SERVER會將此列默認為聚集索引。這樣做有好處，就是可以讓您的數(shù)據(jù)在數(shù)據(jù)庫中按照ID進行物理排序，但這樣做實用價值不大。從我們前面談到的聚集索引的定義我們可以看出，使用聚集索引的最大好處就是能夠根據(jù)查詢要求，迅速縮小查詢范圍，避免全表掃描。在實際應(yīng)用中，因為ID號是自動生成的，我們并不知道每條記錄的ID 號，所以我們很難在實踐中用ID號來進行查詢。這就使讓ID號這個主鍵作為聚集索引成為一種資源浪費。聚集索引相對與非聚集索引的優(yōu)勢是很明顯的，而每個表中只能有一個聚集索引的規(guī)則，這使得聚集索引變得更加寶貴，應(yīng)該用在其他查詢頻率高的字段上。其次，讓每個ID號都不同的字段作為聚集索引也不符合“大數(shù)目的不同值情況下不應(yīng)建立聚合索引”規(guī)則；當然，這種情況只是針對用戶經(jīng)常修改記錄內(nèi)容，特別是索引項的時候會負作用，但對于查詢速度并沒有影響。索引的建立要根據(jù)實際應(yīng)用需求來進行并非是在任何字段上簡單地建立索引就能提高查詢速度。聚集索引建立的規(guī)則大致是“既不能絕大多數(shù)都相同，又不能只有極少數(shù)相同”。舉個例子，在公文表的收發(fā)日期字段上建立聚合索引是比較合適的。在政務(wù)系統(tǒng)中，我們每天都會收一些文件，這些文件的發(fā)文日期將會相同，在發(fā)文日期上建立聚合索引對性能的提升應(yīng)該是相當大的。在群集索引下，數(shù)據(jù)物理上按順序存于數(shù)據(jù)頁上，重復(fù)值也排列在一起，因而在范圍查找時，可以先找到這個范圍的起末點，且只在這個范圍內(nèi)掃描數(shù)據(jù)頁，避免了大范圍掃描，提高了查詢速度。另一個相反的例子：比如在雇員表的“性別”列上只有“男”與“女”兩個不同值，因此就完全沒必要建立索引。在聚集索引中加入所有需要提高查詢速度的字段，形成復(fù)合索引根據(jù)一些實驗的結(jié)果，我們可以得出一些可供參考的結(jié)論：252。 僅用復(fù)合聚集索引的起始列作為查詢條件和同時用到復(fù)合聚集索引的全部列的查詢，速度是幾乎一樣的，甚至比后者還要快（在查詢結(jié)果集數(shù)目一樣的情況下）；252。 僅用復(fù)合聚集索引的非起始列作為查詢條件的話，這個索引是不起任何作用的。252。 復(fù)合聚集索引的所有列都用上，而且因為查詢條件嚴格，查詢結(jié)果少的話，會形成“索引覆蓋”，性能可以達到最優(yōu)。252。 最重要的一點：無論是否經(jīng)常使用復(fù)合聚合索引的其他列，其起始列一定要是使用最頻繁的列。，特定情況下有效252。 用聚合索引比用不是聚合索引的主鍵速度快；252。 用聚合索引比用一般的主鍵作order by速度快，特別是在小數(shù)據(jù)量情況；252。 使用聚合索引內(nèi)的時間段，搜索時間會按數(shù)據(jù)占整個數(shù)據(jù)表的百分比成比例減少，而無論聚合索引使用了多少個；252。 日期列不會因為有分秒的輸入而減慢查詢速度；252。 由于改變一個表的內(nèi)容，將會引起索引的變化。頻繁的insert,update,delete語句將導(dǎo)致系統(tǒng)花費較大的代價進行索引更新，引起整體性能的下降。一般來講，在對查詢性能的要求高于對數(shù)據(jù)維護性能要求時，應(yīng)該盡量使用索引，否則，就要慎重考慮一下付出的代價。在某些極端情況下，可先刪除索引，再對數(shù)據(jù)庫表更新大量數(shù)據(jù)，最后再重建索引，新建立的索引總是比較好用。二、編寫優(yōu)化的SQL語句，充分利用索引下面就某些SQL語句的where子句編寫中需要注意的問題作詳細介紹。在這些where子句中，即使某些列存在索引，但是由于編寫了劣質(zhì)的SQL，系統(tǒng)在運行該SQL語句時也不能使用該索引，而同樣使用全表掃描，這就造成了響應(yīng)速度的極大降低。SQL語句在提交給數(shù)據(jù)庫進行操作前，都會經(jīng)過查詢分析階段，SQLSERVER內(nèi)置的查詢優(yōu)化器會分析查詢條件的的每個部分，并判斷這些條件是否符合掃描參數(shù)（SARG）的標準。只有當一個查詢條件符合SARG的標準，才可以通過預(yù)先設(shè)置的索引，提升查詢性能。SARG的定義：用于限制搜索操作的一種規(guī)范，通常是指一個特定的匹配，一個確定范圍內(nèi)的匹配或者兩個以上條件的AND連接。一般形式如下：列名 操作符 或操作符 列名列名可以出現(xiàn)在操作符的一邊，而常數(shù)或變量出現(xiàn)在操作符的另一邊。如：Name=?張三?價格50005000Name=?張三? and 價格5000如果一個表達式不能滿足SARG的形式，那它就無法限制搜索的范圍了，也就是說SQL SERVER必須對每一行都判斷它是否滿足WHERE子句中的所有條件，既進行全表掃描。所以，一個索引對于不滿足SARG形式的表達式來說是無用的, 如：當查詢條件為“價格*2 5000”時，就無法利用建立在價格字段上的索引。SQLSERVER內(nèi)置了查詢優(yōu)化器，能將一些條件自動轉(zhuǎn)換為符合SARG標準，如：將“價格*2 5000” 轉(zhuǎn)換為“價格 2500/2 ”，以達到可以使用索引的目的，但這種轉(zhuǎn)化不是100%可靠的，有時會有語義上的損失，有時轉(zhuǎn)化不了。如果對“查詢優(yōu)化器”的工作原理不是特別了解，寫出的SQL語句可能不會按照您的本意進行查詢。所以不能完全依賴查詢優(yōu)化器的優(yōu)化，建議大家還是利用自己的優(yōu)化知識，盡可能顯式的書寫出符合SARG標準的 SQL語句，自行確定查詢條件的構(gòu)建方式，這樣一方面有利于查詢分析器分析最佳索引匹配順序，另一方面也有利于今后重讀代碼。介紹完SARG后，我們再結(jié)合一些實際運用中的例子來做進一步的講解：Like語句是否屬于SARG取決于使用%通配符的樣式如：name like ?張%?，這就屬于SARG而：name like ?%張? ,就不屬于SARG通配符%在字符串首字符的使用會導(dǎo)致索引無法使用，雖然實際應(yīng)用中很難避免這樣用，但還是應(yīng)該對這種現(xiàn)象有所了解，至少知道此種用法性能是很低下的?！胺恰辈僮鞣粷M足SARG形式，使得索引無法使用不滿足SARG形式的語句最典型的情況就是包括非操作符的語句，如：NOT、!=、!、NOT EXISTS、NOT IN、NOT LIKE等。下面是一個NOT子句的例子：...where not(status =39。valid39。)not運算符也隱式的包含在另外一些邏輯運算符中，比如運算符。見下例：...where status 39。invalid39。再看下面這個例子：select * from employee where salary3000。對這個查詢，可以改寫為不使用not：select * from employee where salary3000。雖然這兩種查詢的結(jié)果一樣，但是第二種查詢方案會比第一種查詢方案更快些。第二種查詢允許對salary列使用索引，而第一種查詢則不能使用索引。函數(shù)運算不滿足SARG形式，使得索引無法使用例：下列SQL條件語句中的列都建有恰當?shù)乃饕?，但?zhí)行速度卻非常慢：select * from record where substring(card_no,1,4)=′5378′(13秒)select * from record where