具體來說，本文包括以下內容:
事務事務可以觀察真實使用者的行為：能夠在應用互動時捕獲實時效能。眾所周知，測量事務的效能包括獲取整個事務的響應時間和組成事務的各個部分的響應時間。通常我們可以用這些響應時間與滿足事務需求的基線對比，來確定當前事務是否處於正常狀態。
如果你只想衡量應用的某個方面，那麼可以評估事務的行為。所以，儘管容器指標能夠提供更豐富的資訊，並且幫助你決定何時對當前環境進行自動測量，但你的事務就足以確定應用效能。無需向應用程式伺服器獲取 cpu 的使用情況，你更應該關心使用者是否完成了事務，以及該事務是否得到了優化。
補充乙個小知識點，事務是由入口點決定的，通過該入口點可以啟動事務與應用進行互動。
一旦定義了事務，會在整個應用生態系統中對其效能進行測量，並將每個事務與基線進行比對。例如，我們可能會決定當事務的響應時間與基線相比，一旦慢於平均響應時間的兩個標準差是否就應該判定為異常，如圖1所示。
圖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 使用的伺服器。
總結
軟體效能常用三大指標
筆記 茹炳晟老師 第28課 帶你一起解讀不同視角的軟體效能與效能指標 衡量軟體效能三個最常用的指標 併發使用者數 響應時間 系統吞吐量 併發使用者數 包含業務層面和後端伺服器層面的兩層含義 業務層面的併發使用者數 指實際使用系統的使用者總數。要結合使用者行為模型，才能得到系統實際承載的壓力。後端伺服...
五 效能監視（6）資料庫審核
一 sql server審核 sql server 審核 物件收集單個伺服器例項或資料庫級操作和操作組以進行監視。這種審核處於 sql server 例項級別。每個 sql server 例項可以具有多個審核。二 建立審核 1.新建審核 2.啟用審核 三 建立審核規範 1.伺服器審核規範 您可以為每...
五 效能監視（6）資料庫審核
一 sql server審核 sql server 審核 物件收集單個伺服器例項或資料庫級操作和操作組以進行監視。這種審核處於 sql server 例項級別。每個 sql server 例項可以具有多個審核。二 建立審核 1.新建審核 2.啟用審核 三 建立審核規範 1.伺服器審核規範 您可以為每...