【正文】 通過檢查 SET EXPLAIN 輸出文件，您可以確定是否可以采取措施來提高該查詢的性能。該實用程序將生成一個名為 的文件，并詳細記錄查詢的每個執(zhí)行步驟。 這些字段一起將讓您較好地了解當前系統(tǒng)資源的使用情況。如果該數(shù)字極其龐大，并持續(xù)增長，這通常表示物理存儲器或 RAM 不足，您可能需要安裝更多存儲器。 ? ―r‖字段告訴我們系統(tǒng)就緒隊列中有多少任務在等待要執(zhí)行的資源。如果給定了 count， vmstat 就會重復獲取系統(tǒng)的統(tǒng)計數(shù)據，直到達到了所指定的 count 次數(shù)。本例中，它所提供的統(tǒng)計數(shù)據是不準確的，也不是最新的。 Time interval 指定 vmstat 刷新的間隔，而 count 指定它將刷新的最大次數(shù)。它還顯示一行系統(tǒng)重啟或啟動以后的虛擬內存活動的摘要信息。 Timex 只是 time 實用程序的另一個變種，它將以更易讀的格式顯示時間。讓我們仔細查看一下上面的這個例子。 ? ―sys‖字段告訴您整個系統(tǒng)占 用的 CPU 時間總和。下面的實例展示了如何使用 time 實用程序來測量一個簡單數(shù)據庫查詢的響應時間： sys3523:omcadmin time dbaccess airgen_cm_db Database selected. (count(*)) 5958 1 row(s) retrieved. Database closed. real user sys 上面輸出的最后一部分給出了詳細的操作時間統(tǒng)計數(shù)據，該操作在本例中就是數(shù)據庫查詢： ? ―real‖字段告訴您從查詢開始到結束時所經過的時間。 通常，如果完成調優(yōu)過程之后，調優(yōu)之后的 SQL 查詢的響應時間變短了，而系統(tǒng)資源的利用率降低了，那么您就可以充滿信心地推斷：您已經調優(yōu)該 SQL 查詢，并獲得了更高的效率。響應時間指的是用戶等待他們的請求（即 SQL 查詢）得到完成的時間。一般，主要涉及系統(tǒng)和數(shù)據庫的性能。由于在內存中已經解析過的查詢在大多數(shù)情況下都是正在執(zhí)行的查詢，因此這一部分與前一部分在大多數(shù)時候都是相同的。根據研究所收集的統(tǒng)計信息，您可以進一步優(yōu)化查詢以獲取更好的性能。如果您發(fā)現(xiàn)了該查詢的一些問題，如響應時間太長，消耗了太多的系統(tǒng) CPU 或內存，那 么您可以按其顯示狀態(tài)為該查詢制作一個副本，以便稍后研究和分析之用。 ―Current SQL statement‖部分顯示了正在執(zhí)行的查詢的完整 SQL 語法。如果這些字段非零，就表明查詢出了一些問題，沒有正確地執(zhí)行。 輸出如下所示： Informix Dynamic Server 2021 Version OnLine Up 38 days 11:26:22 1654784 Kbytes session RSAM total used id user tty pid hostname threads memory memory 134709 omcadmin 3 29580 localhos 1 65536 61120 tid name rstcb flags curstk status 147311 sqlexec 6511e728 YP 1648 6511e728 cond wait(norm) Memory pools count 1 name class addr totalsize freesize allocfrag freefrag 134709 V 669b9020 65536 4416 162 6 name free used name free used overhead 0 1648 scb 0 96 opentable 0 6000 filetable 0 920 log 0 2152 temprec 0 1608 keys 0 192 ralloc 0 20480 gentcb 0 1256 ostcb 0 2520 sort 0 56 sqscb 0 11960 sql 0 40 rdahead 0 640 hashfiletab 0 280 osenv 0 1584 buft_buffer 0 4272 sqtcb 0 3240 fragman 0 2176 Sess SQL Current Iso Lock SQL ISAM . Id Stmt type Database Lvl Mode ERR ERR Vers 134709 SELECT mso_db CR Not Wait 0 0 Current SQL statement : SELECT ne_type, config_set_version FROM ne WHERE ne_inst = 46176 AND msospace_id = 1 Last parsed SQL statement : SELECT ne_type, config_set_version FROM ne WHERE ne_inst = 46176 AND msospace_id = 1 輸出的第一部分給出了關于正在執(zhí)行的查詢的一些常規(guī)統(tǒng)計信息，如對 哪個數(shù)據庫執(zhí)行查詢、其隔離級別以及鎖方式。例如，如果您想知道某個會話正在 執(zhí)行什么查詢，那么您可能要首先使用命令 onstat g ses 來查明其會話標識，然后將該標識插入上面的命令。 查詢統(tǒng)計信息 查詢統(tǒng)計信息對于故障診斷和查詢優(yōu)化至關重要。您可以將 syssessions 表與 syssesprof 表連接以進一步確定每個會話的用戶名和主機機器名，以便了解哪些地方可能會出現(xiàn)數(shù)據庫和系統(tǒng)問題。 total_sorts 和 dsksorts 表明各會話使用內存進行排序操作的效率。 locksheld 顯示各會話正使用多少鎖。 sysmaster 數(shù)據庫中的 syssesprof 表提供了各會話的更多詳細信息。 login_time 是一個指出會話登錄時 間的整數(shù)，使用 C 程序很容易將它轉換成常規(guī)時間格式。使用本文前面討論的監(jiān)控工具，我們可以收集哪些會話活動統(tǒng)計信息呢？ 常規(guī)會話統(tǒng)計信息 sysmaster 數(shù)據庫中的 syssessions 表存儲各個會話的常規(guī)信息，如登錄名、登錄時間、會話所登錄的主機機器、操作系統(tǒng)的進程標識和當前狀態(tài)等等。如果它是一個具有幾千甚至 幾百萬行的大表，那么您可能需要考慮向該表添加一些索引，或者考慮使用程序偽指令來強制內部查詢優(yōu)化器為訪問該表中的數(shù)據選擇索引而不是順序掃描。但如果 表很大，比如說超過了 100000 行，那么重復的順序掃描會對性能造成致命的影響。如果表很小，比如說幾百行，那么順序存取不會對性能造成什么影響；因為當數(shù)據庫引擎第一次掃描它時，該表會駐留于內存中，而當數(shù)據庫引擎下一次掃描它時，可以直接從內存檢索該表中的所有數(shù)據。利用上面的示例，您可以將主鍵列 customer_id 添加到原來的索引，將它變成一個復合列（例如， ―create index index_name on customer ( customer_type , customer_id )‖）。根據行數(shù)（上面的 nrows列）和唯一鍵數(shù)（上面的 nunique 列），我們可以計算每個索引唯一性的百分率： ( nunique/nrows)*100 百分率越高，索引的唯一性就越高。在必須刪除或更新任何鍵值時，問題出現(xiàn)了。如果這個表有一百萬行，那么可能有 202100 行具有相同的 customer_type 代碼。 索引唯一性 索引的重復程度很高會嚴重地影響更新和刪除的性能。在 OLTP 環(huán)境中會進行頻繁的插入、刪除和更新，這些操作會導致不斷地對索引進行拆分和合并，因此上述問題也就格外明顯。例如，如果索引只有兩層，那么只需要調整兩層，但如果索引有四層，那么相應地就需要對所有四層進行調整。索引層越多， IDS 到達索引葉節(jié)點所需的探測也就越多。對于較大的數(shù)據庫或者大小設置不是很好的數(shù)據庫，我們可能還會關注擴展塊的最大數(shù)目，或者會擔心針對索引的 32GB 限制。這會顯著地降低磁盤尋道速度。如果表有太多擴展塊，那么那些擴展塊極有可能相互交錯。物理頁的連續(xù)性對于性能十分重要。 表擴展塊 擴展塊是一塊物理上連續(xù)的頁。這意味著：您必須留意潛在的性能問題，確定其根源并將其消滅在萌芽狀態(tài)。此外也有許多圖形工具可用，這些工具使您能夠繪制操作系統(tǒng)資源利用率和性能的動態(tài)變化。其它實用程序（如 vmstat、 iostat、 ps ef 和 sar ）在收集操作系統(tǒng)當前的性能統(tǒng)計信息方面也很有用。以下是來自 ―top‖實用程序的輸出： load averages: , , 10:17:30 123 processes: 120 sleeping, 1 zombie, 2 on cpu CPU states: % idle, % user, % kernel, % iowait, % swap Memory: 3072M real, 76M free, 588M swap in use, 440M swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND 28349 omcadmin 4 0 0 86M 55M cpu10 970:25 % 17782 informix 5 30 10 1631M 1594M sleep % 17784 informix 5 59 10 1631M 1594M sleep % 17786 informix 5 59 10 1631M 1591M sleep % 571 root 1 58 0 361M 129M sleep % em_mis 17785 informix 5 59 10 1631M 1592M sleep % 5470 omcadmin 1 0 0 1960K 1408K cpu15 0:00 % top 上面的輸出包含兩部分。如果系統(tǒng)內存不足，那么 CPU 可能也會遭殃。如果 IDS 占用了太多 RAM（例如，如果系統(tǒng)有 512MB RAM，而 IDS 占用了 400MB 或更多作為其 共享內存），那么當用戶執(zhí)行內存密集型操作時，操作系統(tǒng)可能會經歷頻繁的交換和掛起。 ipcs 命令來查看 Informix 共享內存的大小。其思想是，讓 IDS 在初始化時分配足夠的虛擬共享內存，以便在用戶登錄到系統(tǒng)并執(zhí)行數(shù)據庫操作時無需分配 更多的虛擬共享內存。這反過來影響了 IDS 性能，并且最終會損害系統(tǒng)的性能。 您可以通過查詢 sysmaster 數(shù)據庫中的 sysptprof 表來進一步標識哪些表具有最多的磁盤讀寫操作： select dbsname, tabname, (isreads + pagreads) diskreads, (iswrites + pagwrites) diskwrites from sysptprof order by 3 desc, 4 desc 輸出類似于： dbsname tabname