A. GBase8s資料庫sql語句性能緩慢從哪個方面入手分析
在實際的生產運行環境中，很多客戶現場都看到開發人員和系統管理人員遇到很多有關於GBase 8s 資料庫引起的性能問題，進而被多次問起如何進行GBase 8s 資料庫性能調優，
性能優化原則
包括：
性能規劃：深入了解應用與資料庫的交互特徵，確立良好的設計、開發、測試迭代過程，上線前消除模型上的性能瓶頸。
實例調優：建立性能基準，對比調節資料庫、操作系統、存儲、網路等的配置，主動監控、消除瓶頸。
SQL 調優：書寫高效 SQL，優化相關資料庫對象，充分藉助優化器，確定最佳執行計劃。
性能優化流程
首先執行下面的初始檢查：
– 獲取直接用戶的使用反饋，確定性能目標和范圍。
– 獲取性能表現好與壞時的操作系統、資料庫、應用統計信息。
– 對資料庫做一次全面健康檢查。
根據收集的信息，以及對應用特性的了解，構建性能概念模型，明確性能瓶頸所在，以及導致性能的根本原因。
– 首先應該排除操作系統、硬體資源造成的瓶頸。
– 然後針對資料庫系統性能進行分析
– 必要時，還需要檢查應用日誌，因為系統性能問題也可能由於應用非 SQL 部分造成瓶頸。
提出一系列針對的優化措施，並根據它們對性能改善的重要程度排序，然後逐一加以實施。不要一次執行所有的優化措施，必須逐條嘗試，逐步對比。
通過獲取直接用戶的反饋驗證調節是否已經產生預期的效果，否則，需要重新提煉性能概念模型，直到對應用特性了解進一步准確。
重復上述，直到性能達到目標或由於客觀約束無法進一步優化。
常見調優技巧
找到 CPU 佔用最高的 SQL
在 sysmaster 庫中執行
select sqx_estcost, sqx_sqlstatement
from syssqexplain
order by sqx_estcost desc
1
2
3
注意：此時看到的僅僅是當前正在執行的 SQL
需要多看幾次
onstat 命令
onstat -g act 得到當前正在執行的 SQL
根據 rstcb 列
onstat -u | grep 57c68220
1
從第三列 sessid 得到 SESSION
onstat -g ses SESSION 即可得到當時正在執行的 SQL
一般多找幾個 threads 後，就基本可以確定問題 SQL
得到 SQL 後，利用 set explain on 分析其查詢路徑，看是否未利用索引，在對大表進行全表掃描，根據需要創建相應索引。
找到全表掃描較多的表及其 SQL
得到全表掃描較多的表
-- 系統順序掃描較多時，被多次順序掃描的大表，如果有，應該考慮增加索引
select first 5
substr(t.tabname,0,20) tabname,
substr(dbsname,0,10) dbname,
nrows*rowsize*p.seqscans costs,
substr(p.seqscans,0,8) seqscans,
substr(nrows,0,8) nrows
from sysmaster:sysptprof p , systables t,sysmaster:sysprofile s
where p.tabname = t.tabname
and p.seqscans > s.value/50
and s.name = 'seqscans'
--and s.value > 2000000 and nrows > 2000
order by 3 desc
1
2
3
4
5
6
7
8
9
10
11
12
13
利用 onstat –g ses 0 –r 5/ onstat –g stm 的輸出信息，根據表名，找到可能的 SQL 語句。由於以上獲取 SQL 的辦法是有局限的，如果無法獲取，建議通過查看應用日誌或聯系開發人員查看源代碼的方式來找到。
利用 set explain on 分析其查詢路徑，確認是在對表進行全表掃描，根據需要創建相應索引。
B. 衡量資料庫性能的重要指標
具體來說，本文包括以下內容:
事務
查詢性能
用戶和查詢沖突
容量
配置
NoSQL 資料庫
- 圖1-基於基線評估當前事務響應時間
事務
事務可以觀察真實用戶的行為：能夠在應用交互時捕獲實時性能。眾所周知，測量事務的性能包括獲取整個事務的響應時間和組成事務的各個部分的響應時間。通常我們可以用這些響應時間與滿足事務需求的基線對比，來確定當前事務是否處於正常狀態。
如果你只想衡量應用的某個方面，那麼可以評估事務的行為。所以，盡管容器指標能夠提供更豐富的信息，並且幫助你決定何時對當前環境進行自動測量，但你的事務就足以確定應用性能。無需向應用程序伺服器獲取 CPU 的使用情況，你更應該關心用戶是否完成了事務，以及該事務是否得到了優化。
補充一個小知識點，事務是由入口點決定的，通過該入口點可以啟動事務與應用進行交互。
一旦定義了事務，會在整個應用生態系統中對其性能進行測量，並將每個事務與基線進行比對。例如，我們可能會決定當事務的響應時間與基線相比，一旦慢於平均響應時間的兩個標准差是否就應該判定為異常，如圖1所示。
用於評估事務的基線與正在進行的事務活動在時間上是一致的，但事務會由每個事務執行來完善。例如，當你選定一個基線，在當前事務結束之後，將事務與平均響應時間按每天的小時數和每周的天數進行對比，所有在那段時間內執行的事務都將會被納入下周的基線中。通過這種機制，應用程序可以隨時間而變化，而無需每次都重建原始基線；你可以將其看作是一個隨時間移動的窗口。
總之，事務最能反映用戶體驗的測量方法，所以也是衡量性能狀況最重要的指標。
查詢性能
最容易檢測到查詢性能是否正常的指標就是查詢本身。由查詢引起的問題可能會導致時間太長而無法識別所需數據或返回數據。所以不妨在查詢中排查以下問題。
1. 選擇過多冗餘數據
編寫查詢語句來返回適當的數據是遠遠不夠的，很可能你的查詢語句會返回太多列，從而導致選擇行和檢索數據變得異常緩慢。所以，最好是列出所需的列，而不是直接用 SELECT*。當需要在特定欄位中查詢時，該計劃可能會確定一個覆蓋索引從而加快結果返回。覆蓋索引通常會包含查詢中使用的所有欄位。這意味著資料庫可以僅從索引中產生結果，而不需要通過底層表來構建。
另外，列出結果中所需的列不僅可以減少傳輸的數據，還能進一步提高性能。
2. 表之間的低效聯接
聯接會導致資料庫將多組數據帶到內存中進行比較，這會產生多個資料庫讀取和大量 CPU。根據表的索引，聯接還可能需要掃描兩個表的所有行。如果寫不好兩個大型表之間的聯接，就需要對每個表進行完整掃描，這樣的計算量將會非常大。其他會拖慢聯接的因素包括聯接列之間存在不同的數據類型、需要轉換或加入包含 LIKE 的條件，這樣就會阻止使用索引。另外，還需注意避免使用全外聯接；在恰當的時候使用內部聯接只返回所需數據。
3. 索引過多或過少
如果查詢優化沒有可用的索引時，資料庫會重新掃描表來產生查詢結果，這個過程會生成大量的磁碟輸入/輸出（I/O）。適當的索引可以減少排序結果的需要。雖然非唯一值的索引在生成結果時，不能像唯一索引那樣方便。如果鍵越大，索引也會變大，並通過它們創建更多的磁碟 I/O。大多數索引是為了提高數據檢索的性能，但也需要明白索引本身也會影響數據的插入和更新，因為所有相關聯的指標都必須更新。
4. 太多的SQL導致爭用解析資源
任何 SQL 查詢在執行之前都必須被解析，在生成執行計劃之前需要對語法和許可權進行檢查。由於解析非常耗時，資料庫會保存已解析的 SQL 來重復利用，從而減少解析的耗時。因為 WHERE 語句不同，所以使用文本值的查詢語句不能被共享。這將導致每個查詢都會被解析並添加到共享池中，由於池的空間有限，一些已保存的查詢會被舍棄。當這些查詢再次出現時，則需要重新解析。
用戶和查詢沖突
資料庫支持多用戶，但多用戶活動也可能造成沖突。
1. 由慢查詢導致的頁/行鎖定
為了確保查詢產生精確的結果，資料庫必須鎖定表以防止在運行讀取查詢時再發生其他的插入和更新行為。如果報告或查詢相當緩慢，需要修改值的用戶可能需要等待至更新完成。鎖提示能幫助資料庫使用最小破壞性的鎖。從事務資料庫中分離報表也是一種可靠的解決方法。
2. 事務鎖和死鎖
當兩個事務被阻塞時會出現死鎖，因為每一個都需要使用被另一個佔用的資源。當出現一個普通鎖時，事務會被阻塞直到資源被釋放。但卻沒有解決死鎖的方案。資料庫會監控死鎖並選擇終止其中一個事務，釋放資源並允許該事務繼續進行，而另一個事務則回滾。
3. 批處理操作造成資源爭奪
批處理過程通常會執行批量操作，如大量的數據載入或生成復雜的分析報告。這些操作是資源密集型的，但可能影響在線用戶的訪問應用的性能。針對此問題最好的解決辦法是確保批處理在系統使用率較低時運行，比如晚上，或用單獨的資料庫進行事務處理和分析報告。
容量
並不是所有的資料庫性能問題都是資料庫問題。有些問題也是硬體不合適造成的。
1. CPU 不足或 CPU 速度太慢
更多 CPU 可以分擔伺服器負載，進一步提高性能。資料庫的性能不僅是資料庫的原因，還受到伺服器上運行其他進程的影響。因此，對資料庫負載及使用進行審查也是必不可少的。由於 CPU 的利用率時時在變，在低使用率、平均使用率和峰值使用率的時間段分別檢查該指標可以更好地評估增加額外的 CPU 資源是否有益。
2. IOPS 不足的慢磁碟
磁碟性能通常以每秒輸入/輸出操作（IOPS）來計。結合 I/O 大小，該指標可以衡量每秒的磁碟吞吐量是多少兆。同時，吞吐量也受磁碟的延遲影響，比如需要多久才能完成請求，這些指標主要是針對磁碟存儲技術而言。傳統的硬碟驅動器（HDD）有一個旋轉磁碟，通常比固態硬碟（SSD）或快閃記憶體更慢。直到近期，SSD 雖然仍比 HDD 貴，但成本已經降了下來，所以在市場上也更具競爭力。
3. 全部或錯誤配置的磁碟
眾所周知，資料庫會被大量磁碟訪問，所以不正確配置的磁碟可能帶來嚴重的性能缺陷。磁碟應該適當分區，將系統數據目錄和用戶數據日誌分開。高度活躍的表應該區分以避免爭用，通過在不同磁碟上存放資料庫和索引增加並行放置，但不要將操作系統和資料庫交換空間放置在同一磁碟上。
4. 內存不足
有限或不恰當的物理內存分配會影響資料庫性能。通常我們認為可用的內存更多，性能就越好。監控分頁和交換,在多個非繁忙磁碟中建立多頁面空間，進一步確保分頁空間分配足夠滿足資料庫要求；每個資料庫供應商也可以在這個問題上提供指導。
5. 網速慢
網路速度會影響到如何快速檢索數據並返回給終端用戶或調用過程。使用寬頻連接到遠程資料庫。在某些情況下，選擇 TCP/IP 協議而不是命名管道可顯著提高資料庫性能。
配置
每個資料庫都需設置大量的配置項。通常情況下，默認值可能不足以滿足資料庫所需的性能。所以，檢查所有的參數設置，包括以下問題。
1. 緩沖區緩存太小
通過將數據存儲在內核內存，緩沖區緩存可以進一步提高性能同時減少磁碟 I/O。當緩存太小時，緩存中的數據會更頻繁地刷新。如果它再次被請求，就必須從磁碟重讀。除了磁碟讀取緩慢之外，還給 I/O 設備增添了負擔從而成為瓶頸。除了給緩沖區緩存分配足夠的空間，調優 SQL 查詢可以幫助其更有效地利用緩沖區緩存。
2. 沒有查詢緩存
查詢緩存會存儲資料庫查詢和結果集。當執行相同的查詢時，數據會在緩存中被迅速檢索，而不需要再次執行查詢。數據會更新失效結果，所以查詢緩存是唯一有效的靜態數據。但在某些情況下，查詢緩存卻可能成為性能瓶頸。比如當鎖定為更新時，巨大的緩存可能導致爭用沖突。
3. 磁碟上臨時表創建導致的 I/O 爭用
在執行特定的查詢操作時，資料庫需要創建臨時表，如執行一個 GROUP BY 子句。如果可能，在內存中創建臨時表。但是，在某些情況下，在內存中創建臨時表並不可行，比如當數據包含 BLOB 或 TEXT 對象時。在這些情況下，會在磁碟上創建臨時表。大量的磁碟 I / O 都需要創建臨時表、填充記錄、從表中選擇所需數據並在查詢完成後舍棄。為了避免影響性能，臨時資料庫應該從主資料庫中分離出來。重寫查詢還可以通過創建派生表來減少對臨時表的需求。使用派生表直接從另一個 SELECT 語句的結果中選擇，允許將數據加到內存中而不是當前磁碟上。
NoSQL 資料庫
NoSQL 的優勢在於它處理大數據的能力非常迅速。但是在實際使用中，也應該綜合參考 NoSQL 的缺點，從而決定是否適合你的用例場景。這就是為什麼NoSQL通常被理解為 「不僅僅是 SQL」，說明了 NoSQL 並不總是正確的解決方案，也沒必要完全取代 SQL，以下分別列舉出五大主要原因。
1. 挑剔事務
難以保持 NoSQL 條目的一致性。當訪問結構化數據時，它並不能完全確保同一時間對不同表的更改都生效。如果某個過程發生崩潰，表可能會不一致。一致事務的典型代表是復式記賬法。相應的信貸必須平衡每個借方，反之亦然。如果雙方數據不一致則不能輸入。NoSQL 則可能無法保證「收支平衡」。
2. 復雜資料庫
NoSQL 的支持者往往以高效代碼、簡單性和 NoSQL 的速度為傲。當資料庫任務很簡單時，所有這些因素都是優勢。但當資料庫變得復雜，NoSQL 會開始分解。此時，SQL 則比 NoSQL 更好地處理復雜需求，因為 SQL 已經成熟，有符合行業標準的介面。而每個 NoSQL 設置都有一個唯一的介面。
3. 一致聯接
當執行 SQL 的聯接時，由於系統必須從不同的表中提取數據進行鍵對齊，所以有一個巨大的開銷。而 NoSQL 似乎是一個空想，因為缺乏聯接功能。所有的數據都在同一個表的一個地方。當檢索數據時，它會同時提取所有的鍵值對。問題在於這會創建同一數據的多個副本。這些副本也必須更新，而這種情況下，NoSQL 沒有功能來確保更新。
4. Schema設計的靈活性
由於 NoSQL 不需要 schema，所以在某些情況下也是獨一無二的。在以前的資料庫模型中，程序員必須考慮所有需要的列能夠擴展，能夠適應每行的數據條目。在 NoSQL 下，條目可以有多種字元串或者完全沒有。這種靈活性允許程序員迅速增加數據。但是，也可能存在問題，比如當有多個團體在同一項目上工作時，或者新的開發團隊接手一個項目時。開發人員能夠自由地修改資料庫，也可能會不斷實現各種各樣的密鑰對。
5. 資源密集型
NoSQL 資料庫通常比關系資料庫更加資源密集。他們需要更多的 CPU 儲備和 RAM 分配。出於這個原因，大多數共享主機公司都不提供 NoSQL。你必須注冊一個 VPS 或運行自己的專用伺服器。另一方面，SQL 主要是在伺服器上運行。初期的工作都很順利，但隨著資料庫需求的增加，硬體必須擴大。單個大型伺服器比多個小型伺服器昂貴得多，價格呈指數增長。所以在這種企業計算場景下，使用 NoSQL 更為劃算，例如那些由谷歌和 Facebook 使用的伺服器。
C. 怎樣對Access資料庫進行性能分析
1
首先打開Access資料庫，單擊「資料庫工具」菜單中的「分析性能」項，彈出「性能分析器」窗口。
2
在彈出的「性能分析器」窗口中，默認為「表」選擇框。通常選擇對全部表進行性能分析，點擊「全選」，所有表前面的復選框被勾選中，點「確定」開始分析。
3
如果分析後，彈出提示框顯示「性能分析沒有改進所選對象的建議」，說明沒有必要對當前資料庫性能進行優化，無須進行後續步驟；
否則，會彈出分析結果窗口：列表中每一項前面都有一個符號，每個符號都代表一個含義，在這個對話框中都有介紹。如果在列表框中有「推薦」和「建議」，我們
就點擊「全選」按鈕，這時在列表框中的全部項都被選中。然後點擊「優化」按鈕，等一會兒，會發現原來的「推薦」和「建議」項都變成了「更正」項，說明已經
將這些問題都解決了。帶「燈泡」符號的「意見」項沒有變化，當選中其中一個「意見」選項時，在「分析注釋」中詳細列出Access為解決這個問題所出的意
見。
4
另外，「資料庫工具」菜單中的「資料庫文檔管理器」選項，可以列印出所建資料庫各對象的全部信息。點擊「資料庫文檔管理器「，在彈出的對話框中點擊"全
選"，所有表前面的復選框被勾選中。在這個對話框上有一個「選項」按鈕，這個按鈕是用來確定列印表的定義，讓我們單擊該按鈕，會彈出一個對話框。
5
在這個對話框中包含「表含義」、「欄位包含」、「索引包含」這三個含義組，選擇組中不同的選項，會改變列印表顯示的信息內容。當我們完成這些工作，單擊「確定」按鈕。
6
在彈出的列印表中，列出了資料庫表各類屬性信息，有經驗的Access使用者就可以根據這些信息資料分析出所建立的資料庫有哪些問題了。
D. 如何分析sql server 2012資料庫性能
sql server性能分析--查看錶數據頁數
返回表名、索引名和行數
SELECT object_name(i.object_id) as objectName, i.[name] as indexName, sum(p.rows) as rowCnt
FROM sys.indexes i
INNER JOIN sys.partitions p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
WHERE i.object_id = object_id('dbo.Meeting')
AND i.index_id <= 1
GROUP BY i.object_id, i.index_id, i.[name]
返回表的總頁數、使用頁數、數據頁數
SELECT object_name(i.object_id) as objectName, i.[name] as indexName,
sum(a.total_pages) as totalPages, sum(a.used_pages) as usedPages, sum(a.data_pages) as dataPages,
(sum(a.total_pages) * 8) / 1024 as totalSpaceMB, (sum(a.used_pages) * 8) / 1024 as usedSpaceMB,
(sum(a.data_pages) * 8) / 1024 as dataSpaceMB
FROM sys.indexes i
INNER JOIN sys.partitions p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a
ON p.partition_id = a.container_id
WHERE i.object_id = object_id('dbo.Meeting')
AND i.index_id <= 1
GROUP BY i.object_id, i.index_id, i.[name]
按頁類型分類統計
SELECT case when grouping(i.object_id) = 1 then '--- TOTAL ---' else object_name(i.object_id) end as objectName,
case when grouping(i.[name]) = 1 then '--- TOTAL ---' else i.[name] end as indexName,
case when grouping(a.type_desc) = 1 then '--- TOTAL ---' else a.type_desc end as pageType,
sum(a.total_pages) as totalPages, sum(a.used_pages) as usedPages, sum(a.data_pages) as dataPages,
(sum(a.total_pages)
* 8) / 1024 as totalSpaceMB, (sum(a.used_pages) * 8) / 1024 as
usedSpaceMB, (sum(a.data_pages) * 8) / 1024 as dataSpaceMB
FROM sys.indexes i
INNER JOIN sys.partitions p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a
ON p.partition_id = a.container_id
WHERE i.object_id = object_id('dbo.Meeting')
AND i.index_id <= 1
GROUP BY i.object_id, i.[name], a.type_desc with rollup
E. 怎樣改進資料庫的查詢性能
1、使你的資料庫結構規范化，但是不要求一定達到第三範式，為了顯示和列印目的可以有數據冗餘2、評估你的系統中對性能影響的關鍵處，減少被頻繁訪問的核心表的數量，並在這些核心
表上重點優化索引，表結構（盡量緊湊）。典型的核心表是代碼表。
3、對於統計類應用，如果可能應寫成觸發器和存儲過程，這樣就有可能把一個消耗大量時
間的統計運算分布到每INSERT，DELETE，或者UPDATE來處理，從而極大提高查詢類操作的速度。
查詢選擇群居索引最有效。其他索引也要針對業務進行選擇。由於維護索引也要消耗系
統資源和時間，所以過多的索引對性能是損害甚至是毫無效果的。
5、如果可能，可以利用大資料庫對SQL的一些特殊規定來進一步優化，比如查詢暗示。
6、適當選擇硬體，綜合考慮CPU，內存，I/O系統的性能，以當前的CPU，內存配置來看，
很多資料庫系統的瓶頸出在I/O系統上。所以如果有可能，最好使用RAID。
當然如果你有足夠的財力，可以買更好的伺服器，或者搞伺服器集群就更利害啦。
7、可能的話，盡量使用存儲過程，因為存儲過程的執行計劃可以重復使用，而且不需要
象普通由CLIENT提交的SQL那樣進行處理和編譯。
8、檢查你的應用程序設計，如果有可能，盡量減少查詢次數和在網路上往返的數據。為了
獲取少量欄位而寫SELECT * 對性能的損害也比較利害。
9、在應用程序中協調並發和一致性之間的矛盾。並不是所有業務都需要放在事務中。大量
業務是允許臟讀的，在不關鍵事務中使用臟讀，或者讀提交，可以大大降低DEADLOCK和
進程之間彼此等待的機會，從而把由於互相鎖定資源引起的等待降低到最小。
不要在事務執行中進行大量計算或者與用戶交互的操作，因為事務的執行在要求上是
不允許被打斷的原子操作（回滾是失敗的），所以事務應該多而短小。長事務會鎖住
很多資源比較長的時間，因此也比較容易導致其他進程對資源的等待和死鎖的機會。
10、評估你開發系統的關鍵業務，在很多資料庫系統對性能的要求是彼此矛盾的，比如OLTP
應用和DSS是不同的。DSS傾向於使用各種索引加快檢索速度，而大量的索引對OLTP則是負擔。
11、不要在應用程序中寫怪異的SQL 查詢，比如 WHERE money!40000，這樣的語句，這種
SQL查詢，資料庫的SQL優化器是無法進行優化的。
12、定期維護和管理你的資料庫系統，壓縮掉那些垃圾空間，很多資料庫系統執行類似
刪除，事務等操作的時候，並不回收無用的物理空間。所以，制定一份合理的資料庫
維護計劃，不要等日誌文件或者LOG文件越長越大的時候才去整理資料庫。
還有很多很多要注意的東西，。。。。。。
F. 哪些因素影響了資料庫性能
網路寬頻，磁碟IO，查詢速度都會影響到資料庫的性能。
具體問題具體分析，舉例來說明為什麼磁碟IO成瓶頸資料庫的性能急速下降了。
為什麼當磁碟IO成瓶頸之後, 資料庫的性能不是達到飽和的平衡狀態，而是急劇下降。為什麼資料庫的性能有非常明顯的分界點，原因是什麼？
相信大部分做資料庫運維的朋友，都遇到這種情況。 資料庫在前一天性能表現的相當穩定，資料庫的響應時間也很正常，但就在今天，在業務人員反饋業務流量沒有任何上升的情況下，資料庫的變得不穩定了，有時候一個最簡單的insert操作， 需要幾十秒，但99%的insert卻又可以在幾毫秒完成，這又是為什麼了？
dba此時心中有無限的疑惑，到底是什麼原因呢? 磁碟IO性能變差了？還是業務運維人員反饋的流量壓根就不對？ 還是資料庫內部出問題？昨天不是還好好的嗎？
當資料庫出現響應時間不穩定的時候，我們在操作系統上會看到磁碟的利用率會比較高，如果觀察仔細一點，還可以看到，存在一些讀的IO. 資料庫伺服器如果存在大量的寫IO,性能一般都是正常跟穩定的，但只要存在少量的讀IO,則性能開始出現抖動，存在大量的讀IO時（排除配備非常高速磁碟的機器），對於在線交易的資料庫系統來說，大概性能就雪崩了。為什麼操作系統上看到的磁碟讀IO跟寫IO所帶來的性能差距這么大呢？
如果親之前沒有注意到上述的現象，親對上述的結論也是懷疑。但請看下面的分解。
在寫這個文章之前，作者閱讀了大量跟的IO相關的代碼，如非同步IO線程的相關的，innodb_buffer池相關的，以及跟讀數據塊最相關的核心函數buf_page_get_gen函數以及其調用的相關子函數。為了將文章寫得通俗點，看起來不那麼累，因此不再一行一行的將代碼解析寫出來。
咱們先來提問題。buf_page_get_gen函數的作用是從Buffer bool裡面讀數據頁，可能存在以下幾種情況。
提問. 數據頁不在buffer bool 裡面該怎麼辦？
回答：去讀文件，將文件中的數據頁載入到buffer pool裡面。下面是函數buffer_read_page的函數，作用是將物理數據頁載入到buffer pool, 圖片中顯示
buffer_read_page函數棧的頂層是pread64(),調用了操作系統的讀函數。
通過解析buf_wait_for_read函數的下層函數，我們知道其實通過首先自旋加鎖pin的方式，超過設定的自旋次數之後，進入等待，等待IO完成被喚醒。這樣節省不停自旋pin時消耗的cpu,但需要付出被喚起時的開銷。
再繼續擴展問題： 如果會話線程A 經過物理IO將數據頁1001讀入buffer之後，他需要修改這個頁，而在會話線程A之後的其他的同樣需要訪問數據頁1001的會話線程，即使在數據頁1001被入讀buffer pool之後，將仍然處於等待中。因為在數據頁上讀取或者更新的時候，同樣需要上鎖，這樣才能保證數據頁並發讀取/更新的一致性。
由此可見，當一個高並發的系統，出現了熱點數據頁需要從磁碟上載入到buffer pool中時，造成的延遲，是難以想像的。因此排在等待熱點頁隊列最後的會話線程最後才得到需要的頁，響應時間也就越長，這就是造成了一個簡單的sql需要執行幾十秒的原因。
再回頭來看上面的問題，mysql資料庫出現性能下降時，可以看到操作系統有讀IO。 原因是，在資料庫對數據頁的更改，是在內存中的，然後通過檢查點線程進行非同步寫盤，這個非同步的寫操作是不堵塞執行sql的會話線程的。所以，即使看到操作系統上有大量的寫IO，資料庫的性能也是很平穩的。但當用戶線程需要查找的數據頁不在buffer pool中時，則會從磁碟上讀取，在一個熱點數據頁不是非常多的情況下，我們設置足夠大的innodb_buffer_pool的size, 基本可以緩存所有的數據頁，因此一般都不會出現缺頁的情況，也就是在操作系統上基本看不到讀的IO。 當出現讀的IO時，原因時在執行buf_read_page_low函數，從磁碟上讀取數據頁到buffer pool, 則資料庫的性能則開始下降，當出現大量的讀IO，資料庫的性能會非常差。
G. 如何處理查找，處理資料庫的性能瓶頸
具體問題具體分析，舉例來說明為什麼磁碟IO成瓶頸資料庫的性能急速下降了。
為什麼當磁碟IO成瓶頸之後, 資料庫的性能不是達到飽和的平衡狀態，而是急劇下降。為什麼資料庫的性能有非常明顯的分界點，原因是什麼？
相信大部分做資料庫運維的朋友，都遇到這種情況。 資料庫在前一天性能表現的相當穩定，資料庫的響應時間也很正常，但就在今天，在業務人員反饋業務流量沒有任何上升的情況下，資料庫的變得不穩定了，有時候一個最簡單的insert操作， 需要幾十秒，但99%的insert卻又可以在幾毫秒完成，這又是為什麼了？
dba此時心中有無限的疑惑，到底是什麼原因呢? 磁碟IO性能變差了？還是業務運維人員反饋的流量壓根就不對？ 還是資料庫內部出問題？昨天不是還好好的嗎？
當資料庫出現響應時間不穩定的時候，我們在操作系統上會看到磁碟的利用率會比較高，如果觀察仔細一點，還可以看到，存在一些讀的IO. 資料庫伺服器如果存在大量的寫IO,性能一般都是正常跟穩定的，但只要存在少量的讀IO,則性能開始出現抖動，存在大量的讀IO時（排除配備非常高速磁碟的機器），對於在線交易的資料庫系統來說，大概性能就雪崩了。為什麼操作系統上看到的磁碟讀IO跟寫IO所帶來的性能差距這么大呢？
如果親之前沒有注意到上述的現象，親對上述的結論也是懷疑。但請看下面的分解。
在寫這個文章之前，作者閱讀了大量跟的IO相關的代碼，如非同步IO線程的相關的，innodb_buffer池相關的，以及跟讀數據塊最相關的核心函數buf_page_get_gen函數以及其調用的相關子函數。為了將文章寫得通俗點，看起來不那麼累，因此不再一行一行的將代碼解析寫出來。
咱們先來提問題。buf_page_get_gen函數的作用是從Buffer bool裡面讀數據頁，可能存在以下幾種情況。
提問. 數據頁不在buffer bool 裡面該怎麼辦？
回答：去讀文件，將文件中的數據頁載入到buffer pool裡面。下面是函數buffer_read_page的函數，作用是將物理數據頁載入到buffer pool, 圖片中顯示
buffer_read_page函數棧的頂層是pread64(),調用了操作系統的讀函數。
通過解析buf_wait_for_read函數的下層函數，我們知道其實通過首先自旋加鎖pin的方式，超過設定的自旋次數之後，進入等待，等待IO完成被喚醒。這樣節省不停自旋pin時消耗的cpu,但需要付出被喚起時的開銷。
再繼續擴展問題： 如果會話線程A 經過物理IO將數據頁1001讀入buffer之後，他需要修改這個頁，而在會話線程A之後的其他的同樣需要訪問數據頁1001的會話線程，即使在數據頁1001被入讀buffer pool之後，將仍然處於等待中。因為在數據頁上讀取或者更新的時候，同樣需要上鎖，這樣才能保證數據頁並發讀取/更新的一致性。
由此可見，當一個高並發的系統，出現了熱點數據頁需要從磁碟上載入到buffer pool中時，造成的延遲，是難以想像的。因此排在等待熱點頁隊列最後的會話線程最後才得到需要的頁，響應時間也就越長，這就是造成了一個簡單的sql需要執行幾十秒的原因。
再回頭來看上面的問題，mysql資料庫出現性能下降時，可以看到操作系統有讀IO。 原因是，在資料庫對數據頁的更改，是在內存中的，然後通過檢查點線程進行非同步寫盤，這個非同步的寫操作是不堵塞執行sql的會話線程的。所以，即使看到操作系統上有大量的寫IO，資料庫的性能也是很平穩的。但當用戶線程需要查找的數據頁不在buffer pool中時，則會從磁碟上讀取，在一個熱點數據頁不是非常多的情況下，我們設置足夠大的innodb_buffer_pool的size, 基本可以緩存所有的數據頁，因此一般都不會出現缺頁的情況，也就是在操作系統上基本看不到讀的IO。 當出現讀的IO時，原因時在執行buf_read_page_low函數，從磁碟上讀取數據頁到buffer pool, 則資料庫的性能則開始下降，當出現大量的讀IO，資料庫的性能會非常差。
H. MYSQL資料庫伺服器性能分析的方法命令有哪些
?Show
status
?一些值得監控的變數值：
?Bytes_received和Bytes_sent
?和伺服器之間來往的流量。
?Com_*伺服器正在執行的命令。
?Created_*在查詢執行期限間創建的臨時表和文件。
?Handler_*存儲引擎操作。
?Select_*不同類型的聯接執行計劃。
?Sort_*幾種排序信息。
?Show
session status like 『Select』;
?Show profiles
?SET profiling=1;
?Show
profiles\G
?Show profile;