還是關(guān)于SQL的運行速度. 篇2

king1981

7．用排序來取代非順序存取

非順序磁盤存取是最慢的操作，表現(xiàn)在磁盤存取臂的來回移動。SQL語句隱藏了這一情況，使得我們在寫應(yīng)用程序時很容易寫出要求存取大量非順序頁的查詢。

有些時候，用數(shù)據(jù)庫的排序能力來替代非順序的存取能改進(jìn)查詢。









3.優(yōu)化 tempdb 性能





對 tempdb 數(shù)據(jù)庫的物理位置和數(shù)據(jù)庫選項設(shè)置的一般建議包括：

使 tempdb 數(shù)據(jù)庫得以按需自動擴展。這確保在執(zhí)行完成前不終止查詢，該查詢所生成的存儲在 tempdb 數(shù)據(jù)庫內(nèi)的中間結(jié)果集比預(yù)期大得多。



將 tempdb 數(shù)據(jù)庫文件的初始大小設(shè)置為合理的大小，以避免當(dāng)需要更多空間時文件自動擴展。如果 tempdb 數(shù)據(jù)庫擴展得過于頻繁，性能會受不良影響。



將文件增長增量百分比設(shè)置為合理的大小，以避免 tempdb 數(shù)據(jù)庫文件按太小的值增長。如果文件增長幅度與寫入 tempdb 數(shù)據(jù)庫的數(shù)據(jù)量相比太小，則 tempdb 數(shù)據(jù)庫可能需要始終擴展，因而將妨害性能。



將 tempdb 數(shù)據(jù)庫放在快速 I/O 子系統(tǒng)上以確保好的性能。在多個磁盤上條帶化 tempdb 數(shù)據(jù)庫以獲得更好的性能。將 tempdb 數(shù)據(jù)庫放在除用戶數(shù)據(jù)庫所使用的磁盤之外的磁盤上。有關(guān)更多信息，請參見擴充數(shù)據(jù)庫。







4.優(yōu)化服務(wù)器:



使用內(nèi)存配置選項優(yōu)化服務(wù)器性能

Microsoft® SQL Server™ 2000 的內(nèi)存管理組件消除了對 SQL Server 可用的內(nèi)存進(jìn)行手工管理的需要。SQL Server 在啟動時根據(jù)操作系統(tǒng)和其它應(yīng)用程序當(dāng)前正在使用的內(nèi)存量，動態(tài)確定應(yīng)分配的內(nèi)存量。當(dāng)計算機和SQL Server 上的負(fù)荷更改時，分配的內(nèi)存也隨之更改。有關(guān)更多信息，請參見內(nèi)存構(gòu)架。



下列服務(wù)器配置選項可用于配置內(nèi)存使用并影響服務(wù)器性能：

min server memory

max server memory

max worker threads

index create memory



min memory per query

min server memory 服務(wù)器配置選項可用于確保 SQL Server 在達(dá)到該值后不會釋放內(nèi)存。可以基于 SQL Server 的大小及活動將該配置選項設(shè)置為特定的值。如果選擇設(shè)置此選項，必須為操作系統(tǒng)和其他程序留出足夠的內(nèi)存。如果操作系統(tǒng)沒有足夠的內(nèi)存，會向 SQL Server 請求內(nèi)存，從而導(dǎo)致影響 SQL Server 性能。



max server memory 服務(wù)器配置選項可用于：在 SQL Server 啟動及運行時，指定 SQL Server 可以分配的最大內(nèi)存量。如果知道有多個應(yīng)用程序與 SQL Server 同時運行，而且想保障這些應(yīng)用程序有足夠的內(nèi)存運行，可以將該配置選項設(shè)置為特定的值。如果這些其它應(yīng)用程序（如 Web 服務(wù)器或電子郵件服務(wù)器）只根據(jù)需要請求內(nèi)存，則 SQL Server 將根據(jù)需要給它們釋放內(nèi)存，因此不要設(shè)置 max server memory 服務(wù)器配置選項。然而，應(yīng)用程序通常在啟動時不假選擇地使用可用內(nèi)存，而如果需要更多內(nèi)存也不請求。如果有這種行為方式的應(yīng)用程序與 SQL Server 同時運行在相同的計算機上，則將 max server memory 服務(wù)器配置選項設(shè)置為特定的值，以保障應(yīng)用程序所需的內(nèi)存不由 SQL Server 分配出。

不要將 min server memory 和 max server memory 服務(wù)器配置選項設(shè)置為相同的值，這樣做會使分配給 SQL Server 的內(nèi)存量固定。動態(tài)內(nèi)存分配可以隨時間提供最佳的總體性能。有關(guān)更多信息，請參見服務(wù)器內(nèi)存選項。



max worker threads 服務(wù)器配置選項可用于指定為用戶連接到 SQL Server 提供支持的線程數(shù)。255 這一默認(rèn)設(shè)置對一些配置可能稍微偏高，這要具體取決于并發(fā)用戶數(shù)。由于每個工作線程都已分配，因此即使線程沒有正在使用（因為并發(fā)連接比分配的工作線程少），可由其它操作（如高速緩沖存儲器）更好地利用的內(nèi)存資源也可能是未使用的。一般情況下，應(yīng)將該配置值設(shè)置為并發(fā)連接數(shù)，但不能超過 32727。并發(fā)連接與用戶登錄連接不同。SQL Server 實例的工作線程池只需要足夠大，以便為同時正在該實例中執(zhí)行批處理的用戶連接提供服務(wù)。如果增加工作線程的數(shù)量超過默認(rèn)值，會降低服務(wù)器性能。有關(guān)更多信息，請參見max worker threads 選項。

說明 當(dāng) SQL Server 運行在 Microsoft Windows® 98 上時，最大工作線程服務(wù)器配置選項不起作用。



index create memory 服務(wù)器配置選項控制創(chuàng)建索引時排序操作所使用的內(nèi)存量。在生產(chǎn)系統(tǒng)上創(chuàng)建索引通常是不常執(zhí)行的任務(wù)，通常調(diào)度為在非峰值時間執(zhí)行的作業(yè)。因此，不常創(chuàng)建索引且在非峰值時間時，增加該值可提高索引創(chuàng)建的性能。不過，最好將 min memory per query 配置選項保持在一個較低的值，這樣即使所有請求的內(nèi)存都不可用，索引創(chuàng)建作業(yè)仍能開始。有關(guān)更多信息，請參見 index create memory 選項。

min memory per query 服務(wù)器配置選項可用于指定分配給查詢執(zhí)行的最小內(nèi)存量。當(dāng)系統(tǒng)內(nèi)有許多查詢并發(fā)執(zhí)行時，增大 min memory per query 的值有助于提高消耗大量內(nèi)存的查詢（如大型排序和哈希操作）的性能。不過，不要將 min memory per query 服務(wù)器配置選項設(shè)置得太高，尤其是在很忙的系統(tǒng)上，因為查詢將不得不等到能確保占有請求的最小內(nèi)存、或等到超過 query wait 服務(wù)器配置選項內(nèi)所指定的值。如果可用內(nèi)存比執(zhí)行查詢所需的指定最小內(nèi)存多，則只要查詢能對多出的內(nèi)存加以有效的利用，就可以使用多出的內(nèi)存。有關(guān)更多信息，請參見 min memory per query 選項和 query wait 選項。



使用 I/O 配置選項優(yōu)化服務(wù)器性能

下列服務(wù)器配置選項可用于配置 I/O 的使用并影響服務(wù)器性能：



recovery interval

recovery interval 服務(wù)器配置選項控制 Microsoft® SQL Server™ 2000 在每個數(shù)據(jù)庫內(nèi)發(fā)出檢查點的時間。默認(rèn)情況下，SQL Server 確定執(zhí)行檢查點操作的最佳時間。然而，若要確定這是否為適當(dāng)?shù)脑O(shè)置，需要使用 Windows NT 性能監(jiān)視器監(jiān)視數(shù)據(jù)庫文件上的磁盤寫入活動。導(dǎo)致磁盤利用率達(dá)到 100% 的活動尖峰值會妨害性能。若更改該參數(shù)以使檢查點進(jìn)程較少出現(xiàn)，通常可以提高這種情況下的總體性能。但仍須繼續(xù)監(jiān)視性能以確定新值是否已對性能產(chǎn)生正面影響。有關(guān)更多信息，請參見recovery interval 選項。









5.優(yōu)化數(shù)據(jù)庫文件



分區(qū)

將數(shù)據(jù)庫分區(qū)可提高其性能并易于維護(hù)。通過將一個大表拆分成更小的單個表，只訪問一小部分?jǐn)?shù)據(jù)的查詢可以執(zhí)行得更快，因為需要掃描的數(shù)據(jù)較少。而且可以更快地執(zhí)行維護(hù)任務(wù)（如重建索引或備份表）。



實現(xiàn)分區(qū)操作時可以不拆分表，而將表物理地放置在個別的磁盤驅(qū)動器上。例如，將表放在某個物理驅(qū)動器上并將相關(guān)的表放在與之分離的驅(qū)動器上可提高查詢性能，因為當(dāng)執(zhí)行涉及表之間聯(lián)接的查詢時，多個磁頭同時讀取數(shù)據(jù)�？梢允褂� Microsoft® SQL Server™ 2000 文件組指定將表放置在哪些磁盤上。



硬件分區(qū)

硬件分區(qū)將數(shù)據(jù)庫設(shè)計為利用可用的硬件構(gòu)架。硬件分區(qū)的示例包括：



允許多線程執(zhí)行的多處理器，使得可以同時執(zhí)行許多查詢。換句話說，在多處理器上可以同時執(zhí)行查詢的各個組件，因此使單個查詢的速度更快。例如，查詢內(nèi)引用的每個表可同時由不同的線程掃描。





RAID（獨立磁盤冗余陣列）設(shè)備允許數(shù)據(jù)在多個磁盤驅(qū)動器中條帶化，使更多的讀/寫磁頭同時讀取數(shù)據(jù)，因此可以更快地訪問數(shù)據(jù)。在多個驅(qū)動器中條帶化的表一般比存儲在一個驅(qū)動器上的相同的表掃描速度要快。換句話說，將表與相關(guān)的表分開存儲在不同的驅(qū)動器上可以顯著提高聯(lián)接那些表的查詢的性能。

水平分區(qū)

水平分區(qū)將一個表分段為多個表，每個表包含相同數(shù)目的列和較少的行。例如，可以將一個包含十億行的表水平分區(qū)成 12 個表，每個小表代表特定年份內(nèi)一個月的數(shù)據(jù)。任何需要特定月份數(shù)據(jù)的查詢只引用相應(yīng)月份的表。



具體如何將表進(jìn)行水平分區(qū)取決于如何分析數(shù)據(jù)。將表進(jìn)行分區(qū)是為了使查詢引用盡可能少的表。否則，查詢時須使用過多的 UNION 查詢來邏輯合并表，而這會削弱查詢性能。有關(guān)查詢水平分區(qū)的表的更多信息，請參見視圖使用方案。



常用的方法是根據(jù)時期/使用對數(shù)據(jù)進(jìn)行水平分區(qū)。例如，一個表可能包含最近五年的數(shù)據(jù)，但是只定期訪問本年度的數(shù)據(jù)。在這種情況下，可考慮將數(shù)據(jù)分區(qū)成五個表，每個表只包含一年的數(shù)據(jù)。



垂直分區(qū)

垂直分區(qū)將一個表分段為多個表，每個表包含較少的列。垂直分區(qū)的兩種類型是規(guī)范化和行拆分。



規(guī)范化是個標(biāo)準(zhǔn)數(shù)據(jù)庫進(jìn)程，該進(jìn)程從表中刪除冗余列并將其放到次表中，次表按主鍵與外鍵的關(guān)系鏈接到主表。



行拆分將原始表垂直分成多個只包含較少列的表。拆分的表內(nèi)的每個邏輯行與其它表內(nèi)的相同邏輯行匹配。例如，聯(lián)接每個拆分的表內(nèi)的第十行將重新創(chuàng)建原始行。



與水平分區(qū)一樣，垂直分區(qū)使查詢得以掃描較少的數(shù)據(jù)，因此提高查詢性能。例如有一個包含七列的表，通常只引用該表的前四列，那么將該表的后三列拆分到一個單獨的表中可獲得性能收益。



應(yīng)謹(jǐn)慎考慮垂直分區(qū)操作，因為分析多個分區(qū)內(nèi)的數(shù)據(jù)需要有聯(lián)接表的查詢，而如果分區(qū)非常大將可能影響性能。



（一）深入淺出理解索引結(jié)構(gòu)



實際上，您可以把索引理解為一種特殊的目錄。微軟的SQL SERVER提供了兩種索引：聚集索引（clustered index，也稱聚類索引、簇集索引）和非聚集索引（nonclustered index，也稱非聚類索引、非簇集索引）。下面，我們舉例來說明一下聚集索引和非聚集索引的區(qū)別：



其實，我們的漢語字典的正文本身就是一個聚集索引。比如，我們要查“安”字，就會很自然地翻開字典的前幾頁，因為“安”的拼音是“an”，而按照拼音排序漢字的字典是以英文字母“a”開頭并以“z”結(jié)尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”開頭的部分仍然找不到這個字，那么就說明您的字典中沒有這個字；同樣的，如果查“張”字，那您也會將您的字典翻到最后部分，因為“張”的拼音是“zhang”。也就是說，字典的正文部分本身就是一個目錄，您不需要再去查其他目錄來找到您需要找的內(nèi)容。



我們把這種正文內(nèi)容本身就是一種按照一定規(guī)則排列的目錄稱為“聚集索引”。



如果您認(rèn)識某個字，您可以快速地從自動中查到這個字。但您也可能會遇到您不認(rèn)識的字，不知道它的發(fā)音，這時候，您就不能按照剛才的方法找到您要查的字，而需要去根據(jù)“偏旁部首”查到您要找的字，然后根據(jù)這個字后的頁碼直接翻到某頁來找到您要找的字。但您結(jié)合“部首目錄”和“檢字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“張”字，我們可以看到在查部首之后的檢字表中“張”的頁碼是672頁，檢字表中“張”的上面是“馳”字，但頁碼卻是63頁，“張”的下面是“弩”字，頁面是390頁。很顯然，這些字并不是真正的分別位于“張”字的上下方，現(xiàn)在您看到的連續(xù)的“馳、張、弩”三字實際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結(jié)果，然后再翻到您所需要的頁碼。



我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱為“非聚集索引”。



通過以上例子，我們可以理解到什么是“聚集索引”和“非聚集索引”。



進(jìn)一步引申一下，我們可以很容易的理解：每個表只能有一個聚集索引，因為目錄只能按照一種方法進(jìn)行排序。



（二）何時使用聚集索引或非聚集索引



下面的表總結(jié)了何時使用聚集索引或非聚集索引（很重要）。



動作描述

使用聚集索引

使用非聚集索引



列經(jīng)常被分組排序

應(yīng)

應(yīng)



返回某范圍內(nèi)的數(shù)據(jù)

應(yīng)

不應(yīng)



一個或極少不同值

不應(yīng)

不應(yīng)



小數(shù)目的不同值

應(yīng)

不應(yīng)



大數(shù)目的不同值

不應(yīng)

應(yīng)



頻繁更新的列

不應(yīng)

應(yīng)



外鍵列

應(yīng)

應(yīng)



主鍵列

應(yīng)

應(yīng)



頻繁修改索引列

不應(yīng)

應(yīng)





事實上，我們可以通過前面聚集索引和非聚集索引的定義的例子來理解上表。如：返回某范圍內(nèi)的數(shù)據(jù)一項。比如您的某個表有一個時間列，恰好您把聚合索引建立在了該列，這時您查詢2004年1月1日至2004年10月1日之間的全部數(shù)據(jù)時，這個速度就將是很快的，因為您的這本字典正文是按日期進(jìn)行排序的，聚類索引只需要找到要檢索的所有數(shù)據(jù)中的開頭和結(jié)尾數(shù)據(jù)即可；而不像非聚集索引，必須先查到目錄中查到每一項數(shù)據(jù)對應(yīng)的頁碼，然后再根據(jù)頁碼查到具體內(nèi)容。



（三）結(jié)合實際，談索引使用的誤區(qū)



理論的目的是應(yīng)用。雖然我們剛才列出了何時應(yīng)使用聚集索引或非聚集索引，但在實踐中以上規(guī)則卻很容易被忽視或不能根據(jù)實際情況進(jìn)行綜合分析。下面我們將根據(jù)在實踐中遇到的實際問題來談一下索引使用的誤區(qū)，以便于大家掌握索引建立的方法。



1、主鍵就是聚集索引



這種想法筆者認(rèn)為是極端錯誤的，是對聚集索引的一種浪費。雖然SQL SERVER默認(rèn)是在主鍵上建立聚集索引的。



通常，我們會在每個表中都建立一個ID列，以區(qū)分每條數(shù)據(jù)，并且這個ID列是自動增大的，步長一般為1。我們的這個辦公自動化的實例中的列Gid就是如此。此時，如果我們將這個列設(shè)為主鍵，SQL SERVER會將此列默認(rèn)為聚集索引。這樣做有好處，就是可以讓您的數(shù)據(jù)在數(shù)據(jù)庫中按照ID進(jìn)行物理排序，但筆者認(rèn)為這樣做意義不大。



顯而易見，聚集索引的優(yōu)勢是很明顯的，而每個表中只能有一個聚集索引的規(guī)則，這使得聚集索引變得更加珍貴。



從我們前面談到的聚集索引的定義我們可以看出，使用聚集索引的最大好處就是能夠根據(jù)查詢要求，迅速縮小查詢范圍，避免全表掃描。在實際應(yīng)用中，因為ID號是自動生成的，我們并不知道每條記錄的ID號，所以我們很難在實踐中用ID號來進(jìn)行查詢。這就使讓ID號這個主鍵作為聚集索引成為一種資源浪費。其次，讓每個ID號都不同的字段作為聚集索引也不符合“大數(shù)目的不同值情況下不應(yīng)建立聚合索引”規(guī)則；當(dāng)然，這種情況只是針對用戶經(jīng)常修改記錄內(nèi)容，特別是索引項的時候會負(fù)作用，但對于查詢速度并沒有影響。



在辦公自動化系統(tǒng)中，無論是系統(tǒng)首頁顯示的需要用戶簽收的文件、會議還是用戶進(jìn)行文件查詢等任何情況下進(jìn)行數(shù)據(jù)查詢都離不開字段的是“日期”還有用戶本身的“用戶名”。



通常，辦公自動化的首頁會顯示每個用戶尚未簽收的文件或會議。雖然我們的where語句可以僅僅限制當(dāng)前用戶尚未簽收的情況，但如果您的系統(tǒng)已建立了很長時間，并且數(shù)據(jù)量很大，那么，每次每個用戶打開首頁的時候都進(jìn)行一次全表掃描，這樣做意義是不大的，絕大多數(shù)的用戶1個月前的文件都已經(jīng)瀏覽過了，這樣做只能徒增數(shù)據(jù)庫的開銷而已。事實上，我們完全可以讓用戶打開系統(tǒng)首頁時，數(shù)據(jù)庫僅僅查詢這個用戶近3個月來未閱覽的文件，通過“日期”這個字段來限制表掃描，提高查詢速度。如果您的辦公自動化系統(tǒng)已經(jīng)建立的2年，那么您的首頁顯示速度理論上將是原來速度8倍，甚至更快。



在這里之所以提到“理論上”三字，是因為如果您的聚集索引還是盲目地建在ID這個主鍵上時，您的查詢速度是沒有這么高的，即使您在“日期”這個字段上建立的索引（非聚合索引）。下面我們就來看一下在1000萬條數(shù)據(jù)量的情況下各種查詢的速度表現(xiàn)（3個月內(nèi)的數(shù)據(jù)為25萬條）：



（1）僅在主鍵上建立聚集索引，并且不劃分時間段：



Select gid,fariqi,neibuyonghu,title from tgongwen



用時：128470毫秒（即：128秒）



（2）在主鍵上建立聚集索引，在fariq上建立非聚集索引：



select gid,fariqi,neibuyonghu,title from Tgongwen



where fariqi> dateadd(day,-90,getdate())



用時：53763毫秒（54秒）



（3）將聚合索引建立在日期列（fariqi）上：



select gid,fariqi,neibuyonghu,title from Tgongwen



where fariqi> dateadd(day,-90,getdate())



用時：2423毫秒（2秒）



雖然每條語句提取出來的都是25萬條數(shù)據(jù)，各種情況的差異卻是巨大的，特別是將聚集索引建立在日期列時的差異。事實上，如果您的數(shù)據(jù)庫真的有1000萬容量的話，把主鍵建立在ID列上，就像以上的第1、2種情況，在網(wǎng)頁上的表現(xiàn)就是超時，根本就無法顯示。這也是我摒棄ID列作為聚集索引的一個最重要的因素。



得出以上速度的方法是：在各個select語句前加：declare @d datetime



set @d=getdate()



并在select語句后加：



select [語句執(zhí)行花費時間(毫秒)]=datediff(ms,@d,getdate())



2、只要建立索引就能顯著提高查詢速度



事實上，我們可以發(fā)現(xiàn)上面的例子中，第2、3條語句完全相同，且建立索引的字段也相同；不同的僅是前者在fariqi字段上建立的是非聚合索引，后者在此字段上建立的是聚合索引，但查詢速度卻有著天壤之別。所以，并非是在任何字段上簡單地建立索引就能提高查詢速度。



從建表的語句中，我們可以看到這個有著1000萬數(shù)據(jù)的表中fariqi字段有5003個不同記錄。在此字段上建立聚合索引是再合適不過了。在現(xiàn)實中，我們每天都會發(fā)幾個文件，這幾個文件的發(fā)文日期就相同，這完全符合建立聚集索引要求的：“既不能絕大多數(shù)都相同，又不能只有極少數(shù)相同”的規(guī)則。由此看來，我們建立“適當(dāng)”的聚合索引對于我們提高查詢速度是非常重要的。



3、把所有需要提高查詢速度的字段都加進(jìn)聚集索引，以提高查詢速度



上面已經(jīng)談到：在進(jìn)行數(shù)據(jù)查詢時都離不開字段的是“日期”還有用戶本身的“用戶名”。既然這兩個字段都是如此的重要，我們可以把他們合并起來，建立一個復(fù)合索引（compound index）。



很多人認(rèn)為只要把任何字段加進(jìn)聚集索引，就能提高查詢速度，也有人感到迷惑：如果把復(fù)合的聚集索引字段分開查詢，那么查詢速度會減慢嗎？帶著這個問題，我們來看一下以下的查詢速度（結(jié)果集都是25萬條數(shù)據(jù)）：（日期列fariqi首先排在復(fù)合聚集索引的起始列，用戶名neibuyonghu排在后列）

（1）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>'2004-5-5'

查詢速度：2513毫秒

（2）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>'2004-5-5' and neibuyonghu='辦公室'

查詢速度：2516毫秒

（3）select gid,fariqi,neibuyonghu,title from Tgongwen where neibuyonghu='辦公室'

查詢速度：60280毫秒

從以上試驗中，我們可以看到如果僅用聚集索引的起始列作為查詢條件和同時用到復(fù)合聚集索引的全部列的查詢速度是幾乎一樣的，甚至比用上全部的復(fù)合索引列還要略快（在查詢結(jié)果集數(shù)目一樣的情況下）；而如果僅用復(fù)合聚集索引的非起始列作為查詢條件的話，這個索引是不起任何作用的。當(dāng)然，語句1、2的查詢速度一樣是因為查詢的條目數(shù)一樣，如果復(fù)合索引的所有列都用上，而且查詢結(jié)果少的話，這樣就會形成“索引覆蓋”，因而性能可以達(dá)到最優(yōu)。同時，請記�。簾o論您是否經(jīng)常使用聚合索引的其他列，但其前導(dǎo)列一定要是使用最頻繁的列。 時用到復(fù)合聚集索引的全部列的查詢速度是幾乎一樣的，甚至比用上全部的復(fù)合索引列還要略快（在查詢結(jié)果集數(shù)目一樣的情況下）；而如果僅用復(fù)合聚集索引的非起始列作為查詢條件的話，這個索引是不起任何作用的。當(dāng)然，語句1、2的查詢速度一樣是因為查詢的條目數(shù)一樣，如果復(fù)合索引的所有列都用上，而且查詢結(jié)果少的話，這樣就會形成“索引覆蓋”，因而性能可以達(dá)到最優(yōu)。同時，請記住：無論您是否經(jīng)常使用聚合索引的其他列，但其前導(dǎo)列一定要是使用最頻繁的列。