阿里雲 RDS 數據庫又發 CPU 近 100% 的「芯髒病」

最近雲界發生了2件事，一件是大事，一件是小事，大事是阿里雲與微軟合做推出了開放應用模型 Open Application Model(OAM)，小事是因爲微軟 SQL Server 在阿里雲上水土不服（僅是咱們的猜想），阿里雲 SQL Server RDS 患上了間隙性芯髒病，該病容易在夜間酣睡的時候發病，目前惟一的急救藥是「主備切換」。

對於大事，咱們拍手叫好，雲廠商綁定的問題正在被逐步解決。對於小事，咱們提心吊膽，阿里雲你可要保重龍體啊，你打個噴嚏，咱們都抖三抖，你要是生個小病，咱們怎麼活。

在此以前，最近咱們已經遭遇了3次阿里雲 RDS 芯髒病發做，詳見 雲上的芯髒病：奇怪的阿里雲 RDS 數據庫突發 CPU 近 100% 問題。昨天 23:50 左右開始，RDS 芯髒病又發做了，又是發生在數據庫服務器負載極低的時候，又是經過急救藥「主備切換」恢復了正常。

很是抱歉，阿里雲 RDS 芯髒病問題引起的故障再次給您帶來麻煩，請您諒解。

對於這個問題，咱們會繼續觀察並考慮如下的應對方法：

1）向阿里雲提交工單，催促阿里雲重視這個問題。

2）用阿里雲 ECS 自建 SQL Server 數據庫服務器。

3）評估其餘雲廠商的雲數據庫服務，若是在阿里雲上實在沒法解決，換一片雲試試。

請你們理解咱們的小題大作，雲已經變得愈來愈重，已經成爲不少企業的命脈，對於雲上的問題「小題大作」總比「大題小作」好。

【更新】

11:40 更新：阿里雲針對咱們遇到的數據庫 CPU 100% 問題進行分析，分析出來的緣由是「出現了緩存的執⾏計劃被替換，一樣的⼀批SQL執⾏成本⼤幅提⾼（參數嗅探問題）致使的CPU 100%」，並且定位出了具體的嫌疑 SQL 語句，是 EF Core 3.0 生成的獲取上一篇/下一篇博文的 SQL 語句。咱們會改進對應的 LINQ 代碼，並進行驗證。

17:02 更新：因爲 EF Core 3.0 知名的 null checks 問題（詳見 github 上的 Queries really slow due to null checks），EF Core 生成的嫌疑 SQL 語句超長，每一個查詢條件都會加上  IS NOT NULL ，生成是 UNION 查詢，整個 SQL 語句一共有 3895 個字符。

21:07 更新：將 EF Core 生成的嫌疑 SQL 語句改成 Dapper + 存儲過程。另外，更新了 SQL Server 的統計信息。

11月23日 11:39 更新：咱們向微軟 .NET 團隊反饋 EF Core 的 null checks 問題後，微軟很快發佈一個部分修復問題的 fix 版 EF Core 3.1.0-preview2.19522.3 （flags枚舉類型依然有這個問題），詳見 github issue 中的回覆，對應的 PR#18491 。

10月26日 9:14 更新：微軟昨天進一步修復了 flags 枚舉類型的 null checks 問題，詳見 PR#18491 ，但包含這個修復的 nuget 包還沒發佈。

11月4日 21:56 更新：確認 EF Core to 3.1.0-preview3.19553.1 已修復了 null checks 問題。