A. 中國生物醫學文獻資料庫 cbm 的檢索途徑有哪些
您好，很高興為您解答。
一．檢索途徑和方法
CBMdisc資料庫中使用的布爾邏輯運算符一般有「AND」、「OR」、「AND NOT」，
通配符：「?」，可替代任何一中文字元，例如：張？、張偉？。
范圍運算符：僅用於出版年欄位的檢索，對檢索結果進行時間限定。
＝（等於） 例PY = 2001 檢索2001年發表的文獻；
＞（大於） 例PY > 1998 檢索1998年以後發表的文獻；
＜（小於） 例PY < 1997 檢索1997年以前發表的文獻；
＞＝（大於等於） 例PY >= 1992 檢索1992年以來（包括1992年）發表的文獻；
＜＝（小於等於） 例PY <= 1990 檢索1990年以前（包括1990年）發表的文獻。
CBMDisc提供了5種檢索途徑，即基本檢索、主題詞檢索、索引詞檢索、分類檢索和期刊檢索。
1．基本檢索
可直接在檢索框內輸入有效檢索詞進行單字、文本詞的檢索，只要文獻記錄中出現與
檢索詞相同的實義詞，系統一律檢出。
⑴ 在基本檢索狀態下，可進行以下一些輔助檢索：
① 預設欄位：系統默認欄位，表示在中文題目、文摘、作者、主題詞、特徵詞、關鍵詞、期刊欄位查找用戶輸入的檢索詞。
②全部欄位：表示在所有可檢索的字元型欄位中查找用戶輸入的檢索詞。這種檢索方式可使檢索結果較全。
③特定欄位：指僅在某一指定欄位內檢索用戶輸入的檢索詞，如中文標題、英文標題、作者、地址、期刊等。特定欄位檢索需在檢索詞前後加欄位標識符，「標識符」表示精確檢索，「in 標識符」，表示對所選欄位的任意片段進行查找。
例：「au ＝李平」，為精確檢索，檢出的結果均為作者「李平」發表的文章; 「李平 in au」，為非精確檢索，在作者欄位中有「李平」或「李平貴」的文獻均被檢出；
④引文欄位：通過「參考文獻」欄位可了解某種文獻被引用情況。
例：查找「吳孟超」發表論文或著作被引用的情況，方法是：在「預設「下拉菜單中選擇「參考文獻」欄位，輸入「吳孟超」，點擊「檢索」即可顯示作者文獻的被引用結果。再點擊「顯示」按鈕進入引文題錄界面。
⑵ 各按鈕作用及使用方法
①「顯示」按鈕 顯示游標指向的檢索式的檢索結果。
②「刪除」按鈕 刪除無用的檢索式。
③「選中」按鈕 用滑鼠單檢索式，然後點擊「選中」按鈕，該檢索式呈淺藍色。然後選擇「AND」、「OR 」、「NOT」按鈕進行邏輯運算。如果想取消選中狀態，再點擊「清除」按鈕，此時，檢索式淺藍色標記消失。
例：肝炎治療
首先在檢索框內分別輸入肝炎和治療，在檢索結果式列表中，點擊肝炎檢索表達式，然後點擊「選中」按鈕，接著點擊治療檢索表達式，再點擊「選中」按鈕，被點擊後的兩個檢索表達式均呈淺藍色，最後點擊「AND」按鈕將二者組配，即可得到肝炎治療的文獻。
④「二次檢索」按鈕 可在第一次檢索結果的基礎上進行二次檢索，或重新檢索。檢索方法與一次檢索相同。在二次檢索屏幕，系統顯示一次檢索所使用的資料庫、欄位、檢索式，以及一次檢索的命中篇數。可在一次檢索的基礎上進行限制檢索，可瀏覽檢出文獻題目。
提示注意：「加入列表」和「檢索列表」一般用於檢索結果中的任何欄位內容（如標題、文摘、關鍵詞等）。使用方法：即在檢索結果顯示文獻中，用滑鼠選中被檢索詞（呈淺綠色），然後點擊「加入列表」按鈕，接著點擊「檢索列表」，此時被檢索詞自動添加到檢索列表式中，進行限定檢索。
⑶ 關鍵詞檢索適用范圍：
①不太熟悉規范的主題詞時，可先輸入關鍵詞，再在顯示記錄的主題詞欄位中找到相應的主題詞，進行更系統，更全面的檢索。
②沒有相應的主題詞，包括：A. 新出現的科技術語，新發現的物質及疾病名稱：
B. 某些特寫概念，如體重、海拔、高度、劑量等：C. 中醫葯名稱；
③在使用主題詞不能檢出滿意的文獻時，採用自由詞，可能會擴大檢索結果，並可根據記錄中顯示的主題詞，比較使用的主題詞是否合適或重新確定主題詞。
2．主題詞檢索
CBMDisc主題詞表收錄了美國國立醫學圖書館《醫學主題詞表》（即MESH）和中國中醫研究院出版的《中醫葯學主題詞表》的所有詞條。醫學主題詞表是對生物醫學文獻進行主題分析、標引和檢索時使用的權威性詞表，它的作用是使醫學文獻的主題標引達到統一和一致，並指導用戶高質量地檢索醫學文獻。
在基本檢索頁面點擊「主題詞」按鈕進入主題詞檢索頁。可選擇中文主題詞或英文主題詞兩種查找方式，在輸入框鍵入主題詞後點擊「瀏覽」按鈕進入主題詞樹形結構頁，可根據系統顯示的同義詞、相關詞、上位詞或下位詞進行檢索，選擇主題詞後可對該詞進行擴展檢索、加權檢索及主題詞與副主題片語配檢索。
例1: 阿司匹林誘發哮喘
本課題包含兩個主題概念，即阿司匹林和哮喘，按照MESH標引規則， 應查同時包含「阿司匹林/副作用」與「哮喘/化學誘導」兩方面內容的文獻。步驟如下：
⑴ 在「中文主題詞」 對話框下輸入 「阿司匹林」，點擊「瀏覽」按鈕，再點擊「主題詞注釋」進入阿司匹林的英文名稱和樹形結構頁；在檢索選項中選擇「擴展」或「不擴展」；再點擊「檢索」；這時出現副主題詞對話框，根據課題要求，用戶可選擇相匹配的副主題詞。本檢索選擇「副作用」，點擊「確認」按鈕。
⑵ 採取以上方法，在「哮喘」主題詞下, 選擇「化學誘導」副主題詞。
⑶ 將以上兩個檢索結果分別「選中」，點擊「AND」則顯示最終檢索結果。
例2：肺癌的診斷
「肺癌」這個詞不是規范的主題詞，因此輸入之後，輪排詞表中沒有顯示，只有「小細胞肺癌」，這個范疇顯然太小了，要轉換成相應的主題詞「肺腫瘤」之後，再進行檢索。在出現肺腫瘤樹狀結構狀態下，進行擴展檢索，選擇全部的擴展樹，可將「肺腫瘤」的全部下位類如支氣管腫瘤、支氣管原癌、PANCOAST綜合征等內容的全部文獻進行擴展檢索，再與副主題詞「診斷」組配。可選擇「E英文檢索主題詞」，輸入Lung neoplasms，在英漢對照主題詞輪排表中，按字順找到Lung Neoplasms＝肺腫瘤，點擊「檢索」，選擇「診斷」或「超聲診斷」等相關副主題詞後確定，即得檢索結果。
CBMDisc主題詞表與MESH詞表完全對應，因此當讀者不知某個主題詞的英文拼寫時，可通過CBMDisc主題詞表的主題詞注釋，找到其正確的英文主題詞，進而檢索英文資料庫。還可通過顯示文獻的英文題目（TT），找到對應於某個中文詞的英文表達方式。
從理論上講，主題詞檢索有助於提高文獻的查全率和查准率，應是最理想的檢索途徑，但CBMDisc在標引深度、標引的准確性、一致性等方面，都不及MEDLINE，其主題詞檢索效果往往不及自由詞檢索來得全。
3．索引詞檢索
索引詞表收錄了資料庫中所有可檢索欄位中的所有單個字和部分片語, 以及主題詞、匯編名稱等，該表有助於用戶通過瀏覽方式選詞檢索。
檢索方法：點擊「索引」按鈕，在提問框中輸入檢索詞，點擊「瀏覽」按鈕或按回車鍵，系統顯示索引詞表；包括索引詞，命中記錄數和索引詞的出現數；點中一個索引詞（呈淺藍色），然後點擊「檢索」按鈕。索引詞表檢索僅在默認欄位進行，即：題目、文摘、關鍵詞、主題詞和刊名欄位。表中列出的命中文獻數為所有欄位的檢索結果。
4．分類檢索
點擊「分類」按鈕，系統進入分類檢索狀態。分類表包括《中國圖書資料分類法》第三版R類的內容，其排列規則為：總論復分表排在最前面，標記符號為「-」，其次是臨床專用復分表，標記符號為「0」，即01-09，分別表示預防控制、病理學、醫學免疫學、診斷學、治療學等復分類目；最後是主類號，即R1、R2、R3、R4、R5、R6、R7、R8、R9的全部類目。可以通過「分類號」和「分類詞」進行檢索或選用復分號進行擴展檢索。
5．期刊檢索
點擊「期刊」按鈕，系統進入期刊檢索狀態。期刊檢索可從刊名、出版地、出版單位以及主題詞途徑等進行檢索。
方法：在期刊檢索輸入框輸入刊名等檢索詞，點擊右側的「瀏覽」按鈕，屏幕顯示有關期刊列表,即有關的刊名和出版單位；欲瀏覽期刊信息，方法1：可直接點擊刊名，進入期刊顯示屏幕。該屏詳細顯示期刊全部信息，如國際期刊代碼、國內期刊代碼、期刊內部代碼、郵發代碼、創刊年、主辦單位地址、郵編、電話、期刊變更注釋、以及主題詞、分類號等內容。方法2：點擊「詞條注釋」按鈕，顯示該期刊主編、編輯單位、編輯部電話、地址、郵編、刊號等內容，可作為投稿信息。
6．主題詞與副主題片語配檢索
主題詞與相應的副主題詞進行組配檢索。副主題詞包括MESH詞表中的82個副主題詞和中醫葯主題詞表中的10多個中醫葯方面的副主題詞。
7．其它組配檢索
在實際檢索過程中，可根據課題需要進行各種組配檢索。如主題詞與自由片語配檢索，主題詞和著者組配檢索，關鍵詞和期刊組配檢索，著者和期刊組配檢索等等。下面舉例說明主題詞和自由詞檢索。
例：急性心肌梗塞的治療
分析：「心肌梗塞」有相應的主題詞, 屬於治療方面的副主題詞有：飲食療法,葯物療法, 外科學, 放射療法,中醫葯療法, 按摩療法, 穴位療法, 針灸療法,中西醫結合療法, 氣功療法等可與之組配, 但沒有「急性心肌梗塞」這個主題詞, 因此用自由詞「急性」來限定。
檢索步驟：
⑴ 在「主題詞」狀態下輸入「心肌梗塞」（Myocardial Infarction），點擊「瀏覽」按鈕或按回車鍵，雙擊被檢索詞，擴展檢索，然後點擊「檢索」按鈕，進入選擇副主題詞界面，用戶可根據需要用滑鼠選中左邊副主題詞框的副主題詞（呈淺藍色），或按下Ctrl鍵選擇多項副主題詞，點擊「添加」按鈕，把選中的副主題詞添加到右邊的選中副主題框里，再點擊「確認」按鈕，可將選擇的副主題詞（框）與之組配限定；
⑵ 在「檢索」狀態下輸入關鍵詞「急性」，點擊「檢索」按鈕；
⑶ 再將以上兩個檢索結果表達式分別「選中」，點擊「AND」按鈕將二者組配，即可得到最後的檢索結果。
二．檢索結果顯示、標記、套錄
⑴ 顯示 用滑鼠雙擊檢索表達式或單擊「顯示」按鈕，即可顯示該檢索結果文獻的題錄，文獻瀏覽格式有題錄和文摘格式選擇，一般系統默認題錄格式，只要點擊「題錄格式」按鈕便切換到文摘格式。
⑵ 標記 在瀏覽狀態下可對相關文獻進行標記，標記時只需用滑鼠點擊選中文獻左上角書本圖標，該條記錄左邊即顯示一列紅色星號，再點擊紅色星號便取消標記。標記後點擊「顯標注」按鈕，即可對標記記錄和全部記錄進行選擇瀏覽。
⑶ 套錄 選中標記後，點擊「套錄」按鈕，彈出套錄窗口，點擊「套錄參數」按鈕逐項選擇「確認」後，進行選擇相應文本框內輸入存檔路徑、文件名及存檔的文獻類型等，即把命中文獻存檔。點擊「追加」按鈕，可將多次檢索標記的文獻存入同一文件名下。
⑷ 列印 在選中標記後，點擊「列印」按鈕，彈出列印窗口，點擊「列印參數」按鈕逐項選擇「確認」後，最後按「列印」按鈕即可進行列印。
資料庫檢索完畢後，直接點擊頁面右上角「╳」符號即可。
如若滿意，請點擊右側【採納答案】，如若還有問題，請點擊【追問】
希望我的回答對您有所幫助，望採納！
~ O(∩_∩)O~
B. 軟體開發資料庫如何進行測試
比如：數據冗餘，功能和性能方面存在的問題已經嚴重影響應用軟體的使用。軟體測試人員往往重視對軟體功能和編碼的測試，而忽略對軟體性能，特別是資料庫訪問並發測試。因為，他們固有的思想中認為資料庫設計存在問題對系統性能影響不大，或從根本上忽略了資料庫在軟體開發中的地位，直到出現了問題，才想到對資料庫的測試，但往往也是僅僅通過對編碼的測試工作中捎帶對資料庫進行一定的測試，這遠遠是不夠的。目前，中鐵網上訂票系統在大用戶同時在線訂票中系統頻頻癱瘓，就是最好的佐證。 所以，在應用軟體的測試工作中，應該將資料庫作為一個獨立的部分進行充分的測試，這樣才可以得到應用軟體所需要的性能優化的資料庫。那麼，應該對哪些內容進行測試，如何進行測試呢？ 2、資料庫設計的測試 資料庫是應用的基礎，其性能直接影響應用軟體的性能。為了使資料庫具有較好的性能，需要對資料庫中的表進行規范化設計。規范化的範式可分為第一範式、第二範式、第三範式、BCNF範式、第四範式和第五範式。一般來說，邏輯資料庫設計應滿足第三範式的要求，這是因為滿足第三範式的表結構容易維護，且基本滿足實際應用的要求。因此，實際應用中一般都按照第三範式的標准進行規范化。但是，規范化也有缺點：由於將一個表拆分成為多個表，在查詢時需要多表連接，降低了查詢速度。故資料庫設計的測試包括前期需求分析產生資料庫邏輯模型和後期業務系統開發中的測試兩部分（這里指的是後者），我在這里稱為實體測試。 資料庫是由若乾的實體組成的，包括（表，視圖，存儲過程等），資料庫最基本的測試就是實體測試，通過對這些實體的測試，可以發現資料庫實體設計得是否充分，是否有遺漏，每個實體的內容是否全面，擴展性如何。 實體測試，可以用來發現應用軟體在功能上存在的不足，也可以發現數據冗餘的問題。經過測試，測試人員對有異議的問題要及時和資料庫的設計人員進行溝通解決。 3、數據一致性測試 在進行實體測試後，應進一步檢查下面的內容以保障數據的一致性： 3.1 表的主鍵測試根據應用系統的實際需求，對每個表的主鍵進行測試，驗證是否存在記錄不唯一的情況，如果有，則要重新設置主鍵，使表中記錄唯一。 3.2 表之間主外鍵關系的測試資料庫中主外鍵欄位在名稱，數據類型，欄位長度上的一致性測試。 3.3 級聯表，刪除主表數據後，相應從報表數據應同時刪除的問題例如學生表和學生成績表，學生數據已經刪除，成績表中相應學生的成績記錄應同時刪除。 3.4 存儲過程和觸發器的測試存儲過程可以人工執行，但觸發器不能人工處理，所以在對存儲過程和觸發器執行的過程中針對sql SERVER2005及以上版本可以使用Microsoft SQL Server Profiler性能測試工具進行測試。 Microsoft SQL Server Profiler 是 SQL 跟蹤的圖形用戶界面，用於監視資料庫引擎或 Analysis Services 的實例。測試人員可以捕獲有關每個事件的數據並將其保存到文件或表中供以後分析。例如：可以對生產環境進行監視，了解哪些存儲過程由於執行速度太慢影響了性能。 4、資料庫的容量測試 隨著資料庫系統的使用，數據量在飛速增長，如何在使用前對數據容量的增長情況進行初步估算，為最終用戶提供參考，這在資料庫使用和維護過程中，是非常重要的。可以通過對資料庫設計中基本表的數據大小，和每天數據表的數據產生量進行初步估算。 記錄數據量=各個欄位所佔位元組數的總和表的數據量=記錄數據量*記錄數資料庫大小=各表數據量的總和 當然，資料庫的大小不僅僅只是基本表的大小，還有系統表，視圖，存儲過程等其它實體所佔的容量，但最基本的數據是表的數據。另外，資料庫的容量還包括資料庫日誌文件的容量，一般應預留資料庫文件的2倍左右。 5、資料庫的性能測試 應用軟體除了功能外，很重要的一部分就是軟體的性能，而對於資料庫系統，資料庫性能的好壞會直接影響應用軟體的性能，這部分的測試，一般手工測試就顯得無能為力了，這時就要藉助自動化的測試軟體，例如：DataFactory，DataFactory是一種強大的數據產生器，它允許開發人員和測試人員很容易產生百萬行有意義的正確的測試資料庫，該工具支持DB2、Oracle、Sybase、SQL Server資料庫。這樣，就可以模擬出應用軟體長期使用後，海量數據存儲的資料庫的性能狀況。從而盡早發現問題，進行資料庫性能的優化。 這里要注意，進行性能測試的時候，一定要注意測試環境的一致性，包括：操作系統、應用軟體的版本以及硬體的配置等，而且在進行資料庫方面的測試的時候一定要注意資料庫的記錄數、配置等要一致，只有在相同條件下進行測試，才可以對結果進行比較。否則無法和用戶對軟體的性能的觀點達成一致。 6、資料庫的壓力測試 說起測試，我們首先想到的就是軟體正確性的測試，即常說的功能測試。軟體功能正確僅是軟體質量合格指標之一。在實際開發中，還有其它的非功能因素也起著決定性的因素，例如軟體的響應速度。影響軟體響應速度的因素有很多，有些是因為演算法不夠高效；還有些可能受用戶並發數的影響。 在眾多類型的軟體測試中，壓力測試正是以軟體響應速度為測試目標，尤其是針對在較短時間內大量並發用戶的訪問時，軟體的抗壓能力。但壓力測試往往是手工難以測試的，必須藉助自動化測試工具。常用的壓力測試有：Web測試、資料庫測試等。 資料庫在大多數軟體項目中是不可缺少的，對於它進行壓力測試是為了找出資料庫對象是否可以有效地承受來自多個用戶的並發訪問。這些對象主要是：索引、觸發器、存儲過程和鎖。通過對SQL語句和存儲過程的測試，自動化的壓力測試工具可以間接的反應資料庫對象是否需要優化。 這些自動化的測試工具很多，各有特點，基於Java的項目可以使用JMeter，.Net項目可以採用.Net集成開發環境中提供的測試方案。 7、結束語 總之，在應用系統的測試中，把資料庫應當作為獨立的系統來測試，這無疑會為應用軟體的質量增加可靠的保障，同時還必須結合應用軟體進行集成測試，只有二者有機結合起來，才能最大限度的發揮資料庫和應用軟體的功能。
C. 常用的醫學資料庫和網路醫學資源有哪些
有MEDLINE、《中華醫學雜志》、骨密度資料庫、CBM、PubMed等。
1、MEDLINE
MEDLINE是美國國立醫學圖書館(The National Library of Medicine, 簡稱NLM)生產的國際性綜合生物醫學信息書目資料庫，是當前國際上最權威的生物醫學文獻資料庫。
內容包括美國《醫學索引》（Index Medicus, IM）的全部內容和《牙科文獻索引》（Index to Dental Literature）、《國際護理索引》（International Nursing Index）的部分內容。
2、《中華醫學雜志》
《中華醫學雜志》是1915年創辦的雙語學術期刊，周刊，中國科學技術協會主管，中華醫學會主辦。
期刊主要反映中國醫學最新的科研成果，積極推廣醫葯衛生領域的新技術、新成果，及時交流防病治病的新經驗。
3、骨密度資料庫
2004 年11 月，GE 公司與中華醫學會合作, 完成中國大陸骨密度正常值資料庫項目，開創了中國骨密度發展的新時代，是中國醫學界將臨床問題數字化的一項巨大突破。
該項目的完成， 徹底結束了用其他人種的標准診斷中國人骨密度狀況的混亂局面，樹立了醫生和患者對骨密度測量和骨質疏鬆定量診斷的信任。
4、CBM
CBM由中國醫學科學院醫學信息研究所/圖書館開發研製的中國生物醫學文獻服務系統（SinoMed）；
整合了中國生物醫學文獻資料庫（CBM）、西文生物醫學文獻資料庫（WBM）、北京協和醫學院博碩學位論文庫等多種資源，是集檢索、免費獲取、個性化定題服務、全文傳遞服務於一體的生物醫學中外文整合文獻服務系統。
可訪問中國生物醫學文獻資料庫（CBM）資源 ，北京協和醫學院博碩學位論文庫（每篇論文的前30頁內容）。
CBM收錄1978以來1600餘種中國生物醫學期刊，以及匯編、會議論文的文獻題錄530餘萬篇，全部題錄均進行主題標引和分類標引等規范化加工處理。年增文獻40餘萬篇，每月更新。
5、PubMed
PubMed 資料庫是美國國立醫學圖書館(National libraryof Medicine， NLM) 的國家生物技術信息中心(National Center for Biotechnology Information，NCBI)研製開發的， 設在國家健康研究院。
PubMed 資料庫收錄MEDLINE， PRE-MEDLINE， 還有其它如《Science》， 《Nature》 等電子期刊構成的資料庫。 自1996年至今，該資料庫收錄約1000 萬篇生物醫學文獻。
可供檢索的專業為，分子生物學及NCBI 部分的資料庫題錄。它收錄了美國和另外70 個國家出版的生物醫學期刊約3900種。
PubMed 網上更新速度是每周1次。Medline 收錄的大多數論文原始語種是英語， 或有英文摘要。
參考資料來源：網路——醫學資料庫
D. 資料庫索引的操作案例
最普通的情況，是為出現在where子句的欄位建一個索引。為方便講述，先建立一個如下的表。
CREATE TABLE mytable(
idserial primary key,
category_id int not null default0,
user_id int not null default0,
adddate int not null default0
);
如果在查詢時常用類似以下的語句：
SELECT * FROM mytable WHERE category_id=1;
最直接的應對之道，是為category_id建立一個簡單的索引：
CREATE INDEX mytable_categoryid ON mytable (category_id);
OK.如果有不止一個選擇條件呢？例如：
SELECT * FROM mytable WHERE category_id=1 AND user_id=2;
第一反應可能是，再給user_id建立一個索引。不好，這不是一個最佳的方法。可以建立多重的索引。
CREATE INDEX mytable_categoryid_userid ON mytable(category_id,user_id);
注意到在命名時的習慣了嗎？使用表名_欄位1名_欄位2名的方式。很快就會知道為什麼這樣做了。
現在已經為適當的欄位建立了索引，不過，還是有點不放心吧，可能會問，資料庫會真正用到這些索引嗎？測試一下就OK，對於大多數的資料庫來說，這是很容易的，只要使用EXPLAIN命令：
EXPLAIN
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2;
This is what Postgres 7.1 returns (exactlyasI expected)
NOTICE:QUERY PLAN:
Index Scan using mytable_categoryid_userid on
mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
以上是postgres的數據，可以看到該資料庫在查詢的時候使用了一個索引（一個好開始），而且它使用的是創建的第二個索引。看到上面命名的好處了吧，馬上知道它使用適當的索引了。
接著，來個稍微復雜一點的，如果有個ORDERBY 子句呢？不管你信不信，大多數的資料庫在使用orderby的時候，都將會從索引中受益。
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
很簡單，就像為where子句中的欄位建立一個索引一樣，也為ORDER BY的子句中的欄位建立一個索引：
CREATE INDEX mytable_categoryid_userid_adddate ON mytable (category_id,user_id,adddate);
注意:mytable_categoryid_userid_adddate將會被截短為mytable_categoryid_userid_addda
CREATE
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
NOTICE:QUERY PLAN:
Sort(cost=2.03..2.03 rows=1 width=16)
->Index Scanusing mytable_categoryid_userid_addda
on mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
看看EXPLAIN的輸出，資料庫多做了一個沒有要求的排序，這下知道性能如何受損了吧，看來對於資料庫的自身運作是有點過於樂觀了，那麼，給資料庫多一點提示吧。
為了跳過排序這一步，並不需要其它另外的索引，只要將查詢語句稍微改一下。這里用的是postgres，將給該資料庫一個額外的提示--在ORDER BY語句中，加入where語句中的欄位。這只是一個技術上的處理，並不是必須的，因為實際上在另外兩個欄位上，並不會有任何的排序操作，不過如果加入，postgres將會知道哪些是它應該做的。
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY category_id DESC,user_id DESC,adddate DESC;
NOTICE:QUERY PLAN:
Index Scan Backward using
mytable_categoryid_userid_addda on mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
現在使用料想的索引了，而且它還挺聰明，知道可以從索引後面開始讀，從而避免了任何的排序。
以上說得細了一點，不過如果資料庫非常巨大，並且每日的頁面請求達上百萬算，想會獲益良多的。不過，如果要做更為復雜的查詢呢，例如將多張表結合起來查詢，特別是where限制字句中的欄位是來自不止一個表格時，應該怎樣處理呢？通常都盡量避免這種做法，因為這樣資料庫要將各個表中的東西都結合起來，然後再排除那些不合適的行，搞不好開銷會很大。
如果不能避免，應該查看每張要結合起來的表，並且使用以上的策略來建立索引，然後再用EXPLAIN命令驗證一下是否使用了料想中的索引。如果是的話，就OK。不是的話，可能要建立臨時的表來將他們結合在一起，並且使用適當的索引。
要注意的是，建立太多的索引將會影響更新和插入的速度，因為它需要同樣更新每個索引文件。對於一個經常需要更新和插入的表格，就沒有必要為一個很少使用的where字句單獨建立索引了，對於比較小的表，排序的開銷不會很大，也沒有必要建立另外的索引。
以上介紹的只是一些十分基本的東西，其實裡面的學問也不少，單憑EXPLAIN是不能判定該方法是否就是最優化的，每個資料庫都有自己的一些優化器，雖然可能還不太完善，但是它們都會在查詢時對比過哪種方式較快，在某些情況下，建立索引的話也未必會快，例如索引放在一個不連續的存儲空間時，這會增加讀磁碟的負擔，因此，哪個是最優，應該通過實際的使用環境來檢驗。
在剛開始的時候，如果表不大，沒有必要作索引，意見是在需要的時候才作索引，也可用一些命令來優化表，例如MySQL可用OPTIMIZETABLE。
E. mysql資料庫性能測試
我理解的是你希望了解mysql性能測試的方法：
其實常用的一般：
選取最適用的欄位屬性
MySQL可以很好的支持大數據量的存取，但是一般說來，資料庫中的表越小，在它上面執行的查詢也就會越快。因此，在創建表的時候，為了獲得更好的性能，我們可以將表中欄位的寬度設得盡可能小。例如，在定義郵政編碼這個欄位時，如果將其設置為CHAR(255),顯然給資料庫增加了不必要的空間，甚至使用VARCHAR這種類型也是多餘的，因為CHAR(6)就可以很好的完成任務了。同樣的，如果可以的話，我們應該使用MEDIUMINT而不是BIGIN來定義整型欄位。
另外一個提高效率的方法是在可能的情況下，應該盡量把欄位設置為NOT NULL，這樣在將來執行查詢的時候，資料庫不用去比較NULL值。
對於某些文本欄位，例如「省份」或者「性別」，我們可以將它們定義為ENUM類型。因為在MySQL中，ENUM類型被當作數值型數據來處理，而數值型數據被處理起來的速度要比文本類型快得多。這樣，我們又可以提高資料庫的性能。
2、使用連接（JOIN）來代替子查詢(Sub-Queries)
MySQL從4.1開始支持SQL的子查詢。這個技術可以使用SELECT語句來創建一個單列的查詢結果，然後把這個結果作為過濾條件用在另一個查詢中。例如，我們要將客戶基本信息表中沒有任何訂單的客戶刪除掉，就可以利用子查詢先從銷售信息表中將所有發出訂單的客戶ID取出來，然後將結果傳遞給主查詢，如下所示：
DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
使用子查詢可以一次性的完成很多邏輯上需要多個步驟才能完成的SQL操作，同時也可以避免事務或者表鎖死，並且寫起來也很容易。但是，有些情況下，子查詢可以被更有效率的連接（JOIN）.. 替代。例如，假設我們要將所有沒有訂單記錄的用戶取出來，可以用下面這個查詢完成：
SELECT * FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
如果使用連接（JOIN）.. 來完成這個查詢工作，速度將會快很多。尤其是當salesinfo表中對CustomerID建有索引的話，性能將會更好，查詢如下：
SELECT * FROM customerinfo LEFT JOIN salesinfoON customerinfo.CustomerID=salesinfo. CustomerID WHERE salesinfo.CustomerID IS NULL
連接（JOIN）.. 之所以更有效率一些，是因為 MySQL不需要在內存中創建臨時表來完成這個邏輯上的需要兩個步驟的查詢工作。
3、使用聯合(UNION)來代替手動創建的臨時表
MySQL 從 4.0 的版本開始支持 UNION 查詢，它可以把需要使用臨時表的兩條或更多的 SELECT 查詢合並的一個查詢中。在客戶端的查詢會話結束的時候，臨時表會被自動刪除，從而保證資料庫整齊、高效。使用 UNION 來創建查詢的時候，我們只需要用 UNION作為關鍵字把多個 SELECT 語句連接起來就可以了，要注意的是所有 SELECT 語句中的欄位數目要想同。下面的例子就演示了一個使用 UNION的查詢。
SELECT Name, Phone FROM client UNION SELECT Name, BirthDate FROM author
UNION
SELECT Name, Supplier FROM proct
4、事務
盡管我們可以使用子查詢（Sub-Queries）、連接（JOIN）和聯合（UNION）來創建各種各樣的查詢，但不是所有的資料庫操作都可以只用一條或少數幾條SQL語句就可以完成的。更多的時候是需要用到一系列的語句來完成某種工作。但是在這種情況下，當這個語句塊中的某一條語句運行出錯的時候，整個語句塊的操作就會變得不確定起來。設想一下，要把某個數據同時插入兩個相關聯的表中，可能會出現這樣的情況：第一個表中成功更新後，資料庫突然出現意外狀況，造成第二個表中的操作沒有完成，這樣，就會造成數據的不完整，甚至會破壞資料庫中的數據。要避免這種情況，就應該使用事務，它的作用是：要麼語句塊中每條語句都操作成功，要麼都失敗。換句話說，就是可以保持資料庫中數據的一致性和完整性。事物以BEGIN 關鍵字開始，COMMIT關鍵字結束。在這之間的一條SQL操作失敗，那麼，ROLLBACK命令就可以把資料庫恢復到BEGIN開始之前的狀態。
BEGIN;
INSERT INTO salesinfo SET CustomerID=14;
UPDATE inventory SET Quantity=11
WHERE item='book';
COMMIT;
事務的另一個重要作用是當多個用戶同時使用相同的數據源時，它可以利用鎖定資料庫的方法來為用戶提供一種安全的訪問方式，這樣可以保證用戶的操作不被其它的用戶所干擾。
5、鎖定表
盡管事務是維護資料庫完整性的一個非常好的方法，但卻因為它的獨占性，有時會影響資料庫的性能，尤其是在很大的應用系統中。由於在事務執行的過程中，資料庫將會被鎖定，因此其它的用戶請求只能暫時等待直到該事務結束。如果一個資料庫系統只有少數幾個用戶
來使用，事務造成的影響不會成為一個太大的問題；但假設有成千上萬的用戶同時訪問一個資料庫系統，例如訪問一個電子商務網站，就會產生比較嚴重的響應延遲。
其實，有些情況下我們可以通過鎖定表的方法來獲得更好的性能。下面的例子就用鎖定表的方法來完成前面一個例子中事務的功能。
LOCK TABLE inventory WRITE
SELECT Quantity FROM inventory
WHEREItem='book';
...
UPDATE inventory SET Quantity=11
WHEREItem='book';
UNLOCK TABLES
這里，我們用一個 SELECT 語句取出初始數據，通過一些計算，用 UPDATE 語句將新值更新到表中。包含有 WRITE 關鍵字的 LOCK TABLE 語句可以保證在 UNLOCK TABLES 命令被執行之前，不會有其它的訪問來對 inventory 進行插入、更新或者刪除的操作。
6、使用外鍵
鎖定表的方法可以維護數據的完整性，但是它卻不能保證數據的關聯性。這個時候我們就可以使用外鍵。例如，外鍵可以保證每一條銷售記錄都指向某一個存在的客戶。在這里，外鍵可以把customerinfo 表中的CustomerID映射到salesinfo表中CustomerID，任何一條沒有合法CustomerID的記錄都不會被更新或插入到salesinfo中。
CREATE TABLE customerinfo
(
CustomerID INT NOT NULL ,
PRIMARY KEY ( CustomerID )
) TYPE = INNODB;
CREATE TABLE salesinfo
(
SalesID INT NOT NULL,
CustomerID INT NOT NULL,
PRIMARY KEY(CustomerID, SalesID),
FOREIGN KEY (CustomerID) REFERENCES customerinfo
(CustomerID) ON DELETECASCADE
) TYPE = INNODB;
注意例子中的參數「ON DELETE CASCADE」。該參數保證當 customerinfo 表中的一條客戶記錄被刪除的時候，salesinfo 表中所有與該客戶相關的記錄也會被自動刪除。如果要在 MySQL 中使用外鍵，一定要記住在創建表的時候將表的類型定義為事務安全表 InnoDB類型。該類型不是 MySQL 表的默認類型。定義的方法是在 CREATE TABLE 語句中加上 TYPE=INNODB。如例中所示。
7、使用索引
索引是提高資料庫性能的常用方法，它可以令資料庫伺服器以比沒有索引快得多的速度檢索特定的行，尤其是在查詢語句當中包含有MAX(), MIN()和ORDERBY這些命令的時候，性能提高更為明顯。那該對哪些欄位建立索引呢？一般說來，索引應建立在那些將用於JOIN, WHERE判斷和ORDER BY排序的欄位上。盡量不要對資料庫中某個含有大量重復的值的欄位建立索引。對於一個ENUM類型的欄位來說，出現大量重復值是很有可能的情況，例如customerinfo中的「province」.. 欄位，在這樣的欄位上建立索引將不會有什麼幫助；相反，還有可能降低資料庫的性能。我們在創建表的時候可以同時創建合適的索引，也可以使用ALTER TABLE或CREATE INDEX在以後創建索引。此外，MySQL
從版本3.23.23開始支持全文索引和搜索。全文索引在MySQL 中是一個FULLTEXT類型索引，但僅能用於MyISAM 類型的表。對於一個大的資料庫，將數據裝載到一個沒有FULLTEXT索引的表中，然後再使用ALTER TABLE或CREATE INDEX創建索引，將是非常快的。但如果將數據裝載到一個已經有FULLTEXT索引的表中，執行過程將會非常慢。
8、優化的查詢語句
絕大多數情況下，使用索引可以提高查詢的速度，但如果SQL語句使用不恰當的話，索引將無法發揮它應有的作用。下面是應該注意的幾個方面。首先，最好是在相同類型的欄位間進行比較的操作。在MySQL 3.23版之前，這甚至是一個必須的條件。例如不能將一個建有索引的INT欄位和BIGINT欄位進行比較；但是作為特殊的情況，在CHAR類型的欄位和VARCHAR類型欄位的欄位大小相同的時候，可以將它們進行比較。其次，在建有索引的欄位上盡量不要使用函數進行操作。
例如，在一個DATE類型的欄位上使用YEAE()函數時，將會使索引不能發揮應有的作用。所以，下面的兩個查詢雖然返回的結果一樣，但後者要比前者快得多。
SELECT * FROM order WHERE YEAR(OrderDate)<2001;
SELECT * FROM order WHERE OrderDate<"2001-01-01";
同樣的情形也會發生在對數值型欄位進行計算的時候：
SELECT * FROM inventory WHERE Amount/7<24;
SELECT * FROM inventory WHERE Amount<24*7;
上面的兩個查詢也是返回相同的結果，但後面的查詢將比前面的一個快很多。第三，在搜索字元型欄位時，我們有時會使用 LIKE 關鍵字和通配符，這種做法雖然簡單，但卻也是以犧牲系統性能為代價的。例如下面的查詢將會比較表中的每一條記錄。
SELECT * FROM books
WHERE name like "MySQL%"
但是如果換用下面的查詢，返回的結果一樣，但速度就要快上很多：
SELECT * FROM books
WHERE name>="MySQL"and name<"MySQM"
最後，應該注意避免在查詢中讓MySQL進行自動類型轉換，因為轉換過程也會使索引變得不起作用。
F. 如何使用AWR報告來診斷資料庫性能問題
一般來說，當檢測到性能問題時，我們會收集覆蓋了發生問題的時間段的AWR報告-但是最好只收集覆蓋1個小時時間段的AWR報告-如果時間過長，那麼AWR報告就不能很好的反映出問題所在。還應該收集一份沒有性能問題的時間段的AWR報告，作為一個參照物來對比有問題的時間段的AWR報告。這兩個AWR報告的時間段應該是一致的，比如都是半個小時的，或者都是一個小時的。
Interpretation
在處理性能問題時，我們最關注的是資料庫正在等待什麼。
當進程因為某些原因不能進行操作時，它需要等待。花費時間最多的等待事件是我們最需要關注的，因為降低它，我們能夠獲得最大的好處。
AWR報告中的"Top 5 Timed Events"部分就提供了這樣的信息，可以讓我們只關注主要的問題。
Top 5 Timed Events
正如前面提到的，"Top 5 Timed Events"是AWR報告中最重要的部分。它指出了資料庫的sessions花費時間最多的等待事件，如下：
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
db file scattered read 10,152,564 81,327 8 29.6 User I/O
db file sequential read 10,327,231 75,878 7 27.6 User I/O
CPU time 56,207 20.5
read by other session 4,397,330 33,455 8 12.2 User I/O
PX Deq Credit: send blkd 31,398 26,576 846 9.7 Other
-------------------------------------------------------------
Top 5 Events部分包含了一些跟Events（事件）相關的信息。它記錄了這期間遇到的等待的總次數，等待所花費的總時間，每次等待的平均時間；這一部分是按照每個Event占總體call time的百分比來進行排序的。
根 據Top 5 Events部分的信息的不同，接下來我們需要檢查AWR報告的其他部分，來驗證發現的問題或者做定量分析。等待事件需要根據報告期的持續時間和當時數據 庫中的並發用戶數進行評估。如：10分鍾內1000萬次的等待事件比10個小時內的1000萬等待更有問題；10個用戶引起的1000萬次的等待事件比 10,000個用戶引起的相同的等待要更有問題。
就像上面的例子，將近60%的時間是在等待IO相關的事件。
其他20%的時間是花在使用或等待CPU time上。過高的CPU使用經常是性能不佳的SQL引起的（或者這些SQL有可能用更少的資源完成同樣的操作）；對於這樣的SQL，過多的IO操作也是一個症狀。關於CPU使用方面，我們會在之後討論。
在以上基礎上，我們將調查是否這個等待事件是有問題的。若有問題，解決它；若是正常的，檢查下個等待事件。
過多的IO相關的等待一般會有兩個主要的原因：
Top 5 Events部分的顯示的信息會幫助我們檢查：
需要注意，接下來的分析步驟取決於我們在TOP 5部分的發現。在上面的例子里，3個top wait event表明問題可能與SQL語句執行計劃不好有關，所以接下來我們要去分析"SQL Statistics"部分。
同樣的，因為我們並沒有看到latch相關的等待，latch在我們這個例子里並沒有引發嚴重的性能問題；那麼我們接下來就完全不需要分析latch相關的信息。
一 般來講，如果資料庫性能很慢，TOP 5等待事件里"CPU"， "db file sequential read" 和"db file scattered read" 比較明顯（不管它們之間的順序如何），我們總是需要檢查Top SQL (by logical and physical reads)部分；調用SQL Tuning Advisor或者手工調優這些SQL來確保它們是有效率的運行。
是否資料庫做了大量的讀操作：
上面的圖顯示了在這段時間里兩類讀操作都分別大於1000萬，這些操作是否過多取決於報告的時間是1小時或1分鍾。我們可以檢查AWR報告的elapsed time如果這些讀操作確實是太多了，接下來我們需要檢查AWR報告中 SQL Statistics 部分的信息，因為讀操作都是由SQL語句發起的。
是否是每次的IO讀操作都很慢：
上面的圖顯示了在這段時間里兩類讀操作平均的等待時間是小於8ms的
至於8ms是快還是慢取決於底層的硬體設備；一般來講小於20ms的都可以認為是可以接受的。
我們還可以在AWR報告"Tablespace IO Stats"部分得到更詳細的信息
Tablespace IO Stats DB/Inst: VMWREP/VMWREP Snaps: 1-15
-> ordered by IOs (Reads + Writes) desc
Tablespace
------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
TS_TX_DATA
14,246,367 283 7.6 4.6 145,263,880 2,883 3,844,161 8.3
USER
204,834 4 10.7 1.0 17,849,021 354 15,249 9.8
UNDOTS1
19,725 0 3.0 1.0 10,064,086 200 1,964 4.9
AE_TS
4,287,567 85 5.4 6.7 932 0 465,793 3.7
TEMP
2,022,883 40 0.0 5.8 878,049 17 0 0.0
UNDOTS3
1,310,493 26 4.6 1.0 941,675 19 43 0.0
TS_TX_IDX
1,884,478 37 7.3 1.0 23,695 0 73,703 8.3
>SYSAUX
346,094 7 5.6 3.9 112,744 2 0 0.0
SYSTEM
101,771 2 7.9 3.5 25,098 0 653 2.7
如上圖，我們關心Av Rd(ms)的指標。如果它高於20ms並且同時有很多讀操作的，我們可能要開始從OS的角度調查是否有潛在的IO問題。
註：對於一些比較空閑的tablespace/files,我們可能會得到一個比較大的Av Rd(ms)值；對於這樣的情況，我們應該忽略這樣的tablespace/files;因為這個很大的值可能是由於硬碟自旋(spin)引起的，沒有太大的參考意義。比如對
於一個有1000萬次讀操作而且很慢的系統，引起問題的基本不可能是一個只有10次read的tablespace/file.
雖 然高"db file scattered read"和"db file sequential read"等待可以是I / O相關的問題，但是很多時候這些等待也可能是正常的；實際上，對一個已經性能很好的資料庫系統，這些等待事件往往在top 5等待事件里，因為這意味著您的資料庫沒有那些真正的「問題」。
訣竅是能夠評估引起這些等待的語句是否使用了最優的訪問路徑。如果"db file scattered read"比較高，那麼相關的SQL語句可能使用了全表掃描而沒有使用索引（也許是沒有創建索引，也許是沒有合適的索引）；相應的，如果"db file sequential read"過多，則表明也許是這些SQL語句使用了selectivity不高的索引從而導致訪問了過多不必要的索引塊或者使用了錯誤的索引。這些等待可 能說明SQL語句的執行計劃不是最優的。
接下來就需要通過AWR來檢查這些top SQL是否可以進一步的調優，我們可以查看AWR報告中 SQL Statistics 的部分.
上面的例子顯示了20%的時間花在了等待或者使用CPU上，我們也需要檢查 SQL statistics 部分來進一步的分析。
資料庫做了太多的讀操作
每次的IO讀操作都很慢
事件"db file scattered read"一般表明正在做由全表掃描或者index fast full scan引起的多塊讀。
事件"db file sequential read"一般是由不能做多塊讀的操作引起的單塊讀（如讀索引）
SQL Statistics
AWR包含了一些不同的SQL統計值：
根據Top 5 部分的Top Wait Event不同，我們需要檢查不同的SQL statistic。
在我們這個例子里，Top Wait Event是"db file scattered read"，"db file sequential read"和CPU；我們最需要關心的是SQL ordered by CPU Time, Gets and Reads。
我們會從"SQL ordered by gets"入手，因為引起高buffer gets的SQL語句一般是需要調優的對象。
SQL ordered by Gets
-> Resources reported for PL/SQL code includes the resources used by all SQL
statements called by the code.
-> Total Buffer Gets: 4,745,943,815
-> Captured SQL account for 122.2% of Total
Gets CPU Elapsed
Buffer Gets Executions per Exec %Total Time (s) Time (s) SQL Id
-------------- ------------ ------------ ------ -------- --------- -------------
1,228,753,877 168 7,314,011.2 25.9 8022.46 8404.73 5t1y1nvmwp2
SELECT ADDRESSID",CURRENT$."ADDRESSTYPEID",CURRENT$URRENT$."ADDRESS3",
CURRENT$."CITY",CURRENT$."ZIP",CURRENT$."STATE",CURRENT$."PHONECOUNTRYCODE",
CURRENT$."PHONENUMBER",CURRENT$."PHONEEXTENSION",CURRENT$."FAXCOU
1,039,875,759 62,959,363 16.5 21.9 5320.27 5618.96 grr4mg7ms81
Mole: DBMS_SCHEDULER
INSERT INTO "ADDRESS_RDONLY" ("ADDRESSID","ADDRESSTYPEID","CUSTOMERID","
ADDRESS1","ADDRESS2","ADDRESS3","CITY","ZIP","STATE","PHONECOUNTRYCODE","PHONENU
854,035,223 168 5,083,543.0 18.0 5713.50 7458.95 4at7cbx8hnz
SELECT "CUSTOMERID",CURRENT$."ISACTIVE",CURRENT$."FIRSTNAME",CURRENT$."LASTNAME",CU<
RRENT$."ORGANIZATION",CURRENT$."DATEREGISTERED",CURRENT$."CUSTOMERSTATUSID",CURR
ENT$."LASTMODIFIEDDATE",CURRENT$."SOURCE",CURRENT$."EMPLOYEEDEPT",CURRENT$.
對這些Top SQL,可以手工調優，也可以調用SQL Tuning Advisor。
分析：
Other SQL Statistic Sections
就像之前提到的那樣，AWR報告中有很多不同的部分用來分析各種不同的問題。如果特定的問題並沒有出現，那麼分析AWR報告的這些部分並不能有很大的幫助。
下面提到了一些可能的問題：
Waits for 'Cursor: mutex/pin' 如 果發現了一些像"Cursor: pin S wait on X" 或"Cursor: mutex X" 類的mutex等待，那麼可能是由於parsing引起的問題。檢查"SQL ordered by Parse Calls" 和"SQL ordered by Version Count"部分的Top SQL，這些SQL可能引起這類的問題。
單次執行buffer gets過多
SQL_ID為'5t1y1nvmwp2'和'4at7cbx8hnz'的SQL語句總共被執行了168次，但是每次執行引起的buffer gets超過500萬。這兩個SQL應該是主要的需要調優的候選者。
執行次數過多
SQL_ID 'grr4mg7ms81' 每次執行只是引起16次buffer gets,減少這條SQL每次執行的buffer get可能並不能顯著減少總共的buffer gets。這條語句的問題是它執行的太頻繁了，6500萬次。
改變這條SQL的執行次數可能會更有意義。這個SQL看起來是在一個循環裡面被調用，如果可以讓它一次處理的數據更多也許可以減少它執行的次數。
-> Total Buffer Gets: 4,745,943,815
假設這是一個一個小時的AWR報告，4,745,943,815是一個很大的值；所以需要進一步分析這個SQL是否使用了最優的執行計劃
Indivial Buffer Gets
上面的例子里單個的SQL的buffer get非常多，最少的那個都是8億5千萬。這三個SQL指向了兩個不同的引起過多buffers的原因：
注意：對於某些非常繁忙的系統來講，以上的數字可能都是正常的。這時候我們需要把這些數字跟正常時段的數字作對比，如果沒有什麼太大差別，那麼這些SQL並不是引起問題的元兇（雖然通過調優這些SQL我們仍然可以受益）
Load Profile
根據Top 5等待事件的不同，"Load Profile"可以提供一些有用的背景資料或潛在問題的細節信息。
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 4,585,414.80 3,165,883.14
Logical reads: 94,185.63 65,028.07
Block changes: 40,028.57 27,636.71
Physical reads: 2,206.12 1,523.16
Physical writes: 3,939.97 2,720.25
User calls: 50.08 34.58
Parses: 26.96 18.61
Hard parses: 1.49 1.03
Sorts: 18.36 12.68
Logons: 0.13 0.09
Executes: 4,925.89 3,400.96
Transactions: 1.45
% Blocks changed per Read: 42.50 Recursive Call %: 99.19
Rollback per transaction %: 59.69 Rows per Sort: 1922.64
在這個例子里，Top 5 Events部分顯示問題可能跟SQL的執行有關，那麼我們接下來檢查load profile部分。
如果您檢查AWR report是為了一般性的性能調優，那麼可以看到有比較多的redo activity和比較高的physical writes. Physical writes比physical read要高，並且有42%的塊被更改了.
此外，hard parse的次數要少於soft parse.
如果mutex等待事件比較嚴重，如"library cache: mutex X"，那麼查看所有parse的比率會更有用。
當然，如果把Load Profile部分跟正常時候的AWR報告做比較會更有用，比如，比較redo size, users calls, 和 parsing這些性能指標。
Instance Efficiency
Instance Efficiency部分更適用於一般性的調優，而不是解決某個具體問題（除非等待事件直接指向這些指標）。
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.91 Redo NoWait %: 100.00
Buffer Hit %: 98.14 In-memory Sort %: 99.98
Library Hit %: 99.91 Soft Parse %: 94.48
Execute to Parse %: 99.45 Latch Hit %: 99.97
Parse CPU to Parse Elapsd %: 71.23 % Non-Parse CPU: 99.00
從我們的這個例子來看，最有用的信息是%Non-Parse CPU，它表明幾乎所有的CPU都消耗在了Execution而不是Parse上，所以調優SQL會對性能有改善。
G. 為了測試資料庫查詢的效率是否提升,經常使用索引來實現,請問什麼是索引 有什麼作用 原理是什麼
一、什麼是索引？
索引就像是書的目錄，是與表或者視圖關聯磁碟上的結構，可以加快從表中或者視圖中檢索行的速度。素銀中包含表或者視圖中的一行或者多列生成的鍵。這些鍵存儲在一個結構（BTree）中，使SQL可以快速有效的查找與鍵值關聯的行。
二、有什麼用？即索引的優點
建立索引的行可以保證行的唯一性，生成唯一的word
建立索引可以有效的縮短數據的檢索時間
建立索引可以加快表與表之間的 連接
為用來排序或者是分組的欄位添加索引可以加快和排序順序
無索引，直接去讀表數據存放的磁碟快，督導數據緩沖區中再去查找需要的數據
有索引，先讀入索引表，通過索引表直接去找到需要數據的物理地址，並把數據讀入數據緩沖區中。
三、索引的原理
通過不斷地縮小想要獲取數據的范圍來篩選出最終想要的結果，同時把隨機的事件變成順序的事件，也就是說，有了這種索引機制，我們可以總是用同一種查找方式來鎖定數據。
H. 中英文醫學文獻檢索的資料庫各有哪些
常見的英文醫學檢索資料庫：
1、Medline——世界上最著名的醫學文獻檢索系統之一
2、AIDS Databases——有關艾滋病的臨床實驗、葯物研製以及相關文獻資料庫
3、CANCERLIT——癌症資料庫(National Cancer Institute)
4、CHID online——綜合衛生信息資料庫，提供有關衛生、衛生教育資源的題錄、文摘等信息
5、ClinicalTrials.gov——向醫患人員提供的臨床實驗信息資料庫
6、DIRLINE——收集美國約17,000個政府機構、研究機構、公司、學術機構等信息
7、葯物信息庫——包含有9,000餘種美國處方與非處方葯物信息
8、HSTAT——包括有健康指南、評價、和消費者指南信息的全文資料庫
9、NCCAM Resources——補充和替代醫學資源
常見的中文醫學檢索資料庫：
1、中國知網——知網，是國家知識基礎設施的概念。
2、生物醫學文獻資料庫——中國醫科院信息研究所研製，綜合性生物醫學資料庫，國內權威。
3、中國科學引文索引資料庫——收集我國出版315種重要期刊，91-94年13萬篇論文及45萬引文摘要。
4、中醫中葯資料庫——中國科學院科學資料庫提供
5、中國中醫葯文獻檢索中心——由中國中醫研究院信息中心製作，提供中醫葯方面的Web界面文獻檢
I. Oracle資料庫中的索引詳解
一 ROWID的概念
存儲了row在數據文件中的具 *** 置 位編碼的數據 A Z a z + 和 /
row在數據塊中的存儲方式
SELECT ROWID last_name FROM hr employees WHERE department_id = ;
比如 OOOOOOFFFBBBBBBRRR
OOOOOO data object number 對應dba_objects data_object_id
FFF file# 對應v$datafile file#
BBBBBB block#
RRR row#
Dbms_rowid包
SELECT dbms_rowid rowid_block_number( AAAGFqAABAAAIWEAAA ) from al;
具體到特定的物理文件
二 索引的概念
類似書的目錄結構
Oracle 的 索引 對象 與表關聯的可選對象 提高SQL查詢語句的速度
索引直接脊滑指向包含所查詢值的行的位置 減少磁碟I/O
與所索引的表是相互獨立的物理結構
Oracle 自動使用並維護索引 插入 刪除 更新表後 自動更新索引
語法 CREATE INDEX index ON table (column[ column] );
B tree結構(非bitmap)
[一]了解索引的工櫻拿臘作原理
表 emp
目標 查詢Frank的工資salary
建立索引 create index emp_name_idx on emp(name);
[試驗]測試索引的作用
運行/rdbms/admin/utlxplan 腳本
建立測試表
create table t as select * from dba_objects;
insert into t select * from t;
create table indextable
as select rownum id owner object_name subobject_name
object_id data_object_id object_type created
from t;
set autotrace trace explain
set timing on
分析表 可以得到cost
查詢 object_name= DBA_INDEXES
在object_name列上建立索引
再查詢
[思考]索引的代價
插入 更新
三 唯一索引
何時創建 當某列任意兩行的值都不相同
當建立Primary Key(主鍵)或者Unique constraint(唯一約束)時 唯一索引將被自動建立
語法 CREATE UNIQUE INDEX index ON table (column);
演示
四 組合索引
何時創建 當兩個或多個列經常一起出現在where條件中時 則在這些列上同時創建組合索引
組合索引中列的順序是任意的 也無需相鄰 但是建議將最頻繁訪問的列放在列表的最前面
演示(組合列 單獨列)
五 點陣圖索引
何時創建
列中有非常多的重復的值時候 例如某列保存了 性別 信息
Where 條件中包含了很多OR操作符
較少的update操作 因敏稿為要相應的跟新所有的bitmap
結構 點陣圖索引使用點陣圖作為鍵值 對於表中的每一數據行點陣圖包含了TRUE( ) FALSE( ) 或NULL值
優點 點陣圖以一種壓縮格式存放 因此佔用的磁碟空間比標准索引要小得多
語法 CREATE BITMAP INDEX index ON table (column[ column] );
掩飾
create table bitmaptable as select * from indextable where owner in( SYS PUBLIC );
分析 查找 建立索引 查找
六 基於函數的索引
何時創建 在WHERE條件語句中包含函數或者表達式時
函數包括 算數表達式 PL/SQL函數 程序包函數 SQL函數 用戶自定義函數
語法 CREATE INDEX index ON table (FUNCTION(column));
演示
必須要分析表 並且query_rewrite_enabled=TRUE
或者使用提示/*+ INDEX(ic_index)*/
七 反向鍵索引
目的 比如索引值是一個自動增長的列
多個用戶對集中在少數塊上的索引行進行修改 容易引起資源的爭用 比如對數據塊的等待 此時建立反向索引
性能問題
語法
重建為標准索引 反之不行
八 鍵壓縮索引
比如表landscp的數據如下
site feature job
Britten Park Rose Bed Prune
Britten Park Rose Bed Mulch
Britten Park Rose Bed Spray
Britten Park Shrub Bed Mulch
Britten Park Shrub Bed Weed
Britten Park Shrub Bed Hoe
……
查詢時 以上 列均在where條件中同時出現 所以建立基於以上 列的組合索引 但是發現重復值很多 所以考慮壓縮特性
Create index zip_idx
on landscp(site feature job)
press ;
將索引項分成前綴(prefix)和後綴(postfix)兩部分 前兩項被放置到前綴部分
Prefix : Britten Park Rose Bed
Prefix : Britten Park Shrub Bed
實際所以的結構為
Prune
Mulch
Spray
Mulch
Weed
Hoe
特點 組合索引的前綴部分具有非選擇性時 考慮使用壓縮 減少I/O 增加性能
九 索引組織表(IOT)
將表中的數據按照索引的結構存儲在索引中 提高查詢速度
犧牲插入更新的性能 換取查詢性能 通常用於數據倉庫 提供大量的查詢 極少的插入修改工作
必須指定主鍵 插入數據時 會根據主鍵列進行B樹索引排序 寫入磁碟
十 分區索引
簇:
A cluster is a group of tables that share the same data blocks because they share mon columns and are often used together
lishixin/Article/program/Oracle/201311/17769