在
談這倆概念前、先來說說 大i/o vs. 小i/o
通常、我們把<=16kb的i/o認為是小i/o、而>=32kb的i/o認為是大i/o
了解i/o的大小、影響到後期對快取、raid型別、lun的一些屬性的調優
當前大多數資料庫使用的都是傳統的機械磁碟
因此、整個系統設計要盡可能順序i/o
避免昂貴的尋道時間和旋轉延遲的開銷
隨機小i/o消耗比順序大i/o更多的處理資源
隨機小i/o更在意系統處理i/o的數量、即iops、比如、oltp
而順序大i/o則更在意頻寬、即mb/s、比如、olap
因此、如果系統承載了多種不同的應用
必須了解它們各自的需求、是對iops有要求、還是對頻寬有要求
傳統機械磁碟最大的問題在於讀寫磁頭
讀寫磁頭的存在可以讓磁碟既能順序i/o、也可隨機i/o
但是、隨機i/o需要花費昂貴的磁頭旋轉和定位來查詢
因此、順序io訪問的速度遠遠快於隨機io
資料庫的很多設計也都是盡量充分利用順序io、比如oracle redo log寫便是順序io
如果、資料庫伺服器同時使用順序和隨機i/o、隨機i/o從快取中受益最多
原因有 3 ：
① 順序i/o一般只需掃瞄一次資料、所以、快取對它用處不大
② 順序i/o比隨機i/o快
③ 隨機i/o通常只要查詢特定的行、但i/o的粒度是頁級的、其中大部分是浪費的
而、順序i/o所讀取的資料、通常發生在想要的資料塊上的所有行
更加符合成本效益
所以、快取隨機i/o可以節省更多的workload
傳統的資料庫架構對隨機io幾乎沒有還手之力、隨機io幾乎令所有dba談虎色變
而聰明如mysql innodb 則利用事務日誌把隨機i/o轉成順序i/o
竊以為、如果能負擔得起、增加記憶體是解決隨機i/o最好的辦法
**：
從應用層面來實現資料庫負載均衡
從應用層面來實現資料庫負載均衡 問題的由來 以前維護的系統經常宕機，究其原因是開發管理不善，造成程式質量不佳。撇開制度管理的原因不談 那是技術人員無法解決的 其表象原因有二 一 授權程式設計不佳，造成整個系統執行緩慢 二 有很多程式中有幾個大表的join語句，只要這種程式多跑幾個，管你是什麼ibm小...
從資料庫獲取 10 條隨機資料
sql server select top 10 from t user order by newid oracle select from select from t user order by dbms random.random where ronum 10 mysql 從 mysql 隨機選...
資料庫如何抵抗隨機IO的問題 方法與現實
1996年，p o neil等提出的 lsm tree 是乙個重大 突 破。lsm tree主要有兩種變形，最簡單的lsm tree，是乙個記憶體中的小索引加上外存中的大索引，更新先快取在小索引中，再批量更新到大索引，這樣就有望合併對屬性同一頁面的多次更新的io。複雜的lsm tree，是劃分為多個...