[SQL]利用UNION ALL整合統計合併資料 | topcat 姍舞之間的極度凝聚

[SQL]利用UNION ALL整合統計合併資料 | topcat 姍舞之間的極度凝聚: 有時候需要整併一些資料時，UNION ALL可以是個不錯的技巧。本篇用一個範例來說明這樣的應用

1010: [SQL Server] 解決log檔(ldf file)過度膨脹的實戰經驗

1010: [SQL Server] 解決log檔(ldf file)過度膨脹的實戰經驗: 背景： 公司最近把一套每天有相對大量交易 (之前公司更大很多很多倍) 的系統轉移到SQL Server去，不到一個月交易檔(ldf)已經貼近數據檔(mdf)的size，真的好可怕啊。 身為SQL Server的DBA當然  要替月行道，警惡懲奸  不能讓這種情況繼續下去...

SQL LDF檔案過大解決方法

資料來源

在某個機會裡拿到朋友給的sql備份檔(.bak),還原後發現我電腦硬碟空間突然少了60g多,
後來找到原因是sql備份檔的ldf檔案肥大所造成!! 實在太可恥了!一個ldf檔要佔掉我60g
多的碟硬空間!明明它就可以被減肥的!


請依下列指令進行, 你可以把下列指令全都存成一個 .sql檔案備用。


1.把資料庫改成 simple模式.
從 SQL Server Management Studio 請在你的資料庫上用滑鼠點右鍵 => 最下方看到 "屬性" => 然後點到 "選項" 
接著右方下拉式選單把 "復原"模式 改選成 "簡單" 模式。

2.打開指令視窗, 輸入以下指令: (你可copy貼上,請別忘記改資料庫名稱)
USE 資料庫名稱 GO 
DBCC SHRINKFILE('資料庫名稱_Log',2)

上面的指令紅色的文字請改成你要減肥的資料庫名稱。然後run這個指令。




3.接著回到第一步驟,把剛才改成 "簡單" 模式改回 "完整"模式

完成!

你可以看到你的LDF檔減肥成功!
(若你在sql server裡有設定系統定時備份,建議你設定每隔一段時間壓縮資料庫,避免LDF檔再度肥大。)

其實......... 我很懶, 所以我教你一個懶人方法,十秒鏡就可幫LDF減肥~

請copy以下程式碼, [按新增查詢] 貼到指令區,改好資料庫檔名,Run它!!
不到十秒就能減肥成功!





程式碼copy區 (不包含等於符號)
==============================================
ALTER DATABASE 資料庫名稱 SET RECOVERY simple
use 資料庫名稱 go dbcc shrinkfile('資料庫名稱_log',2) ALTER DATABASE 資料庫名稱 SET RECOVERY FULL
=============================================

以上~~

SQL Server 2008 不允許儲存變更

資料來源

使用SQL SERVER 2008 當直接使用SQL Server Management Studio修改Table 欄位格式或是其他DDL定義時，就會引發跳出下列錯誤訊息

不允許儲存變更。 您所做的變更會需要下列資料表卸除並重新建立。 您有做任何變更一個資料表，無法重新建立或啟用選項會防止儲存變更，需要重新建立資料表。

 

這是因為SQL Server 2008預設不允許由圖形介面來變更資料表格式  ，下列行為就會引發上列訊息

1.變更資料行 允許 Null 設定。
2.重新排序資料表中的資料行。
3.變更資料行資料型別。
4.加入新的資料行。

SQL Server 2008會預設不允許由圖形介面來變更資料表格式，主要是因為怕手誤與大量的資料格式異動造成資料鎖定或資料遺失，這是重要的保護，但是卻造成麻煩

如果要取消此預設設定，可以依下列步驟：

開啟SQL Server Management Studio-->工具-->選項-->Designers(設計師)-->資料表和資料庫設計工具-->防止儲存需要資料表重建的變更  

      -->取消勾選 即可！如下圖：

  

但是MSDN上有附註說明停用這選項造成的影響：如果您停用這個選項，會不警告您儲存資料表時，已變更資料表的中繼資料結構。在這種情況下儲存資料表時，可能會發生資料遺失。

所以如果可以還是建議以T-SQL命令，去變更資料表。

SQL Server 2008 Express Edition 安裝 & 設定

SQL Server 2005數據庫簡明教程

MS SQL数据库入门及初级BI教程

SQL Server 管理-安裝與設定 SQL Server 2012

1010: [SQL Server] 解決log檔(ldf file)過度膨脹的實戰經驗

1010: [SQL Server] 解決log檔(ldf file)過度膨脹的實戰經驗: 背景： 公司最近把一套每天有相對大量交易 (之前公司更大很多很多倍) 的系統轉移到SQL Server去，不到一個月交易檔(ldf)已經貼近數據檔(mdf)的size，真的好可怕啊。 身為SQL Server的DBA當然  要替月行道，警惡懲奸  不能讓這種情況繼續下去...

德瑞克：SQL Server 學習筆記: 縮小 壓縮 交易記錄檔 (Shrink Transaction Log)；以使用 SQL Se...

德瑞克：SQL Server 學習筆記: 縮小 壓縮 交易記錄檔 (Shrink Transaction Log)；以使用 SQL Se...: 若您的資料庫因故造成交易記錄檔(Transaction Log，*.ldf)遠大於，資料檔案(例如：*.mdf)時，請參考下圖所示： 資料檔案才 10 MB，但是交易記錄檔卻已經成長為 1 GB。 那要如何 縮小 壓縮 交易記錄檔呢？ 本文以使用 SQL S...

SQL LDF檔案過大解決方法! 幫LDF檔減肥很簡單!

資料來源

在某個機會裡拿到朋友給的sql備份檔(.bak),還原後發現我電腦硬碟空間突然少了60g多,後來找到原因是sql備份檔的ldf檔案肥大所造成!! 實在太可恥了!一個ldf檔要佔掉我60g多的碟硬空間!明明它就可以被減肥的!


請依下列指令進行, 你可以把下列指令全都存成一個 .sql檔案備用。


1.把資料庫改成 simple模式.
從 SQL Server Management Studio 請在你的資料庫上用滑鼠點右鍵 => 最下方看到 "屬性" => 然後點到 "選項" 
接著右方下拉式選單把 "復原"模式 改選成 "簡單" 模式。

2.打開指令視窗, 輸入以下指令: (你可copy貼上,請別忘記改資料庫名稱)
USE 資料庫名稱 GO 
DBCC SHRINKFILE('資料庫名稱_Log',2)

上面的指令紅色的文字請改成你要減肥的資料庫名稱。然後run這個指令。




3.接著回到第一步驟,把剛才改成 "簡單" 模式改回 "完整"模式

完成!

你可以看到你的LDF檔減肥成功!
(若你在sql server裡有設定系統定時備份,建議你設定每隔一段時間壓縮資料庫,避免LDF檔再度肥大。)

其實......... 我很懶, 所以我教你一個懶人方法,十秒鏡就可幫LDF減肥~

請copy以下程式碼, [按新增查詢] 貼到指令區,改好資料庫檔名,Run它!!
不到十秒就能減肥成功!





程式碼copy區 (不包含等於符號)
==============================================
ALTER DATABASE 資料庫名稱 SET RECOVERY simple
use 資料庫名稱 go dbcc shrinkfile('資料庫名稱_log',2) ALTER DATABASE 資料庫名稱 SET RECOVERY FULL
=============================================

以上~~

【-Ma の 筆記本-】: [MS SQL] MERGE 同步處理兩個資料表

【-Ma の 筆記本-】: [MS SQL] MERGE 同步處理兩個資料表: 今天研究了一下MS SQL SERVER 2008才新增的MERGE功能， 主要簡化了比對兩個表格差異處時的新增、修改、刪除動作， 以前需要分開撰寫INSERT、UPDATE、DELETE語法， 透過MERGE比對資料，根據設定更新資料！

MS SQL HA的4種做法

資料來源

資料庫High Availability (HA)，微軟SQL Server共有4種做法。

1. Failover Clustering
2. Database Mirroring
3. Log Shipping
4. Replication

Failover Clustering
把兩台以上SQL Server組成Cluster，讓SQL Server個體(Instance)隨時保持同步的狀態。
每一台SQL Server稱為一個node，這些nodes連結在一個storage，例如san或是iscsi。

同一時間只有一個node是active，
當active node掛掉了，會failover到另一個node，以繼續提供服務。

在SQL Server個體的授權上，由於同一時間只有一個node是active，
所以只有active那個需要授權，passive的node是不需要授權的。

由於是Cluster架構，所以發生問題時，切換速度最快！
但因要綁storage，所以硬體價格最貴。


Database Mirroring
透過SQL的Mirror鏡像機制，將主Server(Principal)的資料庫，覆寫於目標Server(Mirror)中。

Mirror機制是針對資料庫進行覆寫，
不同於Cluster機制是將個SQL Server Instance進行同步。

有High-Safety Mode/High-Performance Mode兩種模式，
其中High-Safety Mode需再搭配一台Server(Witness)來進行auto failover的切換。
系統切換時，active的Server IP會變成目標Server IP，
所以在程式開發上，必需將Connection String中加入Failover_Partner的關鍵字，
以自動切換到active主機。

於Mirror機制下，目標資料庫是處理還原狀態，無法提供使用，
所以目標資料庫是不需要授權的。

參考文章http://caryhsu.blogspot.tw/2011/12/sql-s...-mirroring.html


Log Shipping
透過SQL的Log Shipping交易記錄傳送機制。
利用排程，於固定時間內，將主Server的資料庫，覆寫到目標Server中。

Log Shipping與Mirror相同，都是針對資料庫進行覆寫，而不是SQL Server Instance。
與Mirror不同的是，它只能進行資料庫覆寫，無法進行auto failover切換。

當主Server掛掉時，可藉由手動還原log方式，將資料庫上線供AP使用。
由於是透過排程於固定時間內覆寫資料，所以會資料遺失上的風險。

於Log Shipping機制下，目標資料庫是處理還原狀態，無法提供使用，
所以目標資料庫是不需要授權的。

參考文章http://caryhsu.blogspot.tw/2012/02/log-shipping.html


Replication
Replication複寫是透過SQL Agent將主Server的資料庫複製後，再發行到另一台Server上。

Replication與Log Shipping及與Mirror相同，都是針對資料庫進行覆寫，
而不是SQL Server Instance。

在Replication機制中，主Server與目標Server均可讀寫。
主Server上的異動會立即反映到目標Sever，
但目標Server的異動則不會影響主Sever。

當主Server掛掉時，必需手動修改AP對應到目標Server。

於Replication機制下，主Server與目標Server均是獨立且完整讀寫之個體；
所以不論主資料庫或是目標資料庫，都是需要授權的。

參考文章http://blog.xuite.net/tolarku/blog/41423198

SQL Server 2008 複寫實作

資料來源

你不可不知的複寫常識
複寫用來複製資料和資料庫物件的一項強大的功能，是大型資料庫或資料庫同步維持資料一致性的功能
透過各種網路、撥接連線，將資料散佈到不同地點上，即然是複寫了顧名思義，就是將資料同步的寫到各個不同的資料庫伺服器上

你不可不知的複寫常識 複寫用來複製資料和資料庫物件的一項強大的功能，是大型資料庫或資料庫同步維持資料一致性的功能
透過各種網路、撥接連線，將資料散佈到不同地點上，即然是複寫了顧名思義，就是將資料同步的寫到各個不同的資料庫伺服器上
當然在整個資料庫的複寫中，也有考量到效能處理及資料庫結構問題，又分為三種複寫架構：交易式、合併式、快照式。

快照式複寫：資料變更數量大，但次數不用太頻繁的同步複寫時，最適合使用快照式複寫。
在所有複寫功能中快照式在「發行者」端負擔較小，因為他不用追踨累加變更的資料，只需要將資料庫中的資料做快照即可。
例如，在整個整批交易中，每天共有三十萬筆資料，一天只需要傳回總部一次，那麼快照式複寫就可以較有效率的將資料複寫回去。
※此種複寫需要每一張表都有Identify欄位。

交易式複寫：當資料有任何改變時，會主動的傳遞到訂閱者，預設交易式複寫是唯讀存取，因此在訂閱者端有任何資料的改變
是不會傳遞回到發行者端的。不過交易式複寫是可以設定成訂閱者亦可更新資料。
這種複寫狀態會有較大的彈性並且於資料端有大量的更新或插入、刪除的動作，適合非MS SQL Server資料庫做同步的複寫方式。
※此種複寫在發行資料庫下會主動的配置交易記錄，透過交易記錄來執行複寫轉送，當使用這種複寫方式在資料尚未完全移動到散發資料庫前，記錄檔無法被截斷。
※所有交易式複寫的資料表上，必須包含主索引鍵，否則無法被利用來發送。

合併式複寫：與交易式複寫很類似，是在發行者上發佈後，訂閱者存資料時，之主動的交換最後一次同步處理所變更過的資料。
通常這種複寫是較適合在多個訂閱者可能會在不同時間之下更新相同的資料，較容易產生資料衝突，當資料產生衝突時，必須由DBA進行排解。
※此種複寫會自動建立一組GUID資料行，且支援Timestamp資料行，在訂閱者套用快照集時會重新產生timestamp，驗證timestamp是否為可用快照。

環境限制和需求 不論在那一種複寫狀況之下，建立快照集資料夾的安全問題都是需要被重視的，因此在資料庫複寫的過程中，快照夾實體目錄權限就必須考慮進來，
使用何種複寫則必須視你所貼近的環境來選用，若資料庫設計時，並無使用identify，或並無使用索引欄位，那麼於快照及交易複寫就不適用，除非改變資料庫內容。

實作注意事項 在實作時，必須先選擇何者為發行者、散發者、訂閱者…等等的角色定義。(總是要知道誰負責發資料、誰是來接受同步資料的角色吧)
多數的工作是著在發行者身上，其它的資料處理同步，就可以透過代理程式來決定運作在訂閱者發起同步令命，還是由訂閱者發起呢?
若是遠端的資料庫同步(跨WAN)則必須透過VPN達成複寫或是Web同步處理方式，畢竟複寫是必須透過網芳、或XML訊息傳遞來處理。
在實作的過程中，有一個問題產生了，因SQL是建置在WINDOWS之上，又有使用網芳傳遞，那麼如何確認每個資料庫的同步是沒有問題的呢?
因此在複寫的安全架構下，必須將SQL Server Agent的啟動帳戶設定為相同的實體本機帳號，另外網路上存取網芳亦必須開通由這幾台db可存取。

SQL Server 2008 數據庫同步的兩種方式 （發布、訂閱）

資料來源
時間:2012-07-30 18:03來源:Internet 作者:Internet 
1、找到數據庫服務器下的【复制】--【本地發布】，選擇【新建發布】。如下圖： 　　2、選擇待發布的數據庫。如下圖： 　　3、選擇發布類型。這裏選擇的默認類型【快照發布】。幾種發布類型的區別，SQL
1、找到數據庫服務器下的【复制】--【本地發布】，選擇【新建發布】。如下圖：

　　2、選擇待發布的數據庫。如下圖：

　　3、選擇發布類型。這裏選擇的默認類型【快照發布】。幾種發布類型的區別，SQL SERVER都在下面给出了說明。如下圖：

　　4、選擇待發布的類容。如下圖：

　　上圖中右側就是篩選的SQL語句。

　　5、設置快照代理。如下圖：

　　更改同步頻率如下圖：

　　6、設置代理安全性。如下圖：

　　7、填寫發布名稱

　　8、完成發布。如下圖：

　　二、訂閱。訂閱是對數據庫發布的快照進行同步，將發布的數據源數據同步到目標數據庫。具體訂閱過程如下；

　　1、找到數據庫服務器下的【复制】--【本地訂閱】，選擇【新建訂閱】。如下圖：

　　2、選擇訂閱的發布。如下圖：

　　3、選擇分發代理的位置；如下圖：

　　4、選擇訂閱服務器上的存放同步過來的數據的一個或者多個目標數據庫。如下圖：

　　若要添加多個訂閱數據庫，則點擊【添加訂閱服務器】。如下圖：

　　5、設置分發代理的安全性。如下圖：

　　6、設置同步計劃。如下圖：

　　7、完成訂閱。如下圖：

　　這样就完成了發布與訂閱的整個流程。

　　這裏，和上節一起就介紹完了SQL Server數據庫同步的兩種方式，希望對你有用。

Visual FoxPro 9中新的數據處理方式

資料來源
Visual FoXPro 9.0與以前的版本相比，在數據引擎上做了很大的改進。從增強的SQL語言到支持新的數據類型和索引都作了增強，本文闡述了這個最新版本作爲一個成熟開發平台的魅力。
　　數據引擎的改變主要體現在以下5個方面：
　　· 增強的SQL語言：取消了很多硬編碼的限制，增強了子查詢和關聯查詢的支持，支持更複雜的表達式，以及增強了對UNION的支持。
　　· 性能方面：加入了一個全新的索引方式，增加了過濾型索引的性能，提高了了TOP n ，MIN()/MAX()以及LIKE這些查詢子句的性能。
　　· 命令和函數：對數據操作的更具靈活性，增強對SQL中showplan的支持，增加ICASE()來代替IIF（）函數。
　　· 新的數據類型：支持VarChar、VarBinary和BLOB等新的數據類型，並提供相應的類型轉換函數：CAST()。增強了現有函數對數據類型的控制和轉換能力
　　· 遠程數據：增強了事務控制的能力，遊標機制使得代碼邏輯更加清楚，並且對CursorAdapter作了加強，使開發者只需數行代碼就可以方便地訪問遠程視圖。
　　由于提供了與SQLServer強有力的互操作性，Visual FoxPro 9對客戶端/服務器模式做了很大的改進。通過支持新的數據類型，並取消了SQL語言的諸多限制，同一套代碼可同時運行在本地數據引擎和SQL Server這兩種不同的數據源上。 
　　以上是大致的描述，下面讓我們深入剖析這些新增功能。
　　SQL子查詢的增強
　　假如要用一句話來表示SQL子查詢的增強程度，那就是：“太多了”！SQL語句中再沒有了元素數量的硬編碼限制。一個簡單的SELECT語句能包括更多的表、連接、子查詢、嵌套子查詢和聯結。
　　SQL語句中的IN子句中再也沒有數量限制。在以前的版本中IN實際被映射到了一個名字INLIST（）函數中，但現在這種依靠取消了。這個改變使得IN子句能使用更多的參數來生成非常複雜的SQL語句。與原來版本不同，只要找到相應記錄，Visual FoxPro 9會自動停止計算IN子句中的表達式，這將帶來性能的提高。
　　完全無限制？
　　IN參數表的元素也不是完全無限的，它的最大數量等于函數SYS（3055）的返回值，而這個函數的返回值與實際可用內存有關，因此假如你的可用內存越大，那麽IN子句支持的元素就越多。無硬編碼的限制並不等于完全無限制。像可用內存以及表達式的複雜性都能決定是否能運行一個非常長而且複雜的語句，你要花很大的功夫才能找出它們在你的機器上的真實極限。
　　增強的子查詢功能
　　子查詢在SQL語言中是一個很有用的功能。它一般處于WHERE子句中的右邊，充當一個選擇器的作用。在Visual FoxPro 9中，子查詢還可以處于SELECT的參數列表中（稱爲投影）以及FROM子句中（稱爲派生表）。
　　當你使用投影時，假如子查詢沒有返回任何記錄，那將返加一個空值（NULL）。投影還答應互相關聯，以後我們會講到這點。
　　以下使用投影的SQL語句的一個例子：
　　
　　SELECT ;
　　C.CustomerID, ;
　　C.CompanyName, ;
　　(SELECT YTD_Sales FROM Sales_02 WHERE ;
　　C.CustomerID = Sales_02.CustomerID) AS Y02,;
　　(SELECT YTD_Sales FROM Sales_03 WHERE ;
　　C.CustomerID = Sales_03.CustomerID) AS Y03,;
　　(SELECT YTD_Sales FROM Sales_04 WHERE ;
　　C.CustomerID = Sales_04.CustomerID) AS Y04 ;
　　FROM Customers C 
　　這個SELECT語句返回最後三個會計年度的客戶ID和公司名稱。
　　使用投影的限制是子查詢只能查詢一個字段，並且子查詢返回的記錄數不能大于1。
　　投影的另一個有價值的使用方法是它可以成爲表達式的一部分，如下所示：
　　
　　SELECT ;
　　C.customerID, ;
　　C.companyname, ;
　　SUM(D.quantity*D.unitprice) AS CustTotal ,; 
　　(SUM(D.quantity*D.unitprice) / ;
　　(SELECT SUM((quantity*unitprice)-discount) ;
　　FROM OrderDetails D2) ;
　　)*100 AS PctTotal ;
　　FROM Customers C ;
　　INNER JOIN Orders O ;
　　ON C.customerID = O.customerID ;
　　INNER JOIN OrderDetails D ;
　　ON O.orderid = D.orderid ;
　　GROUP BY C.customerID, C.companyname, O.orderID ;
　　ORDER BY pctTotal DESC
　　這個SELECT語句返回客戶ID、公司名稱、銷售額以及銷售額占總銷售額的百分比。
　　注重在以上語句中，子查詢充當SELECT列表中的一個複雜表達式，並且它還包含一個聚集函數SUM（），這裏我們可以看到使用它的靈活性。
　　子查詢的另一種使用場景即派生表，實際你可以將它看作一個邏輯表。
　　考慮以下的例子：
　　
　　SELECT ;
　　C.customerid, ;
　　P.prodUCt_count AS p_count;
　　FROM Customers C, ;
　　(SELECT c2.customerid, ; 
　　COUNT(DISTINCT D.productID) AS p_count ;
　　FROM Customers C2 ;
　　INNER JOIN Orders O ;
　　ON C2.customerid = O.customerid ;
　　INNER JOIN OrderDetails D ;
　　ON O.orderid = D.orderid ;
　　GROUP BY c2.customerid) AS P ;
　　WHERE C.customerID = p.customerID ;
　　AND P.p_count >= ;
　　(SELECT (COUNT(*)*.50) FROM Products) ;
　　ORDER BY p.product_count DESC
　　這個SELECT語句返回客戶ID、所有購買了50%産品的客戶，以及它們所購買的産品數量。
　　觀察以上的語句，你可以發現派生表有一個名爲“P”的別名，這與普通字段別名的語法一樣――都必須用AS子句來表達。而且這個子查詢很複雜（在本例中，它關聯了兩個表），這個派生表還可以作爲WHERE子句的一個條件或者將它放在ORDER BY子句中。
　　與投影不同，派生表能返回多個字段以及多條記錄，但它不能相互關聯。另外，所有的子查詢都會在主句中的SELECT執行之前運行。
　　子查詢還可以充當UPDATE語句中的SET列表。但SET子句只答應使用一個子查詢，並且當SET子句使用子查詢後，那WHERE子句中就不答應再使用子查詢了。
　　更好的關聯支持
　　新版本中的UPDATE語句和DELETE語句支持關聯。這樣，一條語句可以引用不同的表，如下所示：
　　
　　DELETE products ;
　　FROM mfg ;
　　WHERE mfg.productID = products.productID;
　　AND mfg.discontinued = .t.
　　這個DELETE語句刪除mfg表中所有不再生産的産品。
　　另一個關聯UPDATE語句示例如下：
　　
　　UPDATE products ;
　　SET unitprice = mfg.msrp *.90 ;
　　FROM mfg ;
　　WHERE mfg.productID = products.productID 
　　這條UPDATE語句將零售産品的價格打了九折。可能你會問：它支持子查詢嗎？當然支持。但使用的時候要格外小心。因爲假如子查詢沒有返回任何記錄，那將會返回一個值爲NULL的空記錄。而這恰恰不是你所希望得到的結果。如下所示：
　　
　　UPDATE products ;
　　SET unitprice = ; 
　　(SELECT ( msrp *.90 ) ;
　　FROM mfg ;
　　WHERE mfg.productID = products.productID)
　　這條UPDATE語句的作用與上條基本相似，但假如子查詢中的産品沒有找到的話，那unitprice將被置爲NULL。
　　視圖與查詢設計器
　　盡管新版本增強了子查詢功能，但不幸的是在視圖與查詢設計器中並不支持這種增強功能。並且由于SQL中的IN子句中的元素數目取消了硬編碼的限制，但視圖與查詢設計器中並不知道，因此假如你使用設計器，那IN子句還是只支持24個元素。
　　增強的UNION操作符
　　由于聯結的數量沒有了硬編碼的限制，你可以在INSERTINTO子句的結果集中使用UNION。也可以在使用UNION的同時使用ORDERBY子句。
　　性能
　　不管你是訪問遠程數據還是依靠于它強大的本地數據庫引擎，Visual FoxPro始終將性能考慮在第一位。Visual FoxPro 9進一步地增強了數據引擎的功能。
　　二進制索引
　　這種新型的索引使用方法如下：
　　INDEX ON DELETED() TAG DELETED BINARY
　　這種索引能與任何非空的邏輯表達式一起使用。除此之外，FOR表達式、ASCENDING、DESCENDING、UNIQUE或CANDIDATE要害字不能與它一起使用。
　　二進制索引並不支持SET ORDER TO命令，而且INDEXON命令會將當前的order設爲0。但你可在Seek語句中使用二進制索引。
　　二進制索引最大的優勢在于它的索引文件大小。以一個包含800萬條記錄的表爲例，它的二進制索引文件的大小差不多爲表大小的三十分之一。尺寸越小意味著在執行APPEND和REPLACE操作時I/O處理速度越快，但遺憾的是所有的Rushmore優化技術目前都還不支持二進制索引。
　　假如SQL語句返回的記錄起過表中總記錄的三分之一的話，那Rushmore將得到很好的發揮（當所有的記錄都命中的話會提高92%的速度）。假如SQL語句返回的記錄低于總記錄的三分之一，那Rushmore將變得很慢（假如沒有記錄命中的話會降低兩倍的速度）。
　　在Visual FoxPro 9中，將DELETE語句設置爲二進制索引是一種增強性能的簡單方法。但要注重版本的問題，因爲以前的版本並不支持這種新的索引方式。
　　Rushmore優化技術
　　新版本中有使用了大量的Rushmore優化技術，例如對TOPN[PERCENT]作了優化，這樣便能提供更好的性能。它一般與ORDER BY子句配合使用，返回前N個或者前百分比數目的記錄。在Visaul FoxPro 9中它減少了內排序操作和文件I/O操作，使得執行這種類型的語句占用更少的內存，並且正如此語句所言，它只返回確切的前N個記錄。
　　在以前的版本中，假如要統計一個班級總分排在前十名的學生，但中間存在並列名次的話，那結果會返回多于10個的記錄。
　　在適當的情況下，Visual FoxPro 9將在FOR DELETED()子句和FOR NOT DELETED()子句中使用過濾索引來對MIN（）和MAX（）這兩個聚集函數進行優化，可以提高MIN()和MAX()的計算速度。
　　假如LIKE模糊查詢語句中的條件以“%”爲結尾，那查詢速度也將得到很大提高（請注重，“%”只能出現在查詢條件的結尾，而不能出現在其它地方，否則優化無效）。這種優化的結果等同于普通WHERE子句查詢的速度。
　　更多的智能索引技術
　　Visual FoxPro 9比以前的版本更智能化，它充分地讓索引獲得Rushmore的優化技術，如下所示：
　　
　　INDEX ON DELETED() TAG DELETED 
　　以上語句自動對NOTDELETED（）和DELETED（）條件進行優化，不用你添加一條INDEX ON NOTDELETED()來實現。
　　這裏有個特例，就是當索引過過濾表達式采用了FORNOTDELETED（）作爲Rushmore的優化，並且SETDELETED設爲ON的話，那就無須爲NOTDELETED（）作優化。(王朝網路 wangchao.net.cn)