SQL血的教訓

 
1.    每次查詢的數據要有限制
     2013年1月  產品獨立數據庫，因爲多條SQL每次查詢數據超過幾千條，有些超過10萬條數據未分頁，形成應用服務器CPU有時持續100%。

2.    禁止循環調用SQL

    2011年5月  程序調用Sys_User查詢，每分鐘執行超過3千次，形成服務器CPU持續100%

3.    禁止使用遞歸方法調用SQL；

    方法內如出現數據異常，極易形成查詢死循環

4.    禁止每次寫入大量數據
    2011年7月  深圳庫導入訂單的存儲過程當中加入一條insert語句，每次insert超過100萬條，幾個小時將深圳數據庫服務器磁盤寫滿，業務沒法運行

5.    禁止在事務中使用循環加入緩存；
    2011年4月  批量更新Sys_user用戶後，又在事務裏循環加入緩存，形成事務運行太長，嚴重影響系統性能。

6.    必須在語句的具體字段要明確列出

  2011年3月  查詢Product表數據，每次查詢出所有字段，包括不須要的產品詳細描述信息，形成系統網卡流量暴高。

7.    禁止使用業務邏輯大的事務
    2011年4月開始，前臺客戶最長等待須要超過30S完成下單，查詢發現下單整個操做包在一個巨大的事務中，嚴重影響客戶下單。

8.    禁止使用SQL遊標Cursor；
    遊標使用不當，會嚴重影響系統性能
9.    Select查詢放到事務外

    2011年6月  某條insert語句很慢，檢查發現取表的Sequence語句放在insert的事務裏，在高併發下，失敗率很高。

10  禁止一次刪除大量數據
     2012年11月  Customer_LoginLog表因爲前臺寫入暴增，形成當天數據超過1500萬條，SQL歸檔執行了6個小時未刪除完，影響業務操做超過6個小時。

 11，禁止主鍵刪除再新建

    2016年，Coupon表數據，有1億多條數據，查看其主鍵有大量碎片，當時不想用online的方式重建，仍是想先刪除，後建立。由於當時是早上4點多，開發人員說基本沒人使用，

 就沒有影響，就先刪除主鍵，結果刪除後，沒想到系統有大量查詢coupon的請求，而主鍵沒有，數據庫運行很慢，kill後一直有，後來沒辦法，禁用這個連coupon表的帳戶，等主鍵建立

成功後，再啓用帳戶

12，禁止用系統登陸觸發器

   2017年9月，由於黑客攻擊，想在數據庫作個監控，對凌晨1-7點間登陸數據庫的作個監控，用了SQL Server的系統登陸觸發器，記錄登陸信息，結果觸發器先建好，記錄信息的表沒有建，致使

 登陸觸發器審計失敗，這個失敗致使，其餘用戶登陸時也會觸發這個系統登陸觸發器，也報登陸失敗，登陸不了，本身試了其餘4臺備機，也都登陸不了，前臺，後臺和wms程序所有報錯，查了

網上資料也沒找到合適的方法，程序一直在報錯，這時忽然發現，已經登陸同步實時從庫（8.10），雖然不能登陸，可是他已經登陸了，這時我看，可使用，我這時馬上刪除剛建的觸發器，執行

AlwaysON切換，把數據庫從主庫切到實時備庫。

   經歷了20多分鐘的重大事故終於解決。過後發現有2個解決辦法，1，備份master庫，出現異常時還原master庫   2，CMD最小化登陸數據庫刪除觸發器

   我這邊發現就是還有一個登陸好的實時備庫，進去刪除。

   由於這20多分鐘經歷太痛苦，一直不想去模擬2種處理方案，由於後續也不會用登陸系統觸發器。