?

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

轉(zhuǎn)載于:https://www.cnblogs.com/L-H-R-X-hehe/p/4084390.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。