最近云界发生了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 问题。