資料庫效能優化的目標是通過充分利用系統資源來最小化查詢的響應時間。對這些資源的最佳利用包括最大限度地減少網路流量、磁碟 I/O 和 CPU 時間。這個目標只能通過理解資料的邏輯和物理結構、系統上使用的應用程式以及資料庫的衝突使用如何影響效能來實現。實際上，資料庫效能優化是一項系統工程，需要使用系統化分析方法，從硬體、軟體和應用場景等多個相關聯的維度深入分析、評估與優化，在資料庫系統的架構階段、設計階段、開發階段、部署階段、執行階段等各環節中去尋找效能問題的瓶頸和解決方案。

本文精選了HeapDump效能社群中的8篇資料庫效能優化相關文章，這些文章內不僅包含了影響資料庫效能的因素，資料庫效能評估標準、優化方法的內容，還介紹了一些資料庫設計原則和程式設計技巧，並且記錄了一些或大或小的實戰案例，幫助大家快速瞭解資料庫效能優化，掌握一些實操技能。

1.帶你重走 TiDB TPS 提升 1000 倍的效能優化之旅

作者：TiDB_Robot

作者介紹：TiDB是一個開源的NewSQL資料庫，支援混合事務和分析處理（HTAP）工作負載。它與MySQL相容，並且可以提供水平可擴充套件性、強一致性和高可用性。它主要由PingCAP公司開發和支援，並在Apache 2.0下授權。TiDB現已正式入駐HeapDump效能社群，未來將會分享更多資料庫效能優化相關的優質文章。

文章連結：https://heapdump.cn/article/3021827

精彩導讀：效能優化這個事情核心只有一句話，使用者響應時間去哪兒了？效能優化很困難的原因在於，為了定位使用者響應時間在各個模組的分佈，需要對系統的各個部件進行測量和分析，從底層硬體，CPU、IO、網路到上層應用架構，應用程式碼跟資料庫的互動方式都需要涉及。本文第一部分介紹了一下效能優化的通用的方法，第二部分講了一個實際案例。

使用者響應時間

效能優化的第一個概念是使用者響應時間。使用者響應時間是使用者在使用一個業務系統的時候，發起一個請求，這個請求返回總體消耗的時間為使用者響應時間。一個典型的使用者響應時間的分佈如下圖：

從時序圖看，一個使用者響應時間可能包括：

1.使用者請求的到達應用伺服器的網路時間

2.應用伺服器本身業務邏輯處理時間

3.應用伺服器跟資料庫伺服器之間互動消耗的網路的時間

4.資料庫多次處理 SQL 的時間

5.應用伺服器返回使用者資料的網路時間

整個鏈路上來看，會涉及到網路、應用伺服器和資料庫這幾個重要的部件。只要知道戶響應時間在每個模組的分佈，我們就能定位瓶頸，進行鍼對性的優化。

現實中效能瓶頸的定位又非常難。因為絕大部分的應用都沒有去部署 APM 之類的工具，能夠去跟蹤一個應用請求在全鏈路上面的時間消耗。大部分場景的效能優化工作，都是在缺乏全域性的時間分佈情況下進行的。我們推薦的一種可靠的效能優化的方法：基於資料庫時間進行效能優化

資料庫時間

資料庫時間為單位時間內資料庫提供的服務時間。對比資料庫時間和應用總的使用者響應時間，可以判斷應用系統的瓶頸是否在資料庫中。

一個應用系統，ΔT 時間內提供的總的服務時間，可以拿平均業務的 TPS 乘以平均的響應時間。ΔT 時間內的資料庫時間，有多種演算法：

1.平均 TPS X 平均事務延遲 X ΔT

2.平均的 QPS X 平均的延遲 X ΔT

3.平均的活躍連線數 X ΔT, 下圖資料庫活躍連線圖的面積即為資料庫時間

基於資料庫時間和使用者響應時間的對比，先從全域性的角度判斷瓶頸在資料庫裡面還是在資料庫的外面，然後再進行鍼對性的排查和優化。把資料庫時間除以總的使用者響應時間：

趨近 0，資料庫時間在總的服務時間裡面是很小的佔比，說明瓶頸並不在資料庫中。

趨近 1，說明整個應用系統瓶頸是在資料庫裡面。工程師通過降低資料庫時間來進行效能優化，比如優化 SQL 執行計劃、解決資料庫中存在的熱點爭用等。

2.5G時代，如何徹底搞定海量資料庫的設計與實踐

作者：孫玄｜奈學教育

作者介紹：孫玄，現任奈學教育科技創始人&CEO ，畢業於浙大，前百度資深研發工程師、前 58 集團技術委員會主席／高階系統架構師到前轉轉公司技術委員會主席／首席架構師／大中後臺技術負責人。江湖人稱“玄姐”，出版過《百萬年薪架構師修煉之路》書籍。

文章連結：https://heapdump.cn/article/761671

精彩導讀：5G時代，業務資料越來越豐富，業務使用MySQL資料庫作為後臺儲存，儲存引擎使用InnoDB，會帶來哪些挑戰？如何針對公司業務特點及MySQL資料庫特性，制定若干資料庫使用規範供一線RD在設計業務時參考部分內容要求強制執行。本文從介紹MySQL相關關鍵基礎架構，並結合實際案例介紹表和索引的設計技巧，並對規範中重點內容做詳細解讀。

小結：

1.自增主鍵效能不一定高，需要結合實際業務場景做分析；

2.大多數場景資料型別選擇上儘量使用簡單的型別；

3.索引不是越多越好，太多的索引會導致過大的索引檔案；

4.如果要查詢的資料可以在索引檔案中找到，儲存引擎就不會查詢主鍵索引訪問實際記錄。

3.Mysql的sql優化方法

作者：臆想的一隻貓

文章連結：https://heapdump.cn/article/2994366

精彩導讀：本文總結了一些對mysql效能有利的程式設計技巧。

1、選擇最合適的欄位屬性

2、儘量把欄位設定為NOT NULL

3、使用連線(JOIN)來代替子查詢(Sub-Queries)

4、使用聯合(UNION)來代替手動建立的臨時表

5、事務

6、鎖定表

7、使用外來鍵

8、使用索引

9、優化查詢語句

4.一些比較好的Redis效能優化思路總結

作者：劉思寧

文章連結：https://heapdump.cn/article/2871512

精彩導讀：在一些網路服務的系統中，Redis 的效能，可能是比 MySQL 等硬碟資料庫的效能更重要的課題。比如微博，把熱點微博，最新的使用者關係，都儲存在 Redis 中，大量的查詢擊中 Redis，而不走 MySQL。那麼，針對 Redis 服務，我們能做哪些效能優化呢？或者說，應該避免哪些效能浪費呢？那麼，針對 Redis 服務，我們能做哪些效能優化呢？或者說，應該避免哪些效能浪費呢？

在討論優化之前，我們需要知道，Redis 服務本身就有一些特性，比如單執行緒執行。除非修改 Redis 的原始碼，不然這些特性，就是我們思考效能優化的基本面。首先，Redis 使用作業系統提供的虛擬記憶體來儲存資料。其次，Redis 支援持久化，可以把資料儲存在硬碟上。第三，Redis 是用 key-value 的方式來讀寫的，而 value 中又可以是很多不同種類的資料；更進一步，一個數據型別的底層還有被儲存為不同的結構。最後，在上面的介紹中沒有提到的是，Redis 大多數時候是單執行緒執行的（single-threaded)，即同一時間只佔用一個 CPU，只能有一個指令在執行，並行讀寫是不存在的。

針對這些特性，概括了對Redis進行效能優化的幾個切入點：優化網路延時；警惕執行時間長的操作；優化資料結構、使用正確的演算法；考慮作業系統和硬體是否影響效能；考慮持久化帶來的開銷；使用分散式架構 —— 讀寫分離、資料分片。

5.千萬級資料表選錯索引導致的線上慢查詢事故

作者：後端技術漫談

文章連結：https://heapdump.cn/article/2166752

精彩導讀：最近在線上環境遇到了一次SQL慢查詢引發的資料庫故障，影響線上業務。經過排查後，確定原因是「SQL在執行時，MySQL優化器選擇了錯誤的索引（不應該說是“錯誤”，而是選擇了實際執行耗時更長的索引）」。在排查過程中，查閱了許多資料，也學習了下MySQL優化器選擇索引的基本準則，在本文中進行解決問題思路的分享。本人MySQL瞭解深度有限，如果錯誤歡迎理性討論和指正。在這次事故中也能充分看出深入瞭解MySQL執行原理的重要性，這是遇到問題時能否獨立解決問題的關鍵。

6.MySQL全面瓦解21（番外）：一次深夜優化億級資料分頁的奇妙經歷

作者：翁智華

文章連結：https://heapdump.cn/article/2869483

精彩導讀：本次事故的情況是線上的一個查詢資料的介面被瘋狂的失去理智般的呼叫，這個操作直接導致線上的MySql叢集被拖慢了。分析慢查詢日誌後發現，其實對於我們的MySQL查詢語句來說，整體效率還是可以的，該有的聯表查詢優化都有，該簡略的查詢內容也有，關鍵條件欄位和排序欄位該有的索引也都在，問題在於他一頁一頁的分頁去查詢，查到越後面的頁數，掃描到的資料越多，也就越慢。這種查詢的慢，其實是因為limit後面的偏移量太大導致的。比如像上面的limit 2000000,25，這個等同於資料庫要掃描出 2000025條資料，然後再丟棄前面的 20000000條資料，返回剩下25條資料給使用者，這種取法明顯不合理。《高效能MySQL》第六章：查詢效能優化，對這個問題有過說明：分頁操作通常會使用limit加上偏移量的辦法實現，同時再加上合適的order by子句。但這會出現一個常見問題：當偏移量非常大的時候，它會導致MySQL掃描大量不需要的行然後再拋棄掉。

7.Redis 高負載下的中斷優化

作者：驍雄 春林

作者介紹：驍雄，14年加入美團點評，主要從事MySQL、Redis資料庫運維，高可用和相關運維平臺建設。春林，17年加入美團點評，畢業後一直深耕在運維線，從網路工程師到Oracle DBA再到MySQL DBA 多種崗位轉變，現在美大主要職責Redis運維開發和優化工作。

文章連結：https://heapdump.cn/article/2842148

精彩導讀：2017年年初以來，隨著Redis產品的使用者量越來越大，接入服 務越來越多，再加上美團點評Memcache和Redis兩套快取融合，Redis服務端的總體請求量從年初最開始日訪問量百億次級別上漲到高峰時段的萬億次級別，給運維和架構團隊都帶來了極大的挑戰。原本穩定的環境也因為請求量的上漲帶來了很多不穩定的因素，其中一直困擾我們的就是網絡卡丟包問題。起初線上存在部分Redis節點還在使用千兆網絡卡的老舊伺服器，而快取服務往往需要承載極高的查詢量，並要求毫秒級的響應速度，如此一來千兆網絡卡很快就出現了瓶頸。經過整治，我們將千兆網絡卡伺服器替換為了萬兆網絡卡伺服器，本以為可以高枕無憂，但是沒想到，在業務高峰時段，機器也竟然出現了丟包問題，而此時網絡卡頻寬使用還遠遠沒有達到瓶頸。

8.記一次慢SQL優化

作者：艾小仙

作者介紹：艾小仙，前阿里P7技術專家。工作11年，做過開發、產品、運營，行業橫跨網際網路安全、電商、支付、金融、酒店、O2O等等，熱衷於分享大廠面試經驗、架構設計、中介軟體、演算法、資料庫等熱門技術。微信公眾號【艾小仙】粉絲數10w+，曾被各大技術社群公眾號轉載推薦。

文章連結：https://heapdump.cn/article/3058836

精彩導讀：這是一個線上問題，從日誌平臺查詢到的 SQL 執行情況，該 SQL 執行的時間為 11.146s，可以認定為是一個慢查詢。整個情況來看，緩衝區大小、排序欄位的資料長度、查詢資料條數等都會影響查詢效能。分析了整個排序過程，指導的優化思想就是儘量不使用using filesort，尤其是在排序的資料量比較大的時候，那麼優化的方式就是儘量讓查詢出來的資料已經是排好序的，也就是合理使用聯合索引以及覆蓋索引。

有效能問題，找HeapDump效能社群