怎麼設定資料庫的報警

  報警分為幾種（結合我各行各業的工作經驗）：

1、無報警（這裡主要說是資料庫已經不行了，但是報警沒有提示。因為設定90%報警，且要持續5分鐘，現在是80%，持續了幾個小時。）

2、使用者操作出現問題（同時我們系統也發現問題）和使用者同時發現。比如使用者點選頁面1秒 2秒 3秒 。。。10秒沒出，報502 503等50X 等等.  這個時候我們後臺也會報警。這種要先於使用者不現實。他沒操作之前，這個不知道他點下去是不是超時。

3、在使用者操作之後，比如報警提示，鎖持續1分鐘（3分鐘、5分鐘），估計投訴電話都打過來了。

4、還有一種是監控比較難以察覺的，比如主從資料庫同步有延遲，或者異構資料庫透過CDC同步有延遲。其實延遲不是說一旦延遲就是問題，但是延遲大了一定是問題。這個尺度不好拿捏。比如延遲10秒，可能沒事，但是恰好有個系統居然那一個時刻就不能延遲。

5、關係型資料庫到NoSQL或者到訊息佇列的不一致性（我覺得天生這種就不可能保障一致性，基本無解）

以上個人水平有限列了一些主要的，一定有其他的。我們先討論這些主要的。

      針對問題1：其實資料庫的CPU超過50%的使用率，就開始出現有些請求等待了。有一次在一個技術大會上Oracle的RWP給我們演示了一次壓力測試。所以這也是我對各種資料庫上的要求，不能是常規的報警界限。

      針對問題2：這種可能我們不能100%避免，但是能做的是在上線前，SQL稽核以及壓測。如果我們的主流程或者說高頻訪問的SQL，都控制在50ms、20ms甚至幾毫秒、微秒級別。那麼是可以預防的。一切皆有可能。有一次我就是把一個SQL從20分鐘最佳化到了不到2毫秒。（你要問怎麼做到的，報名上我的課吧）

      針對問題3：設計上避免長事務鎖甚至設計不要鎖的場景。比如update 業務單一ID，基本不會鎖（除非故意不提交），還有拍賣設計成insert出價，而不是update價格。

      針對問題4：禁止大事務。任何CDC都怕大事務。別說CDC怕了，就是主從資料庫也怕。我經歷過多次這樣導致資料庫主從斷了的情況。不怪資料庫。話說能不能CDC（資料同步）就不用。

      針對問題5：好好設計表，好好寫SQL。減少資料庫數量和異構資料庫以及中介軟體。（當真正經歷過就會發現，單套資料庫的開發和運維真的是最幸福的事情了）

      總結一下，會發現好好寫SQL，解決了以上所有問題。然後你的資料庫真的基本就沒有報警了。