導語 | 雖然數據庫上雲解決了傳統數據庫很多問題，但如何讓雲數據庫發揮最優的效能，依然充滿極大挑戰。爲解決這一難題，高速發展的雲數據庫正在走向“自治”。本文是對騰訊雲數據庫高級產品經理劉迪在雲+社區沙龍online的分享整理，爲大家帶來騰訊雲在數據庫自治服務領域的探索和實踐，希望與大家一同交流。
<https://v.qq.com/x/page/e3130i01e5t.html
一、數據庫自治的演進
上圖所示是一張關於數據庫自治的宏觀視圖。
業內普遍定義的石器時代大概是在十幾、二十年前，剛剛進入數據庫發展的快速軌道，當時的技術方案和對於數據庫的認知都處於一個初級的階段。
經歷了後續的工具時代、專家時代，現在數據庫自治已經到達了智能時代。在智能時代中，我們享受到了數據庫自治在數據庫性能優化、管理、服務等紅利。
很多人都有疑惑，這條時代發展的時間線到底是怎麼演進的？其實這個問題不難理解，大家在日常工作中也能體會到，時代的更替、技術的誕生，往往跟業務的需求有關，也跟現有的技術能力有關。
無論是業務驅動還是技術驅動，最終的結果就是使得數據庫自治從石器時代到工具時代、專家時代、智能時代，這樣一個井然有序的發展過程。
我們所謂的石器時代、工具時代、專家時代、智能時代其實不僅僅是指代時間的迭代，更多的是指技術的發展和趨勢的迭代。所以有些公司現在可能依然處於石器時代，有些公司可能很早就進入了專家或者智能時代。
1. 石器時代
首先我們來看石器時代解決了什麼樣的問題？石器時代數據庫運維和服務領域關注的問題是什麼？
最明顯的一個特徵，石器時代關注的問題就是“沒有問題”，也就是保證業務不出問題，沒有問題就是最大的成功。
因爲在石器時代，運維依靠的主要是純手工的人力，靠數據庫運維工程師沒日沒夜進行手工的運維操作。
在這個階段，往往是有經驗的DBA帶一些剛剛入門或者剛剛畢業的同學，傳幫接代的進行知識傳遞。這樣造成的結果就是整個團隊的資質水平參差不齊，但整個團隊還是可以承擔起公司業務線數據庫運維的重任。
石器時代最大的目標、最大的收益，就是知識的積累，但積累的大部分是碎片化、零星化的知識。
2. 工具時代
在工具時代，關注的焦點從“不出問題”，轉變爲“在不出問題的前提下如何提高效率”。工具時代不再是原來的手工錄入代碼、手工處理問題，而是開始把經驗、知識沉澱成腳本或者工具。
目前大部分公司的數據庫運維有可能是專人專崗，也可能是由研發同學兼職，他們會用自己寫的工具或者網上開源的工具進行運維工作。這個工具可能是一個很簡單的腳本，也可能是非常複雜的命令集合，這是數據庫運維中一個必不可少的過程。
在這個時代中，大家關注的焦點是怎樣用工具去很好的滿足業務的需求。
除了人和工具之外，能幫助大家提高效率的還有流程管理。在工具時代，看重的一點是流程管理如何把人和工具結合在一起，提高數據庫運維的效率。
在這個階段會出現大量審覈的系統、流程和服務，每個審覈都有着非常規範的流程來進行數據庫的運維。
3. 專家時代
當工具時代的積累達到了一定的程度，就到達了專家時代。
在這個時期，大家發現之前的腳本雖然很多但很雜亂，用了各種各樣的編程語言、運行在各種不同的環境中，沒有統一的管理平臺，也沒有統一的歸類整理。數據庫運維的水平往往取決於寫這個腳本的運維工程師的個人能力，很難很好繼承下去。
所以專家時代更多的是想把腳本標準化，用服務平臺代替雜亂無章的腳本，從而將腳本規範化、標準化，變成一個可以實現自動化運維的平臺。
通過這個平臺，無論是有資歷的工程師還是剛剛入門的研發同學，都可以井然有序的根據平臺化的服務進行數據庫管理。
把專家的經驗轉變爲可複製的能力工具，是專家時代運維最顯著的特點。
4. 雲數據庫時代
隨着近幾年雲數據庫時代的到來，很多企業從自建DB遷移到了雲上，也開始認知到雲帶給大家的好處。
數據庫從本地部署到雲上，可以自建雲服務器，也可以直接使用雲上提供的PaaS服務。這部分無論是關係型數據庫還是非關係型數據庫或者是NewSQL，大家都開始逐漸享受到雲數據庫時代的紅利。
在數據庫上雲後，很多人會問雲廠商提供的服務是不是可以保證數據庫的運維沒有任何的問題了？就不再需要去思考、不需要擁有之前一代代繼承下來的經驗？
其實並不是這樣。數據庫上雲解決的只是基礎的管控服務，比如備份、監控、故障切換等等，雲上提供的是相應的PaaS能力、高可用能力和數據可靠性的能力。
但其實雲服務的到來，對數據庫的運維服務反而提出了更多的挑戰。這裏我們可以舉幾個例子。
首先是資源的評估，這是在上雲、多雲的使用中會經常遇到的問題。本地使用的是4核16G的物理機，那麼在雲上要購買哪種型號的服務器？購買哪種規格的PaaS數據庫服務？絕大多數沒有經歷過雲遷移的同學在這個階段會認爲最好的方法是平移，這樣一定不會出現問題。其實不然，在某些環節出現的問題有可能會導致業務性能出現故障。
其次在上雲之後，大家會認爲雲的彈性伸縮促使了業務的快速發展。近兩年來很多的電商業務量、訪問流量都呈幾何倍數增長，各種各樣的大促節日讓業務部門、數據庫運維部門面臨更重的數據庫保障任務。這時要如何保障資源評估的準確率，以及快速處理突發事件就成了要解決的問題。
同樣對於雲上的數據庫，最大的變化就是上雲之後變成了黑盒。這種黑盒現象使得在故障診斷、分析和恢復數據庫問題時不能快速的定位問題、發現問題、解決問題。
所以雲上數據庫時代到來以後，對數據庫運維同學其實是提出了更高的要求。對於非專業的運維同學，如何通過雲上成千上百的異常指標來發現問題、找出規律，是面臨的一個大問題。
最後，雲時代還對性能提出了新的考驗。如何利用經驗幫助提高數據庫的性能，並且持續不斷的進行優化？隨着數據量的積累和業務的增長，甚至一些數據的變化導致的數據分佈不均衡，都會導致數據庫出現問題，所以數據庫性能的優化在雲上有着更大的挑戰。
5. 智能時代
正因爲上面講到的原因，促使運維從原來平臺化運維，不得不推進進入智能時代的發展。智能時代大家不再是人和工具的結合，而是人、雲資源、以及自治服務的結合，從而提供更好的數據庫運維服務能力。
這個階段的目標是數據庫能力和專家經驗的共享，能夠把之前已經積累好、沉澱好的數據庫處理經驗自動化，能夠讓數據庫自己處理一些簡單的問題，不需要人工干預。面對複雜問題的時候能夠提供非常充足的建議，通過專家的干預進行最後的處理。
在雲時代也要通過自治服務幫助大家獲取數據庫目前存在的看不見、摸不到的隱患。比如查詢操作，當一個表只有十行數據的時候，無論怎樣查詢返回速度都會非常快、CPU 消耗也會非常小，但一旦併發上來，比如數據量增長到十萬、百萬量級的時候，原來看起來非常快的 SQL 就都變慢了。
在故障沒有發生前，如何通過自治服務幫助用戶在隱患階段就能解決數據庫的潛在問題，這就是數據庫智能時代主要關注的焦點。
類比自動駕駛的等級，我們把數據庫自治運維也切分成 Level 0 ~ Level 4 這幾個階段。
最開始所有操作都需要人工部署、人工干預，而後期人只是作爲輔助，一些簡單的工作、沒有成長、重複的勞動都可以交給數據庫自治服務統一完成。
經常有人會問，數據庫自治服務是否會取代人工？取代數據庫運維？取代DBA？我可以很明確的告訴大家，數據庫自治目的是爲了提高處理問題的效率、提高業務的穩定性、降低業務的故障導致的損失，而並不是爲了取代DBA。
DBA在數據庫各個發展時代的核心價值，從會寫自動命令到會編寫腳本，處理線上的故障、會排查日誌，再到會做一些監控和管控平臺。到了數據庫自治時代，數據庫運維核心價值應該是能夠貼近業務，在業務層面發揮更多的價值。能夠通過積累、通過對業務的理解和數據庫的理解，幫助業務在架構設計、附表設計、整體的業務架構上面做更多的工作。
所以數據庫自治服務是放大了數據庫運維的核心價值，而不是取代了數據庫運維。
二、騰訊在數據庫自治中的探索與實踐
騰訊在數據庫自治中的探索跟整個行業的歷史發展一樣，同樣是從簡單的運維繫統雛形，到後面隨着業務體量越來越大，包括微信、騰訊視頻、紅包業務、騰訊遊戲產業、騰訊體育這些大業務不斷的擴張，使得人工操作遇到了瓶頸，成本也到了需要轉型的階段，因此數據庫自治平臺從內部開始逐漸孵化。
因爲騰訊自身業務的行業屬性非常多，有內容線的行業屬性，有社交類的、有文體類的等等，根據不同的使用場景不斷打磨後，去年開始對外發布 —— 數據庫智能管家DBbrain，這是騰訊對外發布的一款強大的數據庫自治產品。
1. DBbrain 產品能力解讀
DBbrain 服務在雲上是免費的，大家可以進行免費的試用。DBbrain 提供的自治服務涵蓋三個方面：
- 性能優化：利用機器學習、大數據手段快速複製資深數據庫管理員的成熟經驗，將大 量數據庫問題的診斷優化工作自動化，服務於雲上和雲下企業。
- 安全防護：提供從用戶行爲安全、SQL 安全到數據存儲加密安全等多項數據安全服務， 公安部認證的等保合規性安全產品。
- 數據庫管理：提供免安裝、免運維、即開即用、多種數據庫類型與多種環境統一的 web 數據庫管理終端。
數據庫智能管家 DBbrain 與傳統數據庫管理工具的區別在於，它不僅僅作爲輔助運維工具供 DBA 使用，而是面向所有用戶，包括運維團隊、開發團隊、運營團隊。其核心思想是通過智能運維平臺爲應用部門提供標準化和自動化的數據庫運維服務。
2. DBbrain系統架構解讀
數據庫智能管家 DBbrain 提供的自治服務是跨數據庫引擎的，是通過多數據庫引擎插件式方式提供的，不僅支持 MySQL，也支持 NoSQL、Redis等。
之前大家在網上聽過Oracle有自治數據庫、微軟也有自治服務，但他們的服務是在特有引擎上進行數據庫自治，並不是多引擎的的服務平臺。
我們認爲數據庫自治既然是爲了幫助數據庫運維同學減輕工作的壓力、提高運維的效率，應該是具備涵蓋數據庫運維所涉及的儘可能多的數據庫引擎，因爲一個業務可能不止會用到單一的數據庫，比如常見的 MySQL + Redis 組合等。
在數據的採集層，以 MySQL 爲例，我們會根據不同數據採集監控指標、比如主機監控指標、網絡監控指標、數據庫監控指標，通過秒級監控的指標以及採集的日誌信息，幫助用戶發現更廣的問題面，不僅僅是數據庫層面的故障、主機層面和管控任務的故障都可以有豐富的源數據的記錄。
在數據的計算和加工層的模塊，模塊通過流式計算平臺提取出特徵數據。這個地方並不需要人工進行分類，而是通過特徵提取和加工來識別出異常信息、異常的數據，再進行異常指標和異常趨勢的預測。
這個模型我們自身已經訓練出了涵蓋比較多指標和比較多情況的通用引擎，另一方面，也通過了現網用戶對數據庫使用情況和對於問題的反饋來進行監督式學習，不斷增強模型訓練，做到模型對業務是千人千面，而不是一套通用模型面對所有的數據庫業務。
在實時診斷模塊中，通過計算模塊給出的結果、識別出的異常信息，以及內置的專家智能服務來爲大家提供診斷優化的建議，同時會調用一些運維工具類處理的模塊，比如慢日誌分析模塊、延遲主備切換分析等等，以工具類的模塊進行輔助診斷，給到用戶非常精準的數據庫問題的診斷結果和對應分析以及優化定義。
在功能和輸出交互層面也提供了多終端的訪問，不僅僅是PC端的訪問，也提供了小程序、移動端、公衆號、訂閱號一體化的輸出，幫助用戶有各種各樣的體驗，在任何地方都可以享受數據庫自治服務帶來的紅利和便利。
3. 用戶級監控告警全鏈路
接下來和大家分享這幾年我們做了哪些工作，有了哪些沉澱積累。
數據庫自治服務首先關注的是故障，故障具體關注的是告警和監控，DBbrain 提供了宏觀用戶級別的監控和告警，讓用戶第一時間內能夠發現故障、發現異常，可以瞭解整個自己負責的所有數據庫的情況。
這部分採用的是二八原則，產品基本上爲80% 以上的”小白”設計，涵蓋80% 常見的數據庫異常問題和監控指標，所以門檻非常低。
監控頁面給用戶呈現出來的易讀性非常高，不需要從幾百個監控指標中找出哪個有問題，我們會幫助用戶篩選、聚合出相同問題觸發的監控指標。
最後是過程+結果的導向，DBbrain 的全景視圖是聯動的，所有都是結果導向，不僅僅讓用戶看得到實際上出現什麼問題，也可以在監控告警層面給大家展示故障發生過程中的變化，性能變更趨勢、其他指標變化趨勢等等。不僅是在結果側方面給出反饋，在過程方面也會給用戶清晰的呈現。
4. 7*24小時異常診斷
7x24 小時異常診斷，就相當於不間斷的 DBA 值班一樣，只不過是通過數據庫自治服務來提供。
在之前的專家時代、工具時代，沒有辦法做到 7x24 小時的異常診斷，主要有三個原因：
- 信息分析難
- 信息獲取難
- 性能優化難
數據庫自治服務可以幫助大家克服掉這三座大山，提供自治的閉環服務，幫助大家識別各種各樣的數據庫問題。這裏我們可以舉幾個例子：
比如在線教育行業由於疫情的原因，在晚上八點到十點會是一個業務高峯；而交易類、金融類的業務在早上和下午會是高峯，在某一個點可能會出現峯值，所以具備一個週期性的變化。
變更是指原來的業務變化是有規律的，但是突然有一天出現業務的變更，這很可能是業務進行了功能上的發佈或者調整。
通過這些特徵提取以及採集到的多維度秒級監控進行相互的配合，能夠幫助識別出每一類業務自有、特有的規律，使得在做歸因分析和自我優化過程中，可以屏蔽掉由於自身業務特性帶來的並非是故障的高峯點，幫助用戶識別“僞高峯”。
5. 異常框架診斷
數據庫自治服務診斷的框架分三部分 —— 假說生成、證據評分、決策計算。
在假說生成時，我們會把各種關係模型進行1-N個關聯，取到非常多的相關指標和異常，通過決策候選集的篩選，利用證據模型通過證據鏈進行篩選。最後通過決策支持度向量，進入決策計算模塊。
決策計算模塊會進行判斷，決策是否爲最優，如果不是最優會重新進行證據評分。
6. SQL 優化
相信 SQL 優化是絕大多數 DBA 或者研發同學都很感興趣的話題，也是大家用的最頻繁的功能之一。
DBbrain 提供的 SQL 優化，特點在於代價和成本。不僅提供索引的建議，還會提供語句的改寫和排序字段的選擇。
DBbrain 在索引分析方面考慮的更爲全面。比如在增加索引時，會考慮是否有冗餘索引，是否有現成的索引可以使用或者修改。其次在索引更新後，還會評估對於用戶已有的SQL是否會有影響，從而使得數據庫性能下降等？
此外像大家比較關注的 SQL模板聚合統計、耗時區間統計等多維度的信息統計，DBbrain也會提供相應的能力。
7. 基於cost的分析引擎
基於 cost 的分析引擎也是我們今年的重點之一。首先的出發點是增加用戶對於 DBbrain 提供的索引建議的可信度。
往往我們要判斷一個索引、一個優化建議好不好，最簡單的方法是理論上一定是可行的，二是實踐，如果加上去真的變快了，我們就認爲這個處理得好。如果加上去沒改變就不行。
但是通過基於 cost 的分析引擎，我們能夠在用戶沒有執行優化建議之前就把優化的結果告訴大家，從而在優化前就可以清楚的看到預期的優化效果。
cost 值不等同於耗時，減少的 cost 不能等比例的計算耗時。這裏我們會考慮三個方面：
- 在Server層中主要的開銷是計算符合條件的行的代價
- 在engine層中主要的開銷是從磁盤讀數據的代價
- 在Jion計算時不僅要考慮condition,還要考慮condition上的filter
我們會將這些綜合到 cost 引擎中，幫助用戶更好的在優化之前看到優化的預期效果。
8. 數據庫審計與分析
這個功能也是 DBbrain 提供的非常前沿的功能，也是非常實用的功能。
具體就是我們之前有些操作很可能是瞬間的操作，在回溯問題時發現不了；有些SQL由於記錄的原因記錄不全，導致分析問題時沒有參考。
通過SQL審計與分析服務，可以幫助用戶記錄所有在數據庫層面執行的 SQL，不僅僅是變更的操作，查詢操作也可以被記錄下來。可以理解爲類似於原生的 log。首先對性能消耗做了嚴格的測試，每條SQL執行完以後會進行審計規則的識別和過濾，將命中審計規則的 SQL 寫入到內存中，批量的進行刷盤，它的性能整體損耗在做壓縮以後，得出數據是低於5%。
各個廠商都在做審計類的服務，評測報告也是網上可以查詢到的，5% 的消耗是業內很領先的水平。
針對審計全量SQL能夠做的事非常多，能夠貢獻所有SQL任意時刻的快照以及執行的趨勢。很多時候一條SQL可能就執行十秒，但其中等了20秒，所以SQL執行時間很短，但是這條SQL結束的時間跨度非常長。對於這種SQL如果沒有全量時間的快照就很難發現這樣的問題，這幫助我們在排除疑難雜症的時候有更多的支持，能夠幫助我們把整個數據庫執行軌跡更加精確的梳理出來。
9. 數據庫健康評估策略解讀
除了精確到SQL層面的優化，數據庫自治服務在宏觀上對整個數據庫也有一套健康評估策略，主要通過五個方面進行評估，如下圖所示：
首先是可用性，可用性是指服務正常還是不正常。業務最明顯的感知就是業務是不是掛了，是不是可以正常的使用。
第二是數據可靠性。什麼情況下會影響數據可靠性？除了故障數據、丟數據、人爲的操作導致數據的不一致以外，有時候正常的業務邏輯中也會出現數據可靠性的問題。比如數據延遲增加，一旦出現故障如果主庫的數據無法找回、起不來，備庫的數據就會出現數據丟失的情況，很可能是由於binlog還沒有傳輸過去、或者主庫事務沒有結束的情況。
性能是指是不是存在慢SQL、是不是存在併發數導致 CPU 資源消耗過於明顯，是不是使用率非常高、發揮功能不足或者是 cache 比較低等等導致的性能問題，也是數據庫健康評估策略非常關注的一點。
還有就是隱患、超大表或者是表數量的不合理，沒有及時進行分步、分表，或者是採用分佈式底層存儲的架構，導致在做大量數據的排序查詢時性能會隨着數據量逐漸增大，聚合的消耗會越來越大，這也是隱患項。還有一個隱患是權限是否合理、是否有過多的授權，這些都會涉及到數據庫的隱患，我們也會在健康評估策略中特別的強調出來。
變化我們在7x24小時的異常診斷中提到過，業務趨勢的變更、突增、變化，與之前業務消耗和業務資源使用情況不一致的情況，我們都會識別出來告訴用戶，幫助大家不僅能夠掌握整個業務的使用情況，也可以對業務資源消耗畫像有所瞭解。通過健康評估報告，更能夠知道各種業務是否合理。
10. 時間序列模型Porphet在資源預測上的應用
剛剛我們提到，我們結合了一些算法進行了一些預測，預測模型是採用前幾年Facebook開源的Porphet算法，應用累加回歸的模型，通過時間、趨勢以及循環變更的規律來幫助業務預測資源的使用情況。
最簡單的是根據歷史使用趨勢預測磁盤使用量，能夠幫助用戶提早知道什麼時候該擴容、什麼時候縮容、什麼時候需要購買更多的設備、什麼時候需要清理數據，同樣也可以幫助用戶預測CPU、內存性能指標在後續趨勢中的變動，幫助用戶在大促前、一些活動之前、一些重要敏感操作之前，知道業務什麼時候是低峯、什麼時候需要拓展多少資源，這種預測模型對用戶和雲廠商有非常大的價值。
對於雲廠商而言，對於資源調度、資源的管理以及幫助用戶進行資源合理的分配，有非常大的價值。
對於客戶而言，雲上的資源評估、資源的管理工作，藉助預測模型可以預先啓動這些工作，不用每次都措手不及。想要擴容的時候馬上申請資源是來不及的，雖然雲上是彈性的伸縮，但是特殊情況下，比如出現大促的時候，電商客戶都在這一天發起擴容，很可能就會出現資源洪峯，用戶可能不能夠按時拿到想要的資源。
11. 自動性能優化系統 CDBTune
CDBTune 是一個新的前沿技術，去年我們在 SIGMOD 以論文的形式進行了發佈。產品化的過程也在進行逐步的完善。
大家都知道數據庫參數很多，那麼要如何調參？很多人表示網上有很多萬能模板，但到底適不適合你的業務，其實是不知道的，可能無法發揮數據庫最大的性能。
如果對這些參數進行手動調參，有經驗的DBA可能對其中的某些參數有自己的經驗，但對於各種不同特徵業務或者不斷變更的業務，CDBTune 就可以幫助很好的解決這個問題。
我們可以通過深度學習算法通過自調優的方式，得到與自身業務相匹配的參數配置。調優的時間也比其他的要快，調優的結果經過測試，已經達到了很高的水平。
12. 容易被忽略的數據庫安全防護
絕大多數的數據庫運維對於這部分的內容要不然是接觸的很少，要不然就是會被忽略掉。大部分的數據庫運維往往認爲只要保證業務不出性能問題、不出故障就可以，但很少會關注數據庫的安全防護。
數據庫自治服務作爲一個全方位的服務，必然要在大家忽略或者沒有關注到的地方提供相應的價值，這樣才能爲客戶更好的提供數據庫的穩定性和安全性。
這裏我們主要提供了三個功能：
- 合規審計：提供符合國家等保要求的安全審計，對企業網絡中的數據庫各類會話信息、訪問操作、SQL 語句進行安全審計，可挖掘數據庫運行過程中各類潛在風險和隱患，爲數據庫安全運行保駕護航。
- 安全治理：可對數據資產、數據內容、訪問信息進行中心化管理。並依託先進的 AI 引擎與敏感數據發現算法， 將針對企業核心數據的異常操作進行篩選告警，實現企業數據保護。
- 數據脫敏：以處理數據庫文件的方式，對數據庫中敏感數據進行在線屏蔽、變形、字符替換、隨機替換等脫敏操作，達到企業核心數據保密效果。
三、DBbrain行業典型案例分享
下面我們結合一個行業用戶的案例，來給大家進一步分享數據庫自治在實際的生產過程中如何應用。
電商大促大家都不陌生，騰訊雲自身也支撐了非常多的大規模電商。那麼電商在每次的大促過程中，如何利用數據庫的自治服務，來保障自身的數據庫安全？
在備戰階段需要進行故障梳理、資源評估等工作，在沒有數據庫自治之前，這些工作都必須由DBA來進行。一旦在某個環節出現了問題，或者業務出現了問題，往往DBA就變成了“背鍋俠”，總能找出DBA的問題。
而使用數據庫自治服務就可以有效解決上述問題。
1. 數據庫巡檢，評估風險
首先，我們可以通過數據庫巡檢全量的實例，評估相應的風險。因爲電商行業的實例很多，如果讓DBA手動巡檢，工作量是非常巨大的，所以常規DBA會進行核心實例的巡檢，或者只對經常出故障的實例進行巡檢，但這樣就會有很多潛藏的風險。所以全量巡檢、多維度巡檢是非常必要的。
爲什麼說在這個地方可以發現問題？因爲在備戰階段業務側一般會封網，一旦封網，業務邏輯不到必要的bug修復時是不會調整的。所以在封網後進行全量巡檢、排查問題，只要修復了那麼在之後大促的過程中，就可以儘可能的減少問題。
數據庫自治的巡檢報告，包含從基本信息到資源狀況、任務狀態的巡檢，以及日常的訪問行爲等非常全面的信息。
熱點訪問是非常關鍵的，很可能業務沒有出問題，但冷熱數據一旦沒有進行區分，那麼在併發量高的情況下一定會出問題。所以我們可以在用戶封網後提供全鏈路的檢查。
2. 助力業務優化改造
在排查之後，我們還需要助力客戶進行業務的優化。如圖所示，我們把優化大致分爲五層。
其中，SQL優化是大家非常容易上手、操作起來非常方便的一個優化，比如索引優化、改寫優化等。其次還有更深入的配置優化、數據優化、架構優化和業務優化等。
之所以排爲1-5，是因爲在第一層的優化中，業務的配合度會比較高、改動比較小，隨着逐漸深入，可能就需要業務側更改代碼邏輯。我們會根據業務不同的需求提供相應的優化建議。
3. 業務場景的故障自愈
最後，我們發現還有一些問題。比如大促中臨時的變更發佈，導致因爲數據庫層面沒有相應的應對措施，數據庫被擊穿或者壓力很大。還有可能是低質量的SQL，在壓力和數據量激增的情況下數據庫出現問題。
面對這種情況，傳統的方法一般是直接kill掉對話，持續kill或者定時kill進行降級。如果無法降級則進行重啓或者HA切換，或者進行業務側的應用回滾或者臨時降級，但相對來說實踐起來比較困難。
數據庫資質DBbrain在這個時候就可以發揮作用。首先7x24小異常診斷與優化，可以在還未發生問題時就發現隱患，並提出優質的解決方案。此外，還提供了高併發場景的解決方案，並且可以自動持續的kill掉阻塞的SQL。
4. 高併發場景解決方案
剛纔我們提到，DBbrain在高併發場景提供了數據庫性能優化以及降級止損的解決方案。方案具體有三項：
（1）熱點更新保護
在高併發場景中，經常出現對同一行數據的更新，在沒有緩存的情況下，都會打到底層的數據庫。爲了保護和減小開銷，針對語句的排隊機制，儘可能把具有相同衝突的語句放在內存隊列排隊，通過開啓熱點更新保護來減少鎖衝突的開銷，提高高併發場景的數據庫性能。
（2）SQL限流
顧名思義，就是幫助用戶進行業務降級。限流的操作類似於改寫，但技術方案不同。可以通過創建 SQL 限流任務，自主設置 SQL 類型、最大併發數、限流時間、SQL 關鍵詞，來控制數據庫的請求訪問量和 SQL 併發量，進而達到服務的可用性，不同的任務之間不會發生衝突。
（3）空閒事務自結束
自動結束(Kill)空閒事務，避免大事務未提交導致大量資源爭搶。會自動識別開啓的事務，如果開啓事務後在一定時間內沒有進行提交，會自動結束該事務。
四、數據庫自治的未來展望
數據庫自治在未來應該會朝着自愈、自優化的方向發展，不僅能自主調節索引建議，還可以自主創建索引，自動進行識別、添加和刪除。
並且在未來還應該可以自動對執行計劃進行迴歸修正，優化策略下沉與引擎融合，讓用戶需要干預的越來越少，提供的優化服務越來越多。
最後是能夠自動識別並殺掉失控SQL，並阻止進行至優化完成，幫助數據庫層面做更多業務層面的代碼實現。
這些都是未來將要實現的功能，或者是數據庫自治在未來能讓大家看到的迭代或者技術點。
Q&A
Q：數據庫審計功能很重要，特別現在等保也有要求。騰訊雲數據庫審計的功能是通過旁路審計，還是從proxy節點抽取日誌？
A： 騰訊雲數據庫的審計，是在內核層面實現的，並不像其他的審計功能需要外掛Agent，或者在接入機上安裝採集的進程實現。
騰訊雲的數據庫審計，是在連接release之前，在語句提交之後進行規則匹配，如果命中規則便將內容轉變成json，拷貝成審計的內容發回，批量進行Flush刷盤，最後存儲到列式存儲中，提供用戶的查詢，並且爲數據庫審計提供數據源。
在這個階段，如果在return和連接release中間，審計規則配的比較複雜或者比較多，就可能會出現性能損耗，但這個損耗是非常低的，在5%以內。
騰訊雲數據庫的審計功能，與市面上其他審計相比的優勢點在於，是通過內核側實現，不需要再從旁路進行Agent審計，這樣一是可以避免漏審，二是旁路審計抓到的只是SQL包，抓包解析有可能有些信息抓不到，而騰訊雲數據庫自治的審計除了常規內容之外，還能抓到SQL執行的一些相關信息，比如影響行數、掃描行數等。
Q：數據庫走向自治後，DBA的工作內容有什麼變化？
A： 比如性能調優，故障恢復監控、帳號管理、實現高可用、數據備份部署、架構選型等，在數據庫實現自治後，類似這些的重複、簡單的工作都可以被協助實現。而DBA更多的會傾向於更有價值的、與業務側結合更緊密的工作，類似於數據庫架構師、業務架構師的工作。
Q：數據庫的服務降級有哪些表現形式？
A： 數據庫降級服務主要有幾種方式實現。比如SQL限流，用戶最直觀的感受是當SQL超過了數據庫的承載量後，會被拒絕，在日誌中會看到一個自定義的錯誤反饋。因爲SQL限流是在語義解析器之後、優化器之前進行識別，當併發度超過我們設置的每秒併發，並且特徵相符，就可以在進入優化器前進行攔截。另一種降級可以通過賬號和權限來限制；還有一種也可以通過DBbrain“實時會話”中提供的持續kill來實現。
Q：DBbrain是否在SQL優化方面提供SQL優化預估的時間消耗？並且在提供索引建議的同時，提供一個按鈕點擊即可通過onlineddl手動建索引？
A： DBbrain現在給出的是cost分析。選擇cost分析的原因，是因爲cost更能體現出SQL在計算開銷、內存開銷、磁盤讀取數據開銷的代價特徵，而時間往往是不準確的。比如在一個很空閒的系統中，執行一些比較費時的操作，時間往往很快，但一旦數據量突增、系統環境發生變化後，同樣SQL的時間會變長很多，甚至是從量變到質變。而cost分析，哪怕是十行的數據沒有加索引都可以識別出來，就會減少只通過時間分析導致的誤判和影響。
對於提供點擊的onlineddl手動創建索引功能，應該會在後續提供給大家，也是後續比較重要的一項功能，幫助完成從發現問題、定位問題、優化問題到最後執行，這樣一個全鏈路的優化閉環。
本文轉載自公衆號雲加社區（ID：QcloudCommunity）。
原文鏈接：