informix－online 動態伺服器（ids,informix－online dynamic server）作為informix資料庫產品技術的核心，以其動態可伸縮體系結構，高效的並行處理能力、共享記憶體技術及易管理性等特點，將硬體資源發揮 得淋漓盡致。當前ids v7正廣泛地應用於我國金融、郵政、電信等行業的關鍵系統中，隨著應用的不斷深入,資料的積累,查詢的複雜化,查詢速度會變慢,致使響應時間過長。許多用 戶將其歸結為硬體的原因,於是公升級改造,或重新投資,資料庫的調優並沒有引起足夠的重視。這其實是一種浪費,與國外發達國家輕硬體、重應用的思路正好相 反。實踐表明,資料庫的不合理配置和不適當優化是其效能下降的主要因素。實施對ids上資料庫的管理維護、效能調優是系統管理員的主要工作，而能否得以良 好的查詢響應則集中體現了資料庫的效能，因此也是調優的重點。從系統管理的角度，我們可以設定多線索、合理分配共享記憶體空間、建立資料庫和表的分布及分片 管理等來加快查詢速度，但最終還要基於對資料庫本身的全面理解，因為資料處於不斷的變化和積累之中，並且隨著應用的深入查詢將日趨複雜化。本文從資料管理 的角度闡述了幾種查詢優化策略，實際應用中有很好的收效，現說明如下。
一、查詢的分類及要求
二、查詢的優化策略
1.充分利用查詢優化器
查詢優化器提供了資料查詢的優化策略分析和選擇方式，通過設定相關引數，優化器能夠選擇最佳的連線策略，並在所有的查詢路徑中找出一條最優路徑。選擇良 好的路徑是查詢優化中至關重要的一環，一條好的路徑可以掃瞄最少的記錄，以最少的磁碟i/o得到正確的查詢結果。可通過以下步驟進行。
（1）設定連線策略
通過修改配置檔案＄onconfig中的optcompind引數值來實現。
optcompind 0：在連線中優化器只選擇索引連線。
optcompind 1：若事務處理為可重複讀模式（repeatable read）,則選擇索引策略，否則，優化器自動選擇開銷最低的連線策略。
optcompind 2：優化器自動選擇開銷最低的連線策略。應盡量選擇該引數。
（2）設定查詢優化的模式
也即選擇最優的查詢路徑，通過執行以下sql語句來實現，格式為：
set optimization [ high | low | first_rows | all_rows ]
其中,high是預設選項，表示對所有查詢路徑都進行檢測，從中選擇最優。
low表示採用深度優先法僅在部分路徑中選擇最優，即在每次連線比較中，遇到最優路徑就繼續深入而濾掉非最優路徑，特點是優化時間短，但路徑準確率低。
first_rows和all_rows是自ids v7.3開始增加的新選項，無論對oltp還是dss都非常有用。傳統的查詢(即all_rows方式)一次將所有查詢結果輸出到共享記憶體緩衝區中，時間 的消耗非常大，然而實踐表明，大部分使用者僅關注最初的幾屏輸出內容，因此first_rows選項為我們提供了很好的選擇。first_rows指導優化 器選擇一條查詢路徑,使其只輸出填滿乙個緩衝區的記錄數，如果使用者繼續查詢則繼續執行，這樣避免了不必要的輸出結果和時間浪費，也使查詢速度大大提高。
由此可見，優化器的豐富功能為我們提供了靈活的手段，管理員可以根據不同應用情況選擇最佳的方式，既能達到最佳的查詢效果，又能將由此而造成的系統開銷降至最低。
2.進行統計更新和資料分布
當資料庫表做了大量的插入、刪除操作或表的索引發生變化後，online資料庫系統表的相關資訊與實際表的統計數字不一致，這對資料的完整性沒有任何損 害，但會影響到查詢的速度。因為優化器所制定的計畫和策略得以正確實施的前提是對系統表資訊的精確讀取，統計資訊的正確性將直接影響到查詢的執行效果，因 此我們必須定期執行系統表資訊的統計更新工作。此外還要經常做好資料分布工作，使資料的組織形式更為合理。通過資料分布，優化器可以根據有關資訊確定如下 內容：過濾器欄位的選擇率（selectivity）、訪問過濾器欄位和表的策略、最佳的連線策略。一旦確定這些內容，查詢的執行時間將會顯著縮短。
進行統計更新和資料分布的唯一方法是執行sql命令：update statistics……，其結果是：ids 流覽表和索引，一方面對統計資訊加以編譯，最終將編譯好的資訊儲存到相應的系統表中，另一方面讀取表中記錄並對其進行排序以生成最好的組織形式。具體格式 如下：
update statistics [ high | medium | low ] [ distributions only ] [ for table tabname [ (field1,field2……) ] ]
其中,high對錶中的所有記錄進行排序以產生資料分布。
medium隨時從表中選取部分記錄進行排序以產生資料分布。
low僅執行統計更新，即僅修改系統表systables、sysindexes、syscolumns的內容，但不進行資料分布。
distributions only進行資料分布和部分統計更新工作，不更新系統表sysindexes的內容。
為實現科學有效的統計更新和資料分布，通常應執行以下優化步驟:
（1）針對每張表執行
update statistics medium for table tabname distributions only
（2）針對每張表中帶索引的第乙個字段執行
update statistics high for table tabname (fieldname)
（3）對某些表中帶復合索引的每乙個字段執行
update statistics low for table tabname (fieldname1,fieldname2……)
以上順序非常重要，不能搞錯。為方便執行，我們可以將以上命令按順序寫入到乙個shell程式檔案中，讓作業系統在每日資料最少改動時間定時執行該程式。
3.使用sql語句快取（ssc,sql statement cache）功能
ssc是informix ids2000 v9中增加的新功能，提供了共享的語句快取，從而實現了快速的sql呼叫。傳統情況下，每條sql語句執行前都要進行邏輯分析以判斷語法正誤，還要在共享 記憶體中為各語句分配空間。實踐表明，無論是oltp還是dss應用，大量執行的sql語句具有相同的格式，通過ssc，重複的sql語句可以單一在共享內 存中儲存及共享使用，這樣不僅大大減少了大量語句的分析過程，使查詢的速度明顯加快，而且節省了大量共享記憶體空間，帶來了其他應用效果的改善。ssc的使 用方法如下。
(1) 在ids配置檔案＄onconfig中定義
stmt_cache 1
或執行sql命令：onmode －e enable 以啟用ssc功能。
（2）使用者使用前還必須定義環境變數stmt_cache
export stmt_cache = 1
或執行sql命令：set statement cache on
經過以上設定後，所有的查詢都將充分基於ssc進行高效處理。
三、檢視優化結果
查詢優化器給使用者提供了大量詳盡的關於優化的資訊，包括：
1．連線過程中的開銷估計
2．查詢過程中表的使用順序（即查詢路徑）
3．查詢過程中用到的臨時表
4．對每個表的訪問型別，如：順序掃瞄、索引掃瞄、雜湊連線等
一名合格的系統管理員應熟知每一項資訊所代表的含義，並進行反覆的優化和輸出比較方可制定出最佳的優化方案。為使系統提供以上資訊，要求執行查詢前先運 行sql命令：set explain on ，查詢完畢後再執行：set explain off，這樣在使用者當前工作目錄下會生成乙個包含以上資訊sqlexplain.out文字檔案。通過該檔案內容，管理員可清楚地看到經過優化後的查詢效 果。
onstat －g cac stmt
這時共享記憶體中每條sql語句的命中情況將會詳盡地顯示出來，命中率越高，表明查詢的效果越好，ssc得到了越充分的利用。
本文所列舉的查詢優化策略只是筆者工作經驗的總結，實際上，資料庫的優化是乙個長期不懈、不斷比較分析和調整的過程，因為資料在不斷的變化中，應用在不 斷的發展中。系統管理員只有深入領會和掌握informix動態伺服器所提供的強大功能，正確觀察和分析系統執行中提供的各種資訊，充分結合實際應用特 點，才能合理制定出良好的優化策略，實現快速、高效的資料查詢和應用分析，同時也使硬體資源得到最充分的發揮
Catalan數（卡特蘭數）
卡特蘭數 規定h 0 1，而h 1 1，h 2 2，h 3 5，h 4 14，h 5 42，h 6 132，h 7 429，h 8 1430，h 9 4862，h 10 16796，h 11 58786，h 12 208012，h 13 742900，h 14 2674440，h 15 969484...
卡特蘭數 Catalan數
卡特蘭數 規定h 0 1，而h 1 1，h 2 2，h 3 5，h 4 14，h 5 42，h 6 132，h 7 429，h 8 1430，h 9 4862，h 10 16796，h 11 58786，h 12 208012，h 13 742900，h 14 2674440，h 15 969484...
Catalan數（卡特蘭數）
2012 04 12 21 08 13 標籤 卡特蘭數 原始出處 作者資訊和本宣告。否則將追究法律責任。卡特蘭數 規定h 0 1，而h 1 1，h 2 2，h 3 5，h 4 14，h 5 42，h 6 132，h 7 429，h 8 1430，h 9 4862，h 10 16796，h 11 58...