7月19日，話題“微軟藍屏”沖上了熱搜榜第一。微軟公司旗下部分應用和服務出現訪問延遲、功能不全或無法訪問問題，大量用戶端電腦出現藍屏現象。這個技術故障席卷全球，短短兩個小時，就造成一場令人措手不及的大規模事件：多個國家和地區航班停飛，醫療、銀行、酒店等行業“停擺”，連倫敦股票交易所都受到波及……微軟很快就查明事故的根因并及時處理，此次故障與一家與微軟有關聯的全球安全公司CrowdStrike有關，因為推送了一個“更新”，卻觸發了某些Windows的bug導致了系統藍屏。
重視代碼質量，不斷優化質量控制機制，才能保證系統的安全性和穩定性。數據庫層面如果出現這種失誤也必將會造成巨大影響，那么該如何避免呢？
功能上線前SQL質量把控的必要性
在功能上線前，開發者通常需要進行SQL變更。這些SQL語句，在上線前很難識別是否存在潛在的坑和性能問題，發布后一旦出現錯誤，可能會導致數據丟失、性能下降甚至系統崩潰，對業務產生嚴重影響。因此在上線前進行SQL審核是非常有必要的，下面我們通過一個簡單的例子來詳細說明。
表結構和業務代碼簡化如下：
create table user_login_history (
`user_id` varchar(32) NOT NULL PRIMARY KEY COMMENT '用戶id',
`login_time` int(11) NOT NULL DEFAULT 0 COMMENT '登錄時間',
`login_status` varchar(32) NOT NULL DEFAULT '' COMMENT '登錄狀態：success|failed',
`failure_reason` VARCHAR(255) DEFAULT '' COMMENT '登錄失敗原因'
);業務代碼中涉及到如下相關SQL語句：
// 插入登錄歷史
stmt, err :=conn.Prepare("insert into user_login_history values(?,?,?,?)")
if err != nil {
log.Logger.Errorf("prepare sql failed")
return err
}
// 定期清理歷史表
sql := fmt.Sprintf("delete from user_login_history where
login_time<unix_timestamp(now())-%d limit 100"， timeBefore)
for {
_, err := conn.Exec(sql)
if err != nil {
log.Logger.Errorf("DelLogInHistory exec sql failed, sql:%s, err:%v", sql, err)
}
time.Sleep(10 * time.Second)
}上面SQL存在哪些問題？
從上面的代碼中可以看到有以下兩個問題：
1）代碼中插入user_login_history表沒有指定列名，新功能版本需要對該表進行新增字段，采用以下兩種發布方式，會出現什么結果？
很多小伙伴是不是也會選擇方式一進行發布，如果你真這么做了，那么一次故障review少不了。從執行新增字段SQL開始，滾動升級這段時間，老版本服務insert into user_login_history將會失敗（由于新增的字段老版本服務代碼中沒有指明對應的value，字段個數對不上）。
選擇方式二的小伙伴也許曾經踩到過類似坑吧，第一次服務滾動發布修復insert表未指定列問題，第二次服務滾動發布進行新功能發布。
2）歷史表數據量一般都比較大，需要定期按照時間進行清理。從上面代碼看user_login_history的login_time字段未添加索引，如果該表數據量增長迅猛或清理任務堆積，那么也會存在問題。
清理任務涉及的login_time字段沒加索引全表掃描，導致磁盤IO異常，從而會影響業務穩定性。
為什么會出現這么低級的問題呢？
對于開發同學來說，由于日常開發任務緊，一些類似insert不指定列的問題沒有足夠重視，先完成功能（不指定字段代碼寫起來比較省事），往往就會引入此類問題。不加索引導致故障的問題數不勝數，剛開始業務量比較小，表中數據不多，就算沒索引也不會存在問題，缺乏對業務未來的評估。
通過這個例子也能看出依賴人工進行SQL審核和代碼Review并不能完全識別出潛在問題。比如以下場景：
人工Review的方式不靠譜，那么有沒有好的工具能識別出類似上述問題呢？
DBdoctor自動批量SQL審核（規范審核+性能審核）防止“藍屏事件”發生
行業內SQL審核的工具比較多，但大多數都聚焦在規范審核上，缺少針對SQL性能的審核。近期DBdoctor發布了批量性能審核的功能，開發人員可以快速發現并解決SQL語句中的各種問題，大大提升SQL質量和系統的穩定性。
如何用DBdoctor進行批量SQL審核
1.上傳DDL文件
將此次版本涉及到的DDL文件上傳。
2.查看任務詳情
任務詳情中分別展示每條SQL的審核結果。
3.查看審核詳情
審核結果中對性能審核結果和規則審核結果分別展示。
4.同樣的步驟審核DML文件
可以看到插入語句未顯示指定列名插入，當表中存在1000條數據時，加上索引性能提升543倍，并提示出添加索引的SQL語句。
結語
在當今數字化的時代，數據庫的穩定和高效運行對于各行各業來說都是至關重要的。SQL語句作為數據庫操作的基石，其質量和性能直接關系到整個系統的穩定性和安全性。然而，面對海量SQL語句的審核需求，傳統的人工審核方式早就不能滿足效率及準確率的需求。DBdoctor作為一個先進的數據庫性能診斷和優化平臺，提供的批量SQL審核功能，可幫助開發者和數據庫管理員在多場景下對SQL語句進行高效、準確的審核，有效避免潛在事故的發生！
DBdoctor介紹
DBdoctor是一款企業級數據庫監控、巡檢、性能診斷、SQL審核與優化平臺，致力于解決一切數據庫性能問題。采用eBPF技術可對數據庫做細粒度的掃描，幫助您一分鐘內找到數據庫性能問題，實現性能診斷百倍提效。針對數據庫性能診斷門檻高、耗時長的問題，DBdoctor提供了快速易用的解決方案，深入到數據庫內核，提供精準的診斷分析和優化建議。基于內核Cost精確評估技術，可以在SQL上線前審核性能問題，并給出優化建議，提前規避故障發生。
關注【DBdoctor】公眾號了解更多信息！
從昨天開始，全球范圍內的Windows系統的 電腦，出現了大范圍的藍屏死機問題！目前已經確認的是，這個全球性的電腦藍屏的元兇就是CrowdStrike 。CrowdStrike 是一家領先的網絡安全技術提供商，為終端、云工作負載、身份和數據提供安全服務。CrowdStrike 深受 298 家財富 500 強企業、美國 43 個州、6 家排名前 10 的醫療保健提供商和 8 家排名前 10 的金融服務公司的信賴，是業內的佼佼者。其 Falcon 平臺是一種統一的、云交付的安全解決方案，旨在防止所有類型的攻擊，包括惡意軟件等。然而， Windows 上Falcon Sensor代理的最新更新引發了一個嚴重問題：藍屏死機 (BSOD) 啟動循環導致受影響的系統無法使用。這一普遍存在的問題擾亂了各個行業的運營，尤其影響了航空公司、銀行和醫療保健提供商。
CrowdStrike 已確認該問題并停止進一步部署錯誤更新。向用戶發送的警報確認他們知道與 Falcon Sensor 相關的 Windows 主機崩潰，特別是錯誤檢查/藍屏錯誤。不幸的是，恢復陷入 BSOD 啟動循環的 Windows PC 的官方解決方案仍然難以捉摸。有幾種解決方法可以解決此問題，請閱讀下文。
Windows PC 上 CrowdStrike BSOD 問題的官方解決方法：
另一種方法是使用以下任一方法阻止 CrowdStrike 啟動：
方法 1：
方法 2：
如果您在 AWS EC2 實例上運行 Windows，則可以嘗試以下方法：
上述方法也適用于在 Google Cloud Platform 上運行的 Windows 實例。