目錄

一、性能測試的指標

1、并發量

2、響應時間

3、錯誤率

4、吞吐量

5、資源使用率

二、壓測全流程

三、其他注意點

1、并發和吞吐量的關系

2、并發和線程的關系

四、調優及分布式集群壓測（待仔細學習）

1.線程數量超過單機承載能力時的解決方案

2. 如何搭建分布式集群

3. 實施集群壓測及監控

4. 處理集群中單臺施壓機報錯的情況

5. 長時間壓測（10小時）的注意事項

6. 處理混合場景：用戶思考時間及多個服務同時壓測

7. 開發壓測監控大屏

8. 匯總多個測試報告

9. 監控服務器的 CPU、內存、磁盤

10. 監控 Java 程序、Nginx、MySQL 數據庫及 JVM 指標

11. 性能分析及測試結論

12. 區分壓測問題與程序問題

13. 內存溢出與性能問題標注

14. 與 BI 項目的關聯

四、調優（待仔細學習）

1. 緩存調優

2. 集群調優

3. MQ（消息隊列）中間件調優

4. 分布式微服務全鏈路壓測

五、連接數據庫進行數據庫壓測（待仔細學習）

1、步驟

2、性能測試指標

3.性能瓶頸發現方法

---

一、性能測試的指標

1、并發量

• 定義：描述一個系統所面臨的壓力，服務器收到多少請求（多少/秒）

• 用的人多，服務器收到請求多，并發量就高。

• 用來描述場景

2、響應時間

• 定義：請求開始到獲取結果的時長（毫秒 1000ms=1s）

• 直觀反映了用戶體驗

• 統計方式：平均響應時間 （按響應時間分布 90% 95% 99%）

• 平均響應時間：是對所有請求的響應時間取平均值，代表整體性能的一個平均水平。

  百分位數（90%、95%、99%）：

  • 90%百分位數：表示90%的請求響應時間都小于這個值，也就是說有10%的請求響應時間是比這個值更長的。

  • 95%百分位數：表示95%的請求響應時間都小于這個值，也就是說有5%的請求響應時間比這個值更長。

  • 99%百分位數：表示99%的請求響應時間都小于這個值，也就是說有1%的請求響應時間比這個值更長。

3、錯誤率

• 定義：高并發海量請求場景，系統出錯誤的比例。

  錯誤率=出錯請求數量/整體請求數量

4、吞吐量

• 定義：服務器1秒內處理了多少請求

• 吞吐量和并發量的區別：并發量是服務器收到請求，吞吐量是服務器處理請求

• 細分概念

  • QPS (Queries Per Second)：QPS 指的是每秒能夠處理的查詢數量，通常用于描述Web服務**或數據庫在一定時間內處理請求的能力。

  • TPS (Transactions Per Second)：TPS 指的是每秒能夠處理的事務數量，這里的事務通常指的是一系列邏輯上的操作，這些操作可能包含多個查詢、插入、更新等。一個事務需要滿足ACID屬性（原子性、一致性、隔離性、持久性）。

5、資源使用率

• 定義：程序在測壓中，服務器資源的占用情況

• 程序運行代碼需要占用服務器資源，CPU/內存、磁盤、網絡…

這個是網絡的指標 不是性能測試的指標：

1、帶寬

• 定義：網絡吞吐量，系統或網絡在單位時間內能夠傳輸的數據量

• 單位：比特每秒（bps）_為單位，常見的單位有_10mb/s（兆比特每秒）

2、時延

二、壓測全流程

(壓力測試 及 壓力測試前的接口測試 詳細請看另一個文章)

1. 壓測場景分析

2. 在做性能測試之前，先做接口測試

3. 收集性能指標

4. 分析性能數據

5. 梳理性能報告

三、其他注意點

1、并發和吞吐量的關系

• 并發請求：發送給服務器的請求數量

• 吞吐量：服務器每秒能處理的請求數量

(1) 先有并發，再有吞吐量（現有請求再有處理）。

(2) 并發量**>**吞吐量

2、并發和線程的關系

（1）并發量 不等于 線程數

• 有時候 一個線程 一秒鐘 能產生多次請求

• 有時候 一個線程 一秒鐘 不能完成一次請求

（2）線程數量=并發量*最大響應時間（秒）

四、調優及分布式集群壓測（待仔細學習）

（性能測試需要剝奪業務層的干擾，有時候也需要對中間件直接壓測，查看其性能）

1.線程數量超過單機承載能力時的解決方案

當單臺運行 JMeter 的機器無法再增加線程數量時，可以采用 分布式集群 的方式，通過多臺施壓機（JMeter Server）共同承擔壓測任務。

2. 如何搭建分布式集群

（1）分布式集群搭建步驟如下：

1. 準備多臺施壓機： 確保所有施壓機和控制機（JMeter Controller）在同一網絡中，能夠相互通信。

2. 配置 JMeter：

   • 在所有施壓機上安裝與控制機相同版本的 JMeter。

   • 修改

     jmeter.properties

     文件，確保

     remote_hosts

     配置項包含所有施壓機的 IP 地址。例如：

     remote_hosts=192.168.1.2,192.168.1.3,192.168.1.4

3. 啟動 JMeter Server：

   • 在每臺施壓機上，通過命令行啟動 JMeter Server：

     jmeter-server

4. 啟動測試：

   • 在控制機上打開測試計劃，選擇 Run > Remote Start All 或選擇特定的施壓機啟動測試。

3. 實施集群壓測及監控

集群實施步驟：

• 測試計劃設計： 確保測試計劃是分布式友好的，例如避免使用非線程安全的元素。

• 同步資源： 所有施壓機應使用相同的測試腳本和資源文件。

• 啟動測試： 通過控制機統一啟動所有施壓機的測試。

監控壓測情況：

• 實時監控工具： 使用 JMeter 自帶的監聽器或更高級的工具（如 Grafana 與 InfluxDB）進行實時監控。

• 集中監控平臺： 可以開發一個監控大屏，將各施壓機的性能指標匯總展示。

4. 處理集群中單臺施壓機報錯的情況

應對策略：

1. 自動化監控與報警： 實時監控每臺施壓機的狀態，若發現某臺施壓機報錯或宕機，立即觸發報警。

2. 自動恢復機制： 配置自動重啟腳本，確保施壓機故障后能自動重啟 JMeter Server。

3. 測試任務再分配： 如果施壓機長時間故障，可以手動或自動將其負載轉移到其他施壓機。

5. 長時間壓測（10小時）的注意事項

關鍵點：

• 資源穩定性： 確保施壓機和被測系統在長時間壓測下資源不泄漏（如內存、文件句柄）。

• 斷點續測： 設計測試計劃時考慮斷點續測機制，以防測試中斷后能夠恢復。

• 日志管理： 合理配置日志級別，避免長時間壓測產生過多日志，影響系統性能。

• 定期檢查： 在壓測過程中定期檢查施壓機和被測系統的性能指標，及時發現潛在問題。

6. 處理混合場景：用戶思考時間及多個服務同時壓測

實現方法：

• 用戶思考時間： 在 JMeter 中使用 Timers（定時器） 元素，如 Gaussian Random Timer 或 Constant Timer，模擬用戶思考時間。

• 多個服務壓測： 在測試計劃中設計多線程組，每個線程組針對不同的服務進行壓測，或在同一線程組中配置不同的請求，確保多個服務同時承受壓力。

• 邏輯控制： 使用 Controllers（控制器） 元素，如 Transaction Controller 或 Module Controller，管理復雜的測試邏輯。

7. 開發壓測監控大屏

監控大屏開發步驟：

1. 數據收集：

   • 使用 JMeter Backend Listener 將性能數據發送到時序數據庫，如 InfluxDB。

   • 配置監控工具（如 Grafana）連接 InfluxDB 以實時獲取數據。

2. 展示內容：

   • 施壓機性能指標： CPU、內存、磁盤使用率。

   • 被測服務指標： 響應時間、吞吐量、錯誤率。

   • 應用層指標： JVM 內存使用、垃圾回收情況、數據庫性能指標（如 MySQL 的連接數、查詢性能）。

3. 可視化設計：

   • 使用 Grafana 創建儀表板，將各類指標以圖表、儀表盤等形式展示。

   • 設置閾值和警報規則，實時標注異常情況。

8. 匯總多個測試報告

實現方法：

• 集中化報告生成：

  • 使用 JMeter Plugins 中的 Aggregate Report 或 Summary Report 進行數據匯總。

  • 將各施壓機的測試結果通過腳本或工具（如 JMeter Dashboard）匯總到統一的報告中。

• 自動化腳本：

  • 編寫腳本在測試結束后自動收集各施壓機的結果文件（如 JTL 文件），并進行匯總處理。

9. 監控服務器的 CPU、內存、磁盤

監控工具選擇：

• Prometheus + Grafana： 通過 Node Exporter 采集服務器的 CPU、內存、磁盤等指標，并在 Grafana 中展示。

• 其他監控工具： 如 Zabbix、Nagios 等，也可以實現類似的監控功能。

實施步驟：

1. 在每臺服務器上安裝監控代理（如 Node Exporter）。

2. 配置 Prometheus 抓取各服務器的指標。

3. 在 Grafana 中創建儀表板，實時展示各項資源使用情況。

10. 監控 Java 程序、Nginx、MySQL 數據庫及 JVM 指標

Java 程序（JVM）監控：

• JMX（Java Management Extensions）：

  • 啟用 JVM 的 JMX 功能，允許遠程監控。

• 監控工具：

  • 使用 Prometheus JMX Exporter 將 JVM 指標導出到 Prometheus。

• 關鍵指標：

  • 垃圾回收（GC）： GC 次數、GC 時間。

  • 內存使用： 新生代（Young Generation）、老年代（Old Generation）、堆外內存。

  • 線程數： 活動線程數。

Nginx 監控：

• 狀態模塊：

  • 啟用 Nginx 的 Stub Status Module，獲取當前連接數、請求數等信息。

• 監控工具：

  • 使用 Prometheus Nginx Exporter 獲取并導出 Nginx 指標。

• 關鍵指標：

  • 活動連接數、總請求數、每秒請求數、響應時間。

MySQL 數據庫監控：

• 性能指標：

  • 連接數： 當前活動連接數、最大連接數。

  • 查詢性能： 每秒查詢數、慢查詢數。

  • 資源使用： CPU、內存、磁盤 I/O。

• 監控工具：

  • 使用 Prometheus MySQL Exporter 或 Percona Monitoring and Management (PMM) 進行監控。

實施步驟：

1. 在 Java 應用、Nginx、MySQL 服務器上安裝相應的監控 Exporter。

2. 配置 Prometheus 抓取這些 Exporter 的指標。

3. 在 Grafana 中創建綜合儀表板，展示所有關鍵指標。

11. 性能分析及測試結論

性能分析步驟：

1. 數據匯總： 收集所有施壓機和被測系統的性能數據。

2. 指標對比： 將實際指標與預設的性能指標（如響應時間、吞吐量）進行對比。

3. 瓶頸識別： 通過分析 CPU、內存、磁盤、網絡等資源的使用情況，識別性能瓶頸所在。

4. 異常檢測： 標注在壓測過程中出現的任何異常情況，如響應時間飆升、錯誤率增加、資源耗盡等。

5. 結論判定：

   • 測試通過： 所有關鍵指標在預期范圍內，系統穩定。

   • 測試不通過： 某些關鍵指標超出預期范圍，存在性能問題。

6. 問題定位： 進一步分析是測試本身的問題（如施壓機資源不足）還是被測系統的問題（如內存泄漏、數據庫瓶頸）。

12. 區分壓測問題與程序問題

診斷步驟：

1. 施壓機健康檢查：

   • 確認所有施壓機的 CPU、內存、磁盤等資源未達到極限。

   • 確保網絡帶寬充足，無網絡瓶頸。

2. 被測系統監控：

   • 檢查被測系統的資源使用情況，如 CPU 是否達到 100%、內存是否溢出。

   • 通過 JVM 指標分析是否存在內存泄漏或頻繁的垃圾回收。

3. 日志分析：

   • 查看被測系統的日志，檢查是否有異常錯誤（如 OutOfMemoryError）。

   • 查看 JMeter 的測試日志，確認是否有請求超時或連接失敗等錯誤。

4. 錯誤分類：

   • 壓測問題： 施壓機資源不足、網絡不穩定、JMeter 配置錯誤等。

   • 程序問題： 被測系統存在性能瓶頸、內存泄漏、數據庫慢查詢等。

5. 驗證與復現：

   • 如果懷疑施壓機問題，可以在另一臺施壓機上復現相同的測試，看問題是否依舊存在。

   • 如果問題在多臺施壓機上均存在，傾向于被測系統的問題。

13. 內存溢出與性能問題標注

實施方法：

• 自動標注： 在監控大屏上設置閾值，當某項指標（如 CPU 使用率、內存使用量）超過設定值時，自動高亮或標注異常。

• 日志關聯： 將性能指標異常與應用日志中的錯誤關聯起來，幫助快速定位問題原因。

• 報告生成： 在測試報告中詳細記錄所有異常情況，并說明其可能的原因及影響。

14. 與 BI 項目的關聯

整合 BI 項目的建議：

• 數據匯總與分析： 將壓測數據匯總到 BI 平臺（如 Tableau、Power BI），進行更深入的數據分析與可視化。

• 自動化報告： 利用 BI 工具自動生成定期的性能測試報告，方便團隊查看和決策。

• 交互式大屏： 在 BI 平臺上創建交互式儀表板，實時展示壓測與系統性能指標，支持多維度數據分析。

四、調優（待仔細學習）

在性能測試和系統優化過程中，調優是確保系統在高負載下依然穩定、高效運行的關鍵步驟。以下是關于 緩存、集群、MQ 中間件調優 以及 分布式微服務全鏈路壓測 的詳細解釋和優化建議。

---

1. 緩存調優

1.1 什么是緩存

緩存是一種存儲機制，用于臨時存儲經常訪問的數據，以減少數據獲取的延遲和降低數據庫或后端服務的負載。緩存可以存在于客戶端（如瀏覽器緩存）、服務器端（如內存緩存）或分布式緩存系統中。

1.2 緩存的類型

• 本地緩存： 存儲在應用程序所在的同一臺機器上，如使用 Java 的 ConcurrentHashMap、Caffeine、Guava 等。

• 分布式緩存： 存儲在獨立的緩存服務器上，支持多節點訪問和高可用性，如 Redis、Memcached。

• 瀏覽器緩存： 存儲在客戶端瀏覽器中，通過設置 HTTP 頭（如 Cache-Control）進行管理。

1.3 緩存調優策略

• 緩存淘汰策略：

  • LRU（Least Recently Used）： 移除最近最少使用的項。

  • LFU（Least Frequently Used）： 移除使用頻率最低的項。

  • FIFO（First In First Out）： 按照進入緩存的順序移除項。

• 緩存一致性：

  • 數據失效： 設置合理的 TTL（Time-To-Live），確保緩存數據不過期。

  • 緩存更新： 使用發布/訂閱機制或消息隊列通知緩存更新。

• 緩存預熱： 在系統啟動或部署后，提前將常用數據加載到緩存中，減少首次訪問的延遲。

• 分片與分區： 對于大規模緩存，進行分片或分區管理，提高緩存的擴展性和訪問效率。

1.4 緩存監控與優化

• 命中率監控： 通過監控緩存命中率，評估緩存的有效性，命中率低可能需要調整緩存策略或增加緩存容量。

• 內存使用監控： 確保緩存服務器有足夠的內存，避免頻繁的垃圾回收或內存溢出。

• 延遲監控： 監控緩存訪問的響應時間，確保緩存系統本身不會成為性能瓶頸。

---

2. 集群調優

2.1 什么是集群

集群是由多臺計算機（節點）通過網絡連接組成的一個統一系統，旨在通過分布式計算和資源共享，提高系統的可靠性、可擴展性和性能。常見的集群類型包括負載均衡集群、高可用集群和計算集群。

2.2 集群的組成

• 控制節點（Master）： 負責管理和協調集群中的其他節點，分發任務和監控集群狀態。

• 工作節點（Worker）： 執行具體的計算任務或服務請求。

• 負載均衡器： 分發客戶端請求到不同的工作節點，確保負載均衡和高可用性。

2.3 集群調優策略

• 負載均衡優化：

  • 均衡算法選擇： 使用合適的負載均衡算法，如輪詢（Round Robin）、最少連接（Least Connections）、哈希（Hash-based）。

  • 會話保持： 對于需要會話保持的應用，配置負載均衡器支持粘性會話或使用分布式會話管理。

• 資源分配與管理：

  • 自動擴展： 根據負載情況自動增加或減少工作節點，使用 Kubernetes、Docker Swarm 等容器編排工具實現彈性伸縮。

  • 資源限制： 設置每個節點的 CPU、內存、存儲等資源限制，防止單個節點資源被過度占用。

• 高可用性配置：

  • 冗余設計： 部署多個控制節點和負載均衡器，避免單點故障。

  • 故障轉移： 配置自動故障轉移機制，確保節點故障時請求能自動轉移到其他正常節點。

• 網絡優化：

  • 網絡帶寬： 確保集群內部網絡帶寬充足，避免網絡瓶頸。

  • 延遲優化： 使用低延遲的網絡設備和協議，減少節點間通信的延遲。

2.4 集群監控與優化

• 性能監控： 監控各節點的 CPU、內存、磁盤和網絡使用情況，確保資源均衡。

• 健康檢查： 定期檢查節點的健康狀態，及時發現并處理故障節點。

• 日志管理： 集中收集和分析集群日志，排查性能問題和故障原因。

---

3. MQ（消息隊列）中間件調優

3.1 什么是消息隊列（MQ）中間件

消息隊列是一種異步通信機制，允許不同系統或服務之間通過發送和接收消息進行通信。常見的 MQ 中間件有 RabbitMQ、Apache Kafka、ActiveMQ、RocketMQ 等。

3.2 消息隊列的作用

• 解耦系統： 使生產者和消費者獨立運行，降低系統耦合度。

• 提高可靠性： 消息隊列可以持久化消息，確保消息不丟失。

• 緩沖流量： 在高峰期，消息隊列可以緩沖大量請求，平滑系統負載。

• 異步處理： 提高系統響應速度，適合處理耗時任務。

3.3 MQ 中間件調優策略

• 隊列設計優化：

  • 合理劃分隊列： 根據業務功能劃分不同的隊列，避免單個隊列過于繁忙。

  • 消息分區： 對于分布式 MQ（如 Kafka），合理設計分區數，平衡負載和并行度。

• 生產者與消費者優化：

  • 批量發送與接收： 使用批量操作減少網絡開銷，提高吞吐量。

  • 并發處理： 增加消費者的并發數，提升消息處理能力。

• 持久化與可靠性：

  • 消息持久化： 配置合理的持久化策略，確保消息不丟失，但也要注意持久化帶來的性能影響。

  • 確認機制： 配置合理的消息確認機制，確保消息被成功消費。

• 性能參數調優：

  • 內存與緩存： 調整 MQ 中間件的內存緩存大小，提高消息處理速度。

  • 網絡配置： 優化網絡參數，減少消息傳輸延遲。

• 監控與限流：

  • 監控指標： 監控隊列長度、消息吞吐量、延遲等指標，及時發現和處理性能瓶頸。

  • 限流機制： 在高負載情況下，使用限流策略防止 MQ 過載，保護下游系統。

3.4 MQ 中間件監控與優化

• 實時監控： 使用監控工具（如 Prometheus + Grafana）監控 MQ 的運行狀態和性能指標。

• 日志分析： 分析 MQ 日志，排查消息積壓、消費失敗等問題。

• 故障恢復： 配置高可用架構，如 MQ 集群和鏡像隊列，確保消息服務的連續性。

---

4. 分布式微服務全鏈路壓測

4.1 什么是分布式微服務

分布式微服務架構將應用程序拆分為多個獨立的服務，每個服務負責特定的業務功能，通過網絡進行通信和協作。這樣的架構具有高可擴展性、靈活性和容錯性。

4.2 全鏈路壓測的概念

全鏈路壓測（End-to-End Performance Testing）是指對整個分布式微服務系統進行全面的性能測試，模擬真實用戶行為，評估系統在高負載下的響應能力、穩定性和整體性能。全鏈路壓測涵蓋了從前端到后端所有服務的性能測試。

4.3 全鏈路壓測的關鍵要素

• 用戶行為模擬： 模擬真實用戶的操作流程和使用習慣，包括訪問頻率、并發數和思考時間。

• 服務依賴分析： 識別和分析各微服務之間的依賴關系，確保壓測覆蓋所有關鍵路徑。

• 性能指標監控： 監控各微服務的響應時間、吞吐量、錯誤率及系統資源使用情況。

• 數據一致性： 確保在壓測過程中，數據的一致性和完整性不受影響。

4.4 全鏈路壓測的實施步驟

1. 測試計劃設計：

   • 業務流程定義： 確定需要壓測的業務流程，編寫詳細的測試用例。

   • 并發用戶數設定： 根據業務需求和預期負載，確定并發用戶數和測試持續時間。

   • 數據準備： 準備測試所需的輸入數據和測試環境。

2. 測試環境搭建：

   • 環境一致性： 確保測試環境與生產環境盡可能一致，包括硬件配置、網絡拓撲和服務版本。

   • 隔離測試環境： 使用獨立的測試環境，避免對生產環境造成影響。

3. 測試工具配置：

   • 選擇合適的測試工具： 使用 JMeter、Gatling、Locust 等性能測試工具進行壓測。

   • 分布式測試配置： 配置分布式測試架構，確保能夠模擬大規模的并發用戶。

4. 執行壓測：

   • 逐步加載： 采用逐步增加負載的方法，觀察系統在不同負載下的表現。

   • 全鏈路覆蓋： 確保測試覆蓋所有關鍵微服務和依賴組件，避免遺漏關鍵路徑。

5. 監控與分析：

   • 實時監控： 使用監控工具（如 Prometheus + Grafana）實時監控系統性能指標。

   • 日志分析： 收集并分析各微服務的日志，識別性能瓶頸和錯誤。

   • 鏈路追蹤： 使用分布式追蹤工具（如 Jaeger、Zipkin）追蹤請求在各微服務間的傳播，分析響應時間和瓶頸點。

6. 結果評估與優化：

   • 性能報告生成： 匯總測試結果，生成詳細的性能報告。

   • 瓶頸定位與優化： 根據測試結果，定位性能瓶頸，進行針對性的優化。

   • 復測驗證： 在優化后進行再次壓測，驗證優化效果。

4.5 分布式微服務全鏈路壓測的優化建議

• 服務解耦與獨立部署： 確保每個微服務獨立部署，減少服務間的耦合，提高系統的可維護性和擴展性。

• 容錯與降級機制： 實現服務的容錯和降級機制，確保部分服務故障時，系統整體仍能保持穩定運行。

• 自動化測試與持續集成： 將全鏈路壓測集成到 CI/CD 流程中，確保每次代碼變更后都進行性能驗證。

• 資源彈性管理： 使用容器化和編排工具（如 Kubernetes）實現資源的彈性管理，動態調整服務實例數應對負載變化。

• 安全性考慮： 在壓測過程中，確保數據的安全性和隱私保護，避免敏感數據泄露。

五、連接數據庫進行數據庫壓測（待仔細學習）

1、步驟

1. 下載JDBC驅動

   • 獲取所需的JDBC驅動（JAR包），并將其放入JMeter的指定目錄下。

2. 配置JDBC原件

   • 在JMeter中添加配置元件（Config Element）中的JDBC配置。

3. 連接數據庫

   • 配置并測試與目標數據庫的連接，確保連接正常。

4. 編寫SQL操作

   • 編寫需要執行的SQL語句，用于壓測過程中模擬實際的數據庫操作。

5. 設置線程屬性

   • 配置壓測的線程屬性，包括線程數、持續時間和循環次數，以模擬并發用戶行為。

6. 執行數據庫壓測

   • 啟動壓測，監控測試過程中的各項性能指標。

2、性能測試指標

1. 執行效率

   • 定義：評估數據庫操作的整體性能和響應時間。

   • 關注點：查詢執行時間、事務處理時間等。

2. 慢查詢

   • 定義：執行時間超過預設閾值的SQL語句。

   • 分析內容：

     • 哪些語句存在慢查詢。

     • 慢查詢的原因（如缺乏索引、復雜查詢等）。

3. 組件問題

   • 定義：數據庫系統中各組件（如緩沖池、查詢優化器等）可能存在的性能瓶頸。

   • 分析內容

     ：

     • 緩沖池使用情況。

     • 查詢優化器的效率。

4. 鎖問題

   • 定義：多個事務同時訪問同一數據時，因鎖機制導致的等待、阻塞或死鎖。

   • 分析內容：

     • 哪行代碼出現鎖的問題。

     • 哪條語句導致鎖。

     • 哪張表存在鎖的問題。

5. 緩沖區（Buffer）

   • 定義：用于緩存數據和索引的內存區域（如InnoDB緩沖池）。

   • 關注點：緩沖池大小、命中率、讀寫次數等。

6. 表結構問題

   • 定義：數據庫表設計不合理，導致查詢性能低下或存儲空間浪費。

   • 分析內容：

     • 表的大小和增長速度。

     • 索引設計是否合理。

     • 數據分布和訪問模式。

7. 分庫分表

   • 水平分表（Sharding）：

     • 定義：將一張大表按照某個規則（如ID范圍、哈希值）拆分為多個表，每個表存儲部分數據。

     • 優點：減少單表數據量，提高查詢性能，便于水平擴展。

     • 缺點：增加查詢復雜性，需修改應用邏輯。

   • 垂直分表：

     • 定義：將表的不同列拆分為多個表，每個表存儲部分字段。

     • 優點：減少單表寬度，提高查詢效率，分離熱數據和冷數據。

     • 缺點：增加表之間的關聯查詢，需維護多個表的完整性。

3.性能瓶頸發現方法

在進行數據庫壓測后，發現性能瓶頸并確定哪些SQL語句存在慢查詢或鎖問題是優化數據庫性能的關鍵步驟

一、啟用并配置慢查詢日志

1. 啟用慢查詢日志

慢查詢日志記錄了執行時間超過指定閾值的SQL語句。通過分析這些日志，可以識別出性能較差的查詢。

– 啟用慢查詢日志
SET GLOBAL slow_query_log = ‘ON’;

– 設置慢查詢時間閾值（例如，記錄執行時間超過2秒的查詢）
SET GLOBAL long_query_time = 2;

– 可選：記錄未使用索引的查詢
SET GLOBAL log_queries_not_using_indexes = ‘ON’;

2. 配置慢查詢日志文件路徑

在MySQL配置文件（my.cnf或my.ini）中設置慢查詢日志文件路徑和其他相關參數：

[mysqld]
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow-query.log
long_query_time = 2
log_queries_not_using_indexes = ON

3. 分析慢查詢日志

使用工具如 mysqldumpslow 或 pt-query-digest 來分析慢查詢日志，找出最頻繁和耗時最長的查詢。

使用 mysqldumpslow
mysqldumpslow -s t /var/log/mysql/slow-query.log

使用 pt-query-digest

pt-query-digest /var/log/mysql/slow-query.log

二、使用 Performance Schema 進行深入分析

1. 啟用 Performance Schema

確保 performance_schema 已啟用。在MySQL配置文件中：

[mysqld]
performance_schema = ON

2. 查詢慢查詢和鎖信息

利用 performance_schema 提供的表格，可以查詢到詳細的執行情況，包括等待鎖的信息。

– 查看慢查詢
SELECT
EVENT_ID,
SQL_TEXT,
TIMER_WAIT,
LOCK_TIME,
ROWS_SENT,
ROWS_EXAMINED
FROM
performance_schema.events_statements_history
WHERE
TIMER_WAIT > 2000000000; – 時間單位為皮秒（這里表示超過2秒）

– 查看鎖等待
SELECT
thd.PROCESSLIST_ID,
thd.PROCESSLIST_USER,
thd.PROCESSLIST_HOST,
thd.PROCESSLIST_DB,
thd.EVENT_NAME,
thd.STATE,
thd.SQL_TEXT
FROM
performance_schema.threads thd
JOIN
performance_schema.events_waits_current ewc
ON thd.THREAD_ID = ewc.THREAD_ID
WHERE
ewc.EVENT_NAME LIKE ‘wait/lock/%’;

三、使用 EXPLAIN 分析查詢計劃

對發現的慢查詢，使用 EXPLAIN 分析其執行計劃，找出查詢的瓶頸，如全表掃描、缺失索引等。

EXPLAIN ANALYZE
SELECT * FROM your_table WHERE some_column = ‘value’;

關鍵指標：

• type：訪問類型，盡量使用 const、eq_ref 或 ref，避免 ALL（全表掃描）。

• key：使用的索引，確保查詢使用了合適的索引。

• rows：掃描的行數，行數越少越好。

• Extra：查看是否有 Using temporary 或 Using filesort，這可能影響性能。

四、監控和分析鎖問題

1. 查看當前鎖情況

SELECT
r.trx_id waiting_trx_id,
r.trx_mysql_thread_id waiting_thread,
r.trx_query waiting_query,
b.trx_id blocking_trx_id,
b.trx_mysql_thread_id blocking_thread,
b.trx_query blocking_query
FROM
information_schema.innodb_lock_waits w
JOIN
information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id
JOIN
information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id;

2. 使用 SHOW ENGINE INNODB STATUS

該命令提供了當前InnoDB引擎的詳細狀態，包括鎖等待信息。

SHOW ENGINE INNODB STATUSG

在輸出中，查找 LATEST DETECTED DEADLOCK 和 TRANSACTIONS 部分，分析死鎖和鎖等待的詳細信息，包括涉及的SQL語句和表。

五、結合壓測工具的監控功能

如果你使用的是JMeter等壓測工具，可以結合其監控插件或第三方監控工具（如Prometheus、Grafana）來實時監控數據庫的性能指標。

1. 設置JMeter監控

• 使用JMeter的監聽器（Listener）如 JDBC Request、View Results Tree，實時查看查詢的響應時間和錯誤。

• 使用 JMeter Plugins 中的監控插件，如 PerfMon，監控服務器的CPU、內存、磁盤I/O等指標，關聯到數據庫性能問題。

2. 使用第三方監控工具

• Percona Monitoring and Management (PMM)：一個開源的監控解決方案，專為MySQL設計，提供實時查詢分析和性能指標。

• Grafana + Prometheus：通過配置MySQL Exporter，收集數據庫的性能指標，并在Grafana中可視化展示，幫助識別性能瓶頸。

六、優化發現的問題

1. 優化慢查詢

• 添加或優化索引：確保查詢中使用的列有合適的索引。

• 重寫查詢：簡化復雜的查詢，避免不必要的子查詢和JOIN操作。

• 分區表：對于大表，使用分區技術減少查詢的掃描范圍。

2. 解決鎖問題

• 優化事務：縮短事務的執行時間，避免長時間持有鎖。

• 隔離級別調整：在保證數據一致性的前提下，適當降低事務隔離級別（如從 REPEATABLE READ 調整為 READ COMMITTED）。

• 索引優化：確保查詢使用索引，減少鎖的范圍和數量。

3. 緩沖池和表結構優化

• 調整 innodb_buffer_pool_size：確保緩沖池足夠大，以容納大部分活躍數據，減少磁盤I/O。

• 分庫分表

  • 水平分表：將表的數據按某個鍵值分散到多個表中，減小單表的數據量，提升查詢性能。

  • 垂直分表：將表的不同列分散到多個表中，減少每個表的寬度，提升查詢效率。

七、持續監控和迭代優化

性能優化是一個持續的過程，應定期進行壓測和監控，及時發現和解決新的性能瓶頸。同時，結合業務發展和數據增長，動態調整數據庫配置和架構，確保系統始終保持高效穩定。