| 導購 | 订阅 | 在线投稿
分享
 
 
當前位置: 王朝網路 >> mysql >> MySQL數據庫單一表突破4G限制的實現方法
 

MySQL數據庫單一表突破4G限制的實現方法

2008-08-19 06:50:57  編輯來源:互聯網  简体版  手機版  評論  字體: ||
 
 
  問題:在論壇發表回複時出現「The table is full」的提示,字面意義上是數據表已滿的意思。因爲很少有開發者遭遇單一表超過4G的情況,因此朋友間的討論只能提供一些外圍的信息。爲解決此問題,我翻閱了很多資料,本文將以我此次問題的解決過程,介紹問題發生的原因及對策。

  根據經驗,The table is full提示往往出現在以下兩種情況:

  1. 表中設置了MAX_ROWS值,簡單的說,若MAX_ROWS設置爲100,而程序試圖寫入第101條記錄,會出現此錯誤。

  2. 表滿。這種情況是本文討論的重點

  我們認爲MySQL在存取表的時候,存在一種定位分配規律。這個規律在默認的情況下,可以尋址4G以內的數據。超過這個大小,數據庫將不能對數據定位,因而也無法進行讀寫。經過實驗,這個限制是完全可以被突破的。

  本例中,用戶的系統環境爲雙Athlon處理器、SCSI硬盤72G、2G內存,用戶的帖子表數據尺寸爲4294963640,接近4G(4G的實際字節數爲4294967296)。

  首先SSH登錄後,查看用戶的系統信息:

  # uname -a

  Linux zichen.com 2.4.20-8smp #1 SMP Thu Mar 13 16:43:01 EST 2003 i686 athlon i386 GNU/Linux

  證明是Linux系統,根據內核版本2.4.20-8smp,加上國內使用的常見系統,估計應該是redhat 9發行包。

  # cat /etc/*release*

  Red Hat Linux release 9 (Shrike)

  這也證明了我們對系統版本的猜想。

  然後看一下用的是什麽文件系統。因爲該用戶並非高手,估計在裝系統的時候就是一路回車下來,redhat 9默認的應該是EXT3,不過我們還是看一下:

  # parted

  GNU Parted 1.6.3

  Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.

  This program is free software, covered by the GNU General Public License.

  This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of

  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

  Using /dev/sda

  Information: The operating system thinks the geometry on /dev/sda is 8942/255/63. Therefore, cylinder 1024 ends at 8032.499M.

  (parted) print

  Disk geometry for /dev/sda: 0.000-70149.507 megabytes

  Disk label type: msdos

  Minor Start End Type Filesystem Flags

  1 0.031 101.975 primary ext3 boot

  2 101.975 10103.378 primary linux-swap

  證明確實是這樣子。隨後我們翻閱了EXT3文件系統的相關技術參數,EXT3是在EXT2基礎上演變而來。EXT2所支持最大單一文件長度是2G,這個是很蹩腳的一個限制。EXT3做的很大一個改善就是將這個限制放大到了2TB,由此稍松一口氣,起碼不是操作系統上的限制。

  經過朋友的開導,了解到單一文件大小有如下幾個因素:

  1. 文件系統的限制(如剛存所說EXT3的2TB限制)

  2. 某一程序進程所能存取的第一文件最大尺寸(例如apache在Linux EXT3下能存取的最大尺寸爲2G,諸如日志)

  初步判斷瓶頸就在上述其中第二項。隨後找到myisamchk來顯示一下表信息,證明了瓶頸就在MySQL本身的存取上。

  # myisamchk -dv cdb_posts

  結果就不貼了,其中有一項Max datafile length的值恰好就是4G。由此産生了瓶頸。

  後來翻閱了N多資料,進行了N多嘗試,也走了不少彎路,最終覺得還是官方文檔比較可靠。比較老的文檔裏寫道這是由于tmp_table_size的值造成的,也有提到用BIG-TABLES這個參數。事實證明這些都是歧途。大晚上的確實很累,這裏只給出最終的解決方案吧,中間的就不羅嗦了。

  進到mysql客戶端。

  # mysql -uroot -p

  Enter password: ******

  Welcome to the MySQL monitor. Commands end with ; or \g.

  Your MySQL connection id is 59411 to server version: 4.0.18-standard

  Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

  mysql> use ******

  Database changed

  mysql> ALTER TABLE cdb_posts MAX_ROWS=1000000000 AVG_ROW_LENGTH=15000;

  因爲這個表非常大,執行時間在雙Athlon的專業服務器上竟然花了30分鍾!

  之後再通過myisamchk查看該表的信息:

  # myisamchk -dv cdb_posts

  MyISAM file: cdb_posts

  Record format: Packed

  Character set: latin1 (8)

  File-version: 1

  Creation time: 2004-08-30 22:19:48

  Recover time: 2004-08-30 22:42:47

  Status: open,changed

  Auto increment key: 1 Last value: 1063143

  Data records: 619904 Deleted blocks: 5

  Datafile parts: 619909 Deleted data: 323872

  Datafile pointer (bytes): 6 Keyfile pointer (bytes): 4

  Datafile length: 4295287332 Keyfile length: 40421376

  Max datafile length: 281474976710654 Max keyfile length: 4398046510079

  Recordlength: 149

  table description:

  Key Start Len Index Type Rec/key Root Blocksize

  1 1 4 unique unsigned long 1 4535296 1024

  2 5 2 multip. unsigned short 13776 12540928 1024

  3 111 4 multip. unsigned long 1 18854912 1024

  4 28 3 multip. uint24 18 24546304 1024

  5 7 3 multip. uint24 7 32827392 1024

  111 4 unsigned long 1

  6 7 3 multip. uint24 7 40418304 1024

  28 3 uint24

  令人振奮的事情發生了,該表的 Max datafile length: 281474976710654 Max keyfile length: 4398046510079,即最大數據尺寸(MYD文件)達到了2TB,最大索引尺寸(MYI)仍然爲4G。

  由此默認的4G限制被突破了。關于其中的原理,其實很簡單:假設你有一個日記本,上面有10頁紙可以寫東西,編排目錄只需要1個字節(因爲0~9就夠了)。如果你把這本子又塞進兩張紙,變成12頁,1個字節的目錄空間就無法尋址到後面的兩頁中,進而産生了錯誤。上面那個ALTER語句中的數值都是我爲保證成功,取的比較大的值(因爲ALTER一次實在是太慢了,沒時間在那亂試驗),相當于告訴數據庫,這個本子有1000000000頁,每頁平均有15000個字節。這樣數據庫便知道這是很大的一個本子,因此不遺余力的拿出了100頁(假設說)做目錄編排,這樣這個新的目錄就可以尋址到日記本的所有內容了。錯誤消失。

  惟一的缺點就是,目錄占用的空間多了一些,但已經微乎其微了,做了這種改變其實4G的文件尺寸大小只增大了1M多,非常令人振奮。
 
 
 
上一篇《如何修改Linux下MySQL 5.0的默認連接數》
下一篇《用distinct在MySQL中查詢多條不重複記錄值》
 
 
 
 
 
 
日版寵物情人插曲《Winding Road》歌詞

日版寵物情人2017的插曲,很帶節奏感,日語的,女生唱的。 最後聽見是在第8集的時候女主手割傷了,然後男主用嘴幫她吸了一下,插曲就出來了。 歌手:Def...

兄弟共妻,我成了他們夜裏的美食

老鍾家的兩個兒子很特別,就是跟其他的人不太一樣,魔一般的執著。兄弟倆都到了要結婚的年齡了,不管自家老爹怎麽磨破嘴皮子,兄弟倆說不娶就不娶,老父母爲兄弟兩操碎了心...

如何磨出破洞牛仔褲?牛仔褲怎麽剪破洞?

把牛仔褲磨出有線的破洞 1、具體工具就是磨腳石,下面墊一個硬物,然後用磨腳石一直磨一直磨,到把那塊磨薄了,用手撕開就好了。出來的洞啊很自然的。需要貓須的話調幾...

我就是掃描下圖得到了敬業福和愛國福

先來看下敬業福和愛國福 今年春節,支付寶再次推出了“五福紅包”活動,表示要“把欠大家的敬業福都還給大家”。 今天該活動正式啓動,和去年一樣,需要收集“五福”...

冰箱異味産生的原因和臭味去除的方法

有時候我們打開冰箱就會聞到一股異味,冰箱裏的這種異味是因爲一些物質發出的氣味的混合體,聞起來讓人惡心。 産生這些異味的主要原因有以下幾點。 1、很多人有這種習...

《極品家丁》1-31集大結局分集劇情介紹

簡介 《極品家丁》講述了現代白領林晚榮無意回到古代金陵,並追隨蕭二小姐化名“林三”進入蕭府,不料卻陰差陽錯上演了一出低級家丁拼搏上位的“林三升職記”。...

李溪芮《極品家丁》片尾曲《你就是我最愛的寶寶》歌詞

你就是我最愛的寶寶 - 李溪芮 (電視劇《極品家丁》片尾曲) 作詞:常馨內 作曲:常馨內 你的眉 又鬼馬的挑 你的嘴 又壞壞的笑 上一秒吵鬧 下...

烏梅的功效與作用以及烏梅的食用禁忌有哪些?

烏梅,又稱春梅,中醫認爲,烏梅味酸,性溫,無毒,具有安心、除熱、下氣、祛痰、止渴調中、殺蟲的功效,治肢體痛、肺痨病。烏梅泡水喝能治傷寒煩熱、止吐瀉,與幹姜一起制...

什麽是脂肪粒?如何消除臉部脂肪粒?

什麽是脂肪粒 在我們的臉上總會長一個個像脂肪的小顆粒,弄也弄不掉,而且顔色還是白白的。它既不是粉刺也不是其他的任何痘痘,它就是脂肪粒。 脂肪粒雖然也是由油脂...

網絡安全治理:國家安全保障的主要方向是打擊犯罪,而不是處置和懲罰受害者

來源:中國青年報 新的攻擊方法不斷湧現,黑客幾乎永遠占據網絡攻擊的上風,我們不可能通過技術手段杜絕網絡攻擊。國家安全保障的主要方向是打擊犯罪,而不是處置和懲罰...

河南夫妻在溫嶺網絡直播“造人”內容涉黃被刑事拘留

夫妻網絡直播“造人”爆紅   1月9日,溫嶺城北派出所接到南京警方的協查通告,他們近期打掉了一個涉黃直播APP平台。而根據掌握的線索,其中有一對涉案的夫妻主播...

如何防止牆紙老化?牆紙變舊變黃怎麽辦?

如何防止牆紙老化? (1)選擇透氣性好的牆紙 市場上牆紙的材質分無紡布的、木纖維的、PVC的、玻璃纖維基材的、布面的等,相對而言,PVC材質的牆紙最不透氣...

鮮肌之謎非日本生産VS鮮肌之謎假日貨是謠言

觀點一:破日本銷售量的“鮮肌之謎” 非日本生産 近一段時間,淘寶上架了一款名爲“鮮肌之謎的” 鲑魚卵巢美容液,號稱是最近日本的一款推出的全新護膚品,産品本身所...

中國最美古詩詞精選摘抄

系腰裙(北宋詞人 張先) 惜霜蟾照夜雲天,朦胧影、畫勾闌。人情縱似長情月,算一年年。又能得、幾番圓。 欲寄西江題葉字,流不到、五亭前。東池始有荷新綠,尚小如...

關于女人的經典語句

關于女人的經典語句1、【做一個獨立的女人】 思想獨立:有主見、有自己的人生觀、價值觀。有上進心,永遠不放棄自己的理想,做一份自己喜愛的事業,擁有快樂和成就...

未來我們可以和性愛機器人結婚嗎?

你想體驗機器人性愛嗎?你想和性愛機器人結婚嗎?如果你想,機器人有拒絕你的權利嗎? 近日,第二屆“國際人類-機器人性愛研討會”大會在倫敦金史密斯大學落下帷幕。而...

全球最變態的十個地方

10.土耳其地下洞穴城市 變態指數:★★☆☆☆ 這是土耳其卡帕多西亞的一個著名景點,傳說是當年基督教徒們爲了躲避戰爭而在此修建。裏面曾住著20000人,...

科學家稱,人類死亡後意識將在另外一個宇宙中繼續存活

據英國《每日快報》報道,一位科學家兼理論家Robert Lanza博士宣稱,世界上並不存在人類死亡,死亡的只是身體。他認爲我們的意識借助我們體內的能量生存,而且...

《屏裏狐》片頭曲《我愛狐狸精》歌詞是什麽?

《我愛狐狸精》 - 劉馨棋   (電視劇《屏裏狐》主題曲)   作詞:金十三&李旦   作曲:劉嘉   狐狸精 狐狸仙   千年修...

 
 
 
問題:在論壇發表回複時出現「The table is full」的提示,字面意義上是數據表已滿的意思。因爲很少有開發者遭遇單一表超過4G的情況,因此朋友間的討論只能提供一些外圍的信息。爲解決此問題,我翻閱了很多資料,本文將以我此次問題的解決過程,介紹問題發生的原因及對策。 根據經驗,The table is full提示往往出現在以下兩種情況: 1. 表中設置了MAX_ROWS值,簡單的說,若MAX_ROWS設置爲100,而程序試圖寫入第101條記錄,會出現此錯誤。 2. 表滿。這種情況是本文討論的重點 我們認爲MySQL在存取表的時候,存在一種定位分配規律。這個規律在默認的情況下,可以尋址4G以內的數據。超過這個大小,數據庫將不能對數據定位,因而也無法進行讀寫。經過實驗,這個限制是完全可以被突破的。 本例中,用戶的系統環境爲雙Athlon處理器、SCSI硬盤72G、2G內存,用戶的帖子表數據尺寸爲4294963640,接近4G(4G的實際字節數爲4294967296)。 首先SSH登錄後,查看用戶的系統信息: # uname -a Linux zichen.com 2.4.20-8smp #1 SMP Thu Mar 13 16:43:01 EST 2003 i686 athlon i386 GNU/Linux 證明是Linux系統,根據內核版本2.4.20-8smp,加上國內使用的常見系統,估計應該是redhat 9發行包。 # cat /etc/*release* Red Hat Linux release 9 (Shrike) 這也證明了我們對系統版本的猜想。 然後看一下用的是什麽文件系統。因爲該用戶並非高手,估計在裝系統的時候就是一路回車下來,redhat 9默認的應該是EXT3,不過我們還是看一下: # parted GNU Parted 1.6.3 Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc. This program is free software, covered by the GNU General Public License. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. Using /dev/sda Information: The operating system thinks the geometry on /dev/sda is 8942/255/63. Therefore, cylinder 1024 ends at 8032.499M. (parted) print Disk geometry for /dev/sda: 0.000-70149.507 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.031 101.975 primary ext3 boot 2 101.975 10103.378 primary linux-swap 證明確實是這樣子。隨後我們翻閱了EXT3文件系統的相關技術參數,EXT3是在EXT2基礎上演變而來。EXT2所支持最大單一文件長度是2G,這個是很蹩腳的一個限制。EXT3做的很大一個改善就是將這個限制放大到了2TB,由此稍松一口氣,起碼不是操作系統上的限制。 經過朋友的開導,了解到單一文件大小有如下幾個因素: 1. 文件系統的限制(如剛存所說EXT3的2TB限制) 2. 某一程序進程所能存取的第一文件最大尺寸(例如apache在Linux EXT3下能存取的最大尺寸爲2G,諸如日志) 初步判斷瓶頸就在上述其中第二項。隨後找到myisamchk來顯示一下表信息,證明了瓶頸就在MySQL本身的存取上。 # myisamchk -dv cdb_posts 結果就不貼了,其中有一項Max datafile length的值恰好就是4G。由此産生了瓶頸。 後來翻閱了N多資料,進行了N多嘗試,也走了不少彎路,最終覺得還是官方文檔比較可靠。比較老的文檔裏寫道這是由于tmp_table_size的值造成的,也有提到用BIG-TABLES這個參數。事實證明這些都是歧途。大晚上的確實很累,這裏只給出最終的解決方案吧,中間的就不羅嗦了。 進到mysql客戶端。 # mysql -uroot -p Enter password: ****** Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 59411 to server version: 4.0.18-standard Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> use ****** Database changed mysql> ALTER TABLE cdb_posts MAX_ROWS=1000000000 AVG_ROW_LENGTH=15000; 因爲這個表非常大,執行時間在雙Athlon的專業服務器上竟然花了30分鍾! 之後再通過myisamchk查看該表的信息: # myisamchk -dv cdb_posts MyISAM file: cdb_posts Record format: Packed Character set: latin1 (8) File-version: 1 Creation time: 2004-08-30 22:19:48 Recover time: 2004-08-30 22:42:47 Status: open,changed Auto increment key: 1 Last value: 1063143 Data records: 619904 Deleted blocks: 5 Datafile parts: 619909 Deleted data: 323872 Datafile pointer (bytes): 6 Keyfile pointer (bytes): 4 Datafile length: 4295287332 Keyfile length: 40421376 Max datafile length: 281474976710654 Max keyfile length: 4398046510079 Recordlength: 149 table description: Key Start Len Index Type Rec/key Root Blocksize 1 1 4 unique unsigned long 1 4535296 1024 2 5 2 multip. unsigned short 13776 12540928 1024 3 111 4 multip. unsigned long 1 18854912 1024 4 28 3 multip. uint24 18 24546304 1024 5 7 3 multip. uint24 7 32827392 1024 111 4 unsigned long 1 6 7 3 multip. uint24 7 40418304 1024 28 3 uint24 令人振奮的事情發生了,該表的 Max datafile length: 281474976710654 Max keyfile length: 4398046510079,即最大數據尺寸(MYD文件)達到了2TB,最大索引尺寸(MYI)仍然爲4G。 由此默認的4G限制被突破了。關于其中的原理,其實很簡單:假設你有一個日記本,上面有10頁紙可以寫東西,編排目錄只需要1個字節(因爲0~9就夠了)。如果你把這本子又塞進兩張紙,變成12頁,1個字節的目錄空間就無法尋址到後面的兩頁中,進而産生了錯誤。上面那個ALTER語句中的數值都是我爲保證成功,取的比較大的值(因爲ALTER一次實在是太慢了,沒時間在那亂試驗),相當于告訴數據庫,這個本子有1000000000頁,每頁平均有15000個字節。這樣數據庫便知道這是很大的一個本子,因此不遺余力的拿出了100頁(假設說)做目錄編排,這樣這個新的目錄就可以尋址到日記本的所有內容了。錯誤消失。 惟一的缺點就是,目錄占用的空間多了一些,但已經微乎其微了,做了這種改變其實4G的文件尺寸大小只增大了1M多,非常令人振奮。
󰈣󰈤
 
 
 
  免責聲明:本文僅代表作者個人觀點,與王朝網路無關。王朝網路登載此文出於傳遞更多信息之目的,並不意味著贊同其觀點或證實其描述,其原創性以及文中陳述文字和內容未經本站證實,對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請讀者僅作參考,並請自行核實相關內容。
 
 
寶貝清純百變豬豬
美女喜太狼裙裝時代
美麗幹練的OL
平面模特楊棋涵
石系列印象
海洲錦屏磷礦
再憶桂林
觀:重金屬所攝影:元陽梯田所想
 
>>返回首頁<<
 
 
 
 熱帖排行
 
 
 
 
© 2005- 王朝網路 版權所有