資料庫之淚第五章節

前幾天正在群裡談及一些技術問題，接到有人求助請看看MySQL資料庫。連上去看看，大量的表鎖。其實一般來說我們OLTP資料庫都是行鎖的。如果動不動就表鎖了，這活沒法幹了。但是鎖這種在不同資料庫不同場景下處理還不一樣，比如MySQL在預設的RR下，沒有索引或者沒用到索引的DML就是表鎖。這種是不懂或者不瞭解資料庫的人會無意中犯下的錯誤。

   曾經在一個群裡看到有人問，大家MySQL事務隔離級別用的是什麼？有一個人說了句RR。我接了一句：“RR”厲害了。然後一堆人複製我的話。群主問RR厲害在哪裡？我就說了“MySQL在預設的RR下，沒有索引或者沒用到索引的DML就是表鎖。” 群主覺得這是開發的基本素質。沒這樣做的還要留著嗎？ 哎，其實吧。這種在國內是普遍現象。

    不僅僅是這種沒意識的。還有的就是有意識的犯錯誤。

    故意1：有個附件表，每天改，有的有附件，有的沒附件。不知道怎麼搞的就是總是錯了。於是乎每天凌晨定時清空所有，然後一個個對一下，一個個去更新。諸位看看，是不是要是控制的好點，不至於這麼費勁吧？就這一個動作比系統一天其他總的產生的歸檔日誌都多。也就是說一天主要的壓力不是業務，而是刷這個表。

   故意2：全量insert一個表，但是第二天要把這個表全部刪除，再重新insert進去。因為不知道哪些變了？（常見於不知道上游什麼變化了，或者不想知道，只想偷懶）所以越來越慢。

   故意3：ETL全量拿取資料。在上游表結構變化後或者上游刪除資料後再或者在上游變了但是下游實在不知道的情況下，定期全量。

   對於故意2和故意3來說，其實想想資料庫的全量備份和增量備份就知道了。為什麼要有增量備份？就是為了在保障資料一致的前提下，代價最小化。

   故意4:上游強大，不告訴變化。下游被動接受全量，然後自己比較差異。這種是實屬無奈，屬於管理問題。系統對接，上游不管下游死活。與故意2不同，故意2是以後者為準。

   故意5:下游強大，懶得做變化判斷。主動全量拿上游，然後自己比較差異。這種是無知。系統對接，下游不管上游死活。使勁拿資料，上游被消耗盡了也不管。與故意3不同的是，這種只拿固定的1-2個表。

   故意6：每小時拿前一個月的資料（精確到秒），雖然不是全量。但是每次拿的資料99%以上甚至100%都是無用功。

   以上我一定沒有窮舉出所有場景，能力有限，經歷有限。但是我相信一定還會有其他的，只是我沒見過。對於故意的來說，基本出發點就是一個字：懶（除了故意4，這是上游懶）。系統穩定不穩定不是開發的責任。（畫外音在大廠不是這樣定義的，應用開發寫的不好，就是開發的問題。）