將 SQL 查詢回應時間縮至最短

記住，少一點是更快的。如果所有其他因素都相同，則比較複雜的 SQL 陳述式更短的時間內滿足較簡單的 SQL 陳述式。同樣地，如果所有其他因素都相等，則要求更多資料所花費的時間會比要求更少資料所花費的時間更長。

當執行報告或開啟儀表板時， Cognos® Analytics 查詢服務會規劃它從一或多個來源取得資料所需的 SQL 陳述式。產生的實體 SQL 陳述式取決於基礎資料庫支援的 SQL 語意和資料類型。當 Cognos Analytics 伺服器需要在本端執行其他處理程序時，所產生 SQL 陳述式的複雜性可能會為基礎資料伺服器及伺服器帶來效能成本。

在作業資料庫上分層的 Cognos Analytics 應用程式經常需要複雜的結合及表示式，以在商業術語中導覽資料及呈現值。相反地，在已清理的報告結構 (例如星狀綱目) 上分層的應用程式可以受益於發佈擷取、轉換並載入 (ETL) 處理程序所套用的資料轉換。減少查詢中結合及表示式的複雜性，可協助基礎資料伺服器更有效率地規劃查詢，進而減少處理器及記憶體耗用量。

以下是許多資料伺服器技術供應商建議用來改善執行時期效能的一些偏好作法。

避免複式結合及過濾表示式

SQL 陳述式的 WHERE 及 JOIN ON 子句中表示式的複雜性，可能會妨礙規劃資料伺服器、將查詢重新寫入具體化視圖或其他形式的查詢加速。

減少明確或隱含的資料類型轉換

轉換資料類型需要可大幅增加查詢回應時間的處理程序。當您在計算或過濾器中使用 CAST() 之類的函數時，或隱含地在具有不同資料類型的直欄上執行某些作業時，會明確地轉換資料類型。

理論上，作為表格之間關係中的索引鍵的計算表示式會解析為與結合關係反面的對應索引鍵相同的資料類型。這可避免因為資料類型不相容，而限制資料伺服器考量某些結合策略 (例如雜湊結合)。

避免使用 SQL 表示式來轉置值

熟悉 SQL 的使用者可以建構表示式，嘗試對資料庫值進行按摩以顯示。在數種情況下，可以使用可用的資料類型格式化、佈置及其他呈現選項來取代此類表示式。

下列範例示範如何起始多個資料類型轉換、子字串及連結，以特定方式顯示日期值，而不是使用各種編寫介面中可用的資料格式呈現選項。

Substring(Cast ( dateField, char(10)),6,2) || ‘-‘ || Substring(Cast ( dateField,
char(10)),9,2) || Substring(Cast ( dateField, char(10)),1,4)

避免不必要的外部結合

當陳述式中的一或多個表格缺少相關聯資料時，外部結合可讓應用程式傳回結果集。使用外部結合的查詢會限制資料伺服器有時與內部結合搭配使用的各種結合最佳化策略及結合排序。模型可以建構成一律使用外部結合，實際上報告或儀表板所提出的商業問題並不需要這些外部結合。

使用資料伺服器中表格的限制

資料伺服器中的表格可以具有資料伺服器查詢引擎針對策略 (例如結合刪除、查詢重寫及表示式最佳化) 可考量的限制。

基於此目的，可以宣告主要索引鍵、唯一索引鍵及外部索引鍵限制 (但非空值及表格限制)。視資料伺服器技術而定，這些限制可以宣告為非強制或強制。在包含雪花綱目的正規化表格設計中，非主要索引鍵直欄在功能上取決於主要索引鍵。

為了規劃資料伺服器要處理的 SQL 陳述式， Cognos Analytics 查詢服務會使用 meta 資料模型中定義的強制限制，例如資料模組中的 Framework Manger 或直欄相依關係中的行列式，以及表格之間的關係。這些物件通常在建立模型的其中一個起始步驟期間建立，但更常見的是它們由 meta 資料模型建立者手動定義。如需相關資訊，請參閱行列式及直欄相依關係。

使用索引和表格組織功能

資料庫管理者的一般挑戰是預期應用程式嘗試導覽資料庫的方式。這包括查詢將結合哪些表格，以及將套用哪些表格述詞。

使用代表性工作量，資料庫管理者可以檢閱哪些表格最常存取，特別是哪些本端直欄集用來過濾及分組表格中的直欄。利用該知識，資料庫管理者通常可以識別索引或表格組織策略，讓資料庫更有效率地選取所需的列。

候選工作量必須反映應用程式內可能發生之資料的任何特定分析及探索。當資料庫管理者受限於他們可以定義的涵蓋索引或表格組織的內容時，這很重要，因為這可能會使解決方案偏向最常見的情況。例如，應用程式可能主要根據時間、客戶地理位置及資料庫管理者可以最佳化表格設計的產品視景來分類測量。

meta 資料模型也可以建構在透過 SQL 視圖公開應用程式物件的資料庫之上。這類視圖必須由資料庫管理者針對視圖內的表示式進行檢閱。