資料庫之淚第二章節

      書接上回。今天講述的是一些誤解。

      誤解1：空間不足刪除資料。

      假如有100萬資料，佔空間10G。現在刪除50萬資料（delete from這樣），佔空間幾何？（假設資料每行資料大小大致相等） 非資料庫人員認為是5G,包括很多開發人員也這樣認為。一般來說OLTP資料庫來說，還是10G。因為delete了資料，空間上留下了空的行，但是並沒有進行收縮。這個原理今天不展開了。 所以大部分開發會在應用程式中樂此不疲的使用delete，滿以為這樣做，能刪除資料，表不會很大。其實然並卵。

     我有一次幫別人處理問題，就遇到他們每次都是全表刪除，自以為表不大。但是就是這樣只有幾條的表，卻有幾十個G。每次執行都很慢。我給他處理了一下，原來2200秒的，現在0.2秒了。我順帶說這樣對磁碟不好啊。他說你怎麼知道的？上個月剛壞了一塊硬碟。壞了一塊硬碟。壞了一塊硬碟。（本來就不能這樣幹，沒用）

    誤解2：連線數越多越好。有一次安裝一個測試環境，開發說連線數不夠。我說100多還不夠嗎？開發說別人我10萬個連線。

    其實每個連線都要佔用資料庫資源，每個資料庫不一樣，我們通常來說差不多平均也要5M，也就是說1000個連線，什麼都不做，就靜靜的連著，5個G就沒有了。關鍵還不幹活。好像覺得連線數多了可以並行處理，其實絕大多數情況下，我只看到幾個連線是活動的。當達到幾十個的時候，基本資料庫也就告別“腳踏車了”。（除非是像一體機這樣的神獸）。一般物理機連線數幾百還能抗，但是已經很卡或者不能用了。虛擬機器的十幾個活動會話已經卡的不能用了。因為這個時候如果去看CPU和IO，基本是CPU滿負荷，硬碟嗷嗷叫。連線數設定1萬，就像吾皇萬歲萬萬歲一樣，沒見過哪個真到這樣的（一體機除外）。中原王朝最長壽命的乾隆88歲。

   結果很多資料庫應用連線數過高（本質還是SQL寫的太差），導致資源耗盡而死。

    誤解3：表越大越慢。經常有人說MySQL超過1000w效能急劇下降。當然也有說其他資料庫也是超過多少就很慢。說這話的一定是%%去查的。因為這樣的確幾千萬逐行掃描是慢。這個只能說暴露了SQL寫的差，其他說明不了什麼。當然也有說需求如此，那隻能說是管理水平差，其他也說明不了什麼。我記得有一次DTCC大會有人問，周彥偉（我國第一個MySQL方向的ACED）1000萬的表查詢很慢怎麼辦？周總說，看看索引吧。其實當今的資料庫和硬體，只要SQL用到索引，並且結合分頁等。都是很快的，如果是點查都是幾毫秒甚至不到1毫秒可以完成（和redis沒差多少）。

   誤解4：單機不遵守開發規範，效能極差，鎖都不知道怎麼鎖的。寄希望於上分散式資料庫解決這些問題。

   其實分散式資料庫是單機的延伸，也要遵守資料庫開發規範，甚至比單機的還要多。如果單機的鎖都搞不明白是怎麼回事，那麼分散式資料庫的鎖，只能是讓情況變得雪上加霜。當然分散式還是好的，至少還是一個體系能保證資料一致性。沒有分散式資料庫直接來分不分表。最終一致性沒有保障的前提下，發現做的越多錯的越多。最好查問題都不知道怎麼下手。總算知道問題了，但是無法解決。因為一切歸於分庫無法利用資料庫鎖，而鎖在單機時候就沒搞明白，覺得鎖不好。熟不知，沒有鎖更不好。

未完待續。