<span id="mktg5"></span>

<i id="mktg5"><meter id="mktg5"></meter></i>

        <label id="mktg5"><meter id="mktg5"></meter></label>
        最新文章專(zhuān)題視頻專(zhuān)題問(wèn)答1問(wèn)答10問(wèn)答100問(wèn)答1000問(wèn)答2000關(guān)鍵字專(zhuān)題1關(guān)鍵字專(zhuān)題50關(guān)鍵字專(zhuān)題500關(guān)鍵字專(zhuān)題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關(guān)鍵字專(zhuān)題關(guān)鍵字專(zhuān)題tag2tag3文章專(zhuān)題文章專(zhuān)題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專(zhuān)題3
        問(wèn)答文章1 問(wèn)答文章501 問(wèn)答文章1001 問(wèn)答文章1501 問(wèn)答文章2001 問(wèn)答文章2501 問(wèn)答文章3001 問(wèn)答文章3501 問(wèn)答文章4001 問(wèn)答文章4501 問(wèn)答文章5001 問(wèn)答文章5501 問(wèn)答文章6001 問(wèn)答文章6501 問(wèn)答文章7001 問(wèn)答文章7501 問(wèn)答文章8001 問(wèn)答文章8501 問(wèn)答文章9001 問(wèn)答文章9501
        當(dāng)前位置: 首頁(yè) - 科技 - 知識(shí)百科 - 正文

        MySQL數(shù)據(jù)庫(kù)單一表突破4G限制的實(shí)現(xiàn)方法_MySQL

        來(lái)源:懂視網(wǎng) 責(zé)編:小采 時(shí)間:2020-11-09 17:13:18
        文檔

        MySQL數(shù)據(jù)庫(kù)單一表突破4G限制的實(shí)現(xiàn)方法_MySQL

        MySQL數(shù)據(jù)庫(kù)單一表突破4G限制的實(shí)現(xiàn)方法_MySQL:近日,一位Discuz!老用戶的論壇在發(fā)表回復(fù)時(shí)出現(xiàn)The table is full的提示,字面意義上是數(shù)據(jù)表已滿的意思。因?yàn)楹苌儆虚_(kāi)發(fā)者遭遇單一表超過(guò)4G的情況,因此朋友間的討論只能提供一些外圍的信息。為解決此問(wèn)題,我翻閱了很多資料,本文將以我此次問(wèn)題的解決
        推薦度:
        導(dǎo)讀MySQL數(shù)據(jù)庫(kù)單一表突破4G限制的實(shí)現(xiàn)方法_MySQL:近日,一位Discuz!老用戶的論壇在發(fā)表回復(fù)時(shí)出現(xiàn)The table is full的提示,字面意義上是數(shù)據(jù)表已滿的意思。因?yàn)楹苌儆虚_(kāi)發(fā)者遭遇單一表超過(guò)4G的情況,因此朋友間的討論只能提供一些外圍的信息。為解決此問(wèn)題,我翻閱了很多資料,本文將以我此次問(wèn)題的解決

        近日,一位Discuz!老用戶的論壇在發(fā)表回復(fù)時(shí)出現(xiàn)“The table is full”的提示,字面意義上是數(shù)據(jù)表已滿的意思。因?yàn)楹苌儆虚_(kāi)發(fā)者遭遇單一表超過(guò)4G的情況,因此朋友間的討論只能提供一些外圍的信息。為解決此問(wèn)題,我翻閱了很多資料,本文將以我此次問(wèn)題的解決過(guò)程,介紹問(wèn)題發(fā)生的原因及對(duì)策。
        根據(jù)經(jīng)驗(yàn),The table is full提示往往出現(xiàn)在以下兩種情況:
        1. 表中設(shè)置了MAX_ROWS值,簡(jiǎn)單的說(shuō),若MAX_ROWS設(shè)置為100,而程序試圖寫(xiě)入第101條記錄,會(huì)出現(xiàn)此錯(cuò)誤。
        2. 表滿。這種情況是本文討論的重點(diǎn)。

        我們認(rèn)為MySQL在存取表的時(shí)候,存在一種定位分配規(guī)律。這個(gè)規(guī)律在默認(rèn)的情況下,可以尋址4G以內(nèi)的數(shù)據(jù)。超過(guò)這個(gè)大小,數(shù)據(jù)庫(kù)將不能對(duì)數(shù)據(jù)定位,因而也無(wú)法進(jìn)行讀寫(xiě)。經(jīng)過(guò)實(shí)驗(yàn),這個(gè)限制是完全可以被突破的。
        本例中,用戶的系統(tǒng)環(huán)境為雙Athlon處理器、SCSI硬盤(pán)72G、2G內(nèi)存,用戶的帖子表數(shù)據(jù)尺寸為4294963640,接近4G(4G的實(shí)際字節(jié)數(shù)為4294967296)。

        首先SSH登錄后,查看用戶的系統(tǒng)信息:

        # 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系統(tǒng),根據(jù)內(nèi)核版本2.4.20-8smp,加上國(guó)內(nèi)使用的常見(jiàn)系統(tǒng),估計(jì)應(yīng)該是redhat 9發(fā)行包。

        # cat /etc/*release*
        Red Hat Linux release 9 (Shrike)

        這也證明了我們對(duì)系統(tǒng)版本的猜想。

        然后看一下用的是什么文件系統(tǒng)。因?yàn)樵撚脩舨⒎歉呤郑烙?jì)在裝系統(tǒng)的時(shí)候就是一路回車(chē)下來(lái),redhat 9默認(rèn)的應(yīng)該是EXT3,不過(guò)我們還是看一下:

        # 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

        證明確實(shí)是這樣子。隨后我們翻閱了EXT3文件系統(tǒng)的相關(guān)技術(shù)參數(shù),EXT3是在EXT2基礎(chǔ)上演變而來(lái)。EXT2所支持最大單一文件長(zhǎng)度是2G,這個(gè)是很蹩腳的一個(gè)限制。EXT3做的很大一個(gè)改善就是將這個(gè)限制放大到了2TB,由此稍松一口氣,起碼不是操作系統(tǒng)上的限制。

        經(jīng)過(guò)朋友的開(kāi)導(dǎo),了解到單一文件大小有如下幾個(gè)因素:
        1. 文件系統(tǒng)的限制(如剛存所說(shuō)EXT3的2TB限制)
        2. 某一程序進(jìn)程所能存取的第一文件最大尺寸(例如apache在Linux EXT3下能存取的最大尺寸為2G,諸如日志)

        初步判斷瓶頸就在上述其中第二項(xiàng)。隨后找到myisamchk來(lái)顯示一下表信息,證明了瓶頸就在MySQL本身的存取上。

        # myisamchk -dv cdb_posts

        結(jié)果就不貼了,其中有一項(xiàng)Max datafile length的值恰好就是4G。由此產(chǎn)生了瓶頸。
        后來(lái)翻閱了N多資料,進(jìn)行了N多嘗試,也走了不少?gòu)澛罚罱K覺(jué)得還是官方文檔比較可靠。比較老的文檔里寫(xiě)道這是由于tmp_table_size的值造成的,也有提到用BIG-TABLES這個(gè)參數(shù)。事實(shí)證明這些都是歧途。大晚上的確實(shí)很累,這里只給出最終的解決方案吧,中間的就不羅嗦了。

        進(jìn)到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;

        因?yàn)檫@個(gè)表非常大,執(zhí)行時(shí)間在雙Athlon的專(zhuān)業(yè)服務(wù)器上竟然花了30分鐘!
        之后再通過(guò)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

        令人振奮的事情發(fā)生了,該表的 Max datafile length: 281474976710654 Max keyfile length: 4398046510079,即最大數(shù)據(jù)尺寸(MYD文件)達(dá)到了2TB,最大索引尺寸(MYI)仍然為4G。
        由此默認(rèn)的4G限制被突破了。關(guān)于其中的原理,其實(shí)很簡(jiǎn)單:假設(shè)你有一個(gè)日記本,上面有10頁(yè)紙可以寫(xiě)東西,編排目錄只需要1個(gè)字節(jié)(因?yàn)?~9就夠了)。如果你把這本子又塞進(jìn)兩張紙,變成12頁(yè),1個(gè)字節(jié)的目錄空間就無(wú)法尋址到后面的兩頁(yè)中,進(jìn)而產(chǎn)生了錯(cuò)誤。上面那個(gè)ALTER語(yǔ)句中的數(shù)值都是我為保證成功,取的比較大的值(因?yàn)锳LTER一次實(shí)在是太慢了,沒(méi)時(shí)間在那亂試驗(yàn)),相當(dāng)于告訴數(shù)據(jù)庫(kù),這個(gè)本子有1000000000頁(yè),每頁(yè)平均有15000個(gè)字節(jié)。這樣數(shù)據(jù)庫(kù)便知道這是很大的一個(gè)本子,因此不遺余力的拿出了100頁(yè)(假設(shè)說(shuō))做目錄編排,這樣這個(gè)新的目錄就可以尋址到日記本的所有內(nèi)容了。錯(cuò)誤消失。

        惟一的缺點(diǎn)就是,目錄占用的空間多了一些,但已經(jīng)微乎其微了,做了這種改變其實(shí)4G的文件尺寸大小只增大了1M多,非常令人振奮。

        聲明:本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí),若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

        文檔

        MySQL數(shù)據(jù)庫(kù)單一表突破4G限制的實(shí)現(xiàn)方法_MySQL

        MySQL數(shù)據(jù)庫(kù)單一表突破4G限制的實(shí)現(xiàn)方法_MySQL:近日,一位Discuz!老用戶的論壇在發(fā)表回復(fù)時(shí)出現(xiàn)The table is full的提示,字面意義上是數(shù)據(jù)表已滿的意思。因?yàn)楹苌儆虚_(kāi)發(fā)者遭遇單一表超過(guò)4G的情況,因此朋友間的討論只能提供一些外圍的信息。為解決此問(wèn)題,我翻閱了很多資料,本文將以我此次問(wèn)題的解決
        推薦度:
        標(biāo)簽: 文件 方法 系統(tǒng)
        • 熱門(mén)焦點(diǎn)

        最新推薦

        猜你喜歡

        熱門(mén)推薦

        專(zhuān)題
        Top
        主站蜘蛛池模板: 中文字幕成人免费高清在线| 美女视频黄频a免费大全视频 | 性色av极品无码专区亚洲| 久久WWW免费人成一看片| 亚洲精品免费在线视频| 久久经典免费视频| 亚洲一区二区三区国产精华液| 成人免费a级毛片无码网站入口| 亚洲精品天堂在线观看| 在线观看亚洲成人| 亚洲av无码一区二区三区观看| 91免费人成网站在线观看18| 亚洲噜噜噜噜噜影院在线播放| 免费在线观看的网站| 久久亚洲精品11p| 久久乐国产精品亚洲综合| 99在线免费观看| 亚洲成AV人综合在线观看| 青青青国产免费一夜七次郎| 人碰人碰人成人免费视频| 亚洲国产精品lv| 成人毛片18女人毛片免费视频未 | 国产又黄又爽又刺激的免费网址 | 国产在线观看免费完整版中文版 | 亚洲av无码精品网站| 99久久国产热无码精品免费 | 久久久久免费精品国产| 亚洲熟妇av一区| 免费看国产一级特黄aa大片| 免费看黄的成人APP| 亚洲人成网站日本片| 亚洲av午夜精品一区二区三区| 成全在线观看免费观看大全| 亚洲无吗在线视频| 亚洲综合另类小说色区色噜噜| 中文字幕免费观看| 污污视频免费观看网站| 亚洲第一页在线观看| 亚洲精品国产高清嫩草影院| 国产精品视频免费| 国产性生大片免费观看性|