?

偶然看到了“Fotolog: Scaling the World\'s Largest Photo Blogging Community”，才發現很多數據庫的優化其實道理都很簡單，至高境界是當你面對問題時，是否真正做出了自己的思考，而不僅僅只是經驗主義的慣性使然： 本文案例背景介紹：一個圖片網站，每張圖片都有很多評論。瀏覽時會執行：SELECT ... FROM ... WHERE photo_identifier = ... ORDER BY posted ... 在“Old Schema”的解決方案中，一切都顯得中規中矩：使用了最常見的自增字段identifier作為主鍵，同時使用photo_identifier, posted作為索引。 數據按照主鍵進行排序，當執行查詢時，根據索引進行數據對位。不過這里的問題在于，同一個圖片的評論數據，在磁盤上會分散到多個數據頁之上。這也就意味著在查詢這些數據的時候，磁盤要不斷的調整數據定位。這是一個不小的IO開銷。 在“New Schema”的解決方案中，雖然也使用了自增字段，但是采用的是聯合主鍵photo_identifier, posted,identifier，并把identifier作為索引。同時需要注意的是，表類型使用的是Innodb，并縮減了自增字段的長度，這 樣，主鍵的長度會短一些，有助于提升Innodb的性能。 數據按照聯合主鍵進行排序，由于photo_identifier字段是聯合主鍵中的第一個字段，所以對于一張圖片而言，它所有的評論都保存在磁盤中相鄰 的位置上。在這種情況下，當對數據進行定位時，Innodb會進行優化：“Pending read”，所謂Pendingread，指的是當發生一次read的時候，并不一定是直接從文件系統里“物理read”，而只是從緩沖池中“邏輯 read”，Innodb內部的優化機制可以合并多次“邏輯read”為一次“物理read”，從而降低IO消耗，提高磁盤性能。 還有一個問題要考慮，使用photo_identifier, posted,identifier聯合主鍵時，如果對一個“舊圖片”（photo_identifier較小的圖片）發表評論的時候，數據會記錄在比較 靠前的數據頁上（因為數據在硬盤上保存的物理順序是按主鍵排序的），和直接使用identifier自增主鍵相比，這樣會引起一個不小的IO負擔，因為自 增主鍵在添加新數據時，新數據始終位于數據文件的結尾。所以，實際應用中，文中所示的方法是否可用，還要從客觀情況分析而定，比如說評論主要集中在“新圖 片”上，則IO問題不大，因為“新圖片”的記錄位于數據文件靠后的位置上，但是如果評論分布的圖片比較隨機的話，那么此方法是否適用則需要斟酌，不過也可 以變通著來，比如說在主從服務器的結構里，我們可以在主服務器上使用identifier自增主鍵，在從服務器上使用 photo_identifier,posted, identifier聯合主鍵，這樣既保證了寫操作的效率，也保證了讀操作的效率 轉自：http://hi.baidu.com/thinkinginla ... d21b01b3de0580.html

轉載于:https://www.cnblogs.com/L-H-R-X-hehe/p/4084390.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的MySQL中主键的选择与磁盘性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。