- 論壇徽章:
- 0
|
1.4.3. MySQL穩(wěn)定性
本節(jié)回答了如下問題:“MySQL服務(wù)器有多穩(wěn)定?”,以及“在本項目中我能依靠MySQL服務(wù)器嗎”? 我們將嘗試闡明這類問題,并回答很多潛在用戶關(guān)心的某些重要問題。本節(jié)所給出的信息基于通過郵件列表收集的數(shù)據(jù),在確定問題和通報使用類型方面,郵件列表十分有用。
最初的代碼可回溯至20世紀(jì)80年代初。它提供了穩(wěn)定的編碼基數(shù),最初存儲引擎使用的ISAM表格式仍保持向后兼容性。在MySQL AB公司的前身TcX,自1996年中期以來,MySQL代碼在多個項目中工作良好,未出現(xiàn)任何問題。當(dāng)MySQL數(shù)據(jù)庫軟件首次向更廣泛的公眾發(fā)布時,我們的用戶很快發(fā)現(xiàn)了一些未經(jīng)測試的代碼段。自那以后,盡管每個新版本具有很多新的特性,但每次新發(fā)布的版本均存在少量的移植性問題。
每次發(fā)布的MySQL服務(wù)器均是可用的。僅當(dāng)用戶嘗試源自“灰色區(qū)域”的代碼時才會出現(xiàn)問題。當(dāng)然,新用戶不了解“灰色區(qū)域”是什么。因此,在本節(jié)中,我們介紹了目前已知的這類區(qū)域。本節(jié)所作的介紹主要針對MySQL服務(wù)器3.23版和更高版本。在最新的版本中,更正了所有已知和通報的缺陷,但“缺陷”一節(jié)所列的除外,這類缺陷與設(shè)計有關(guān)。請參見A.8節(jié),“MySQL中的已知事宜”。
MySQL服務(wù)器采用了多層設(shè)計和獨(dú)立模塊。在此列出了一些較新的模塊,并指明了它們的測試情況。
· Replication(穩(wěn)定)
大量使用復(fù)制功能的服務(wù)器均處于生產(chǎn)模式下,結(jié)果良好。在MySQL 5.x中,將繼續(xù)增強(qiáng)復(fù)制功能。
· InnoDB表(穩(wěn)定)
自3.23.49版以來,InnoDB事務(wù)存儲引擎一直很穩(wěn)定。InnoDB正用于大型、重負(fù)荷生產(chǎn)系統(tǒng)。
· BDB表(穩(wěn)定)
Berkeley DB碼十分穩(wěn)定,但在MySQL服務(wù)器中,我們?nèi)栽诟倪M(jìn)BDB事務(wù)存儲引擎。
· 全文本搜索(穩(wěn)定)
全文本搜索的使用范圍十分廣泛。在MySQL 4.0和4.1中,增加了重要的特性增強(qiáng)。
· MyODBC 3.51(穩(wěn)定)
MyODBC 3.51采用了ODBC SDK 3.51,并廣泛用于生產(chǎn)活動中。某些出現(xiàn)的情況看上去與應(yīng)用程序相關(guān),與ODBC驅(qū)動程序或底層數(shù)據(jù)庫服務(wù)器無關(guān)。
1.4.4. MySQL表最大能達(dá)到多少
MySQL 3.22限制的表大小為4GB。由于在MySQL 3.23中使用了MyISAM存儲引擎,最大表尺寸增加到了65536TB(2567 – 1字節(jié))。由于允許的表尺寸更大,MySQL數(shù)據(jù)庫的最大有效表尺寸通常是由操作系統(tǒng)對文件大小的限制決定的,而不是由MySQL內(nèi)部限制決定的。
InnoDB存儲引擎將InnoDB表保存在一個表空間內(nèi),該表空間可由數(shù)個文件創(chuàng)建。這樣,表的大小就能超過單獨(dú)文件的最大容量。表空間可包括原始磁盤分區(qū),從而使得很大的表成為可能。表空間的最大容量為64TB。
在下面的表格中,列出了一些關(guān)于操作系統(tǒng)文件大小限制的示例。這僅是初步指南,并不是最終的。要想了解最新信息,請參閱關(guān)于操作系統(tǒng)的文檔。
操作系統(tǒng)
文件大小限制
Linux 2.2-Intel 32-bit
2GB (LFS: 4GB)
Linux 2.4+
(using ext3 filesystem) 4TB
Solaris 9/10
16TB
NetWare w/NSS filesystem
8TB
win32 w/ FAT/FAT32
2GB/4GB
win32 w/ NTFS
2TB(可能更大)
MacOS X w/ HFS+
2TB
在Linux 2.2平臺下,通過使用對ext2文件系統(tǒng)的大文件支持(LFS)補(bǔ)丁,可以獲得超過2GB的MyISAM表。在Linux 2.4平臺下,存在針對ReiserFS的補(bǔ)丁,可支持大文件(高達(dá)2TB)。目前發(fā)布的大多數(shù)Linux版本均基于2.4內(nèi)核,包含所有所需的LFS補(bǔ)丁。使用JFS和XFS,petabyte(千兆兆)和更大的文件也能在Linux上實(shí)現(xiàn)。然而,最大可用的文件容量仍取決于多項因素,其中之一就是用于存儲MySQL表的文件系統(tǒng)。
關(guān)于Linux中LFS的詳細(xì)介紹,請參見Andreas Jaeger的“Linux中的大文件支持”頁面:http://www.suse.de/~aj/linux_lfs.html。
Windows用戶請注意: FAT和VFAT (FAT32)不適合MySQL的生產(chǎn)使用。應(yīng)使用NTFS。
在默認(rèn)情況下,MySQL創(chuàng)建的MyISAM表允許的最大尺寸為4GB。你可以使用SHOW TABLE STATUS語句或myisamchk -dv tbl_name檢查表的最大尺寸。請參見13.5.4節(jié),“SHOW語法”。
如果需要使用大于4GB的MyISAM表(而且你的操作系統(tǒng)支持大文件),可使用允許AVG_ROW_LENGTH和MAX_ROWS選項的CREATE TABLE語句。請參見13.1.5節(jié),“CREATE TABLE語法”。創(chuàng)建了表后,也可以使用ALTER TABLE更改這些選項,以增加表的最大允許容量。請參見13.1.2節(jié),“ALTER TABLE語法”。
處理MyISAM表文件大小的其他方式:
· 如果你的大表是只讀的,可使用myisampack壓縮它。myisampack通常能將表壓縮至少50%,因而,從結(jié)果上看,可獲得更大的表。此外,myisampack還能將多個表合并為1個表。請參見8.2節(jié),“myisampack:生成壓縮、只讀MyISAM表”。
· MySQL包含一個允許處理MyISAM表集合的MERGE庫,這類MyISAM表具有與單個MERGE表相同的結(jié)構(gòu)。請參見15.3節(jié),“MERGE存儲引擎”。
1.4.5. 2000年兼容性
MySQL服務(wù)器本身不存在2000年(Y2K)兼容性問題:
· MySQL服務(wù)器采用了Unix的時間功能,對于TIMESTAMP值,可處理的日期至2037年。對于DATE和DATETIME值,可接受的日期可至9999年。
· 所有的MySQL日期函數(shù)均是在1個源文件sql/time.cc中實(shí)現(xiàn)的,并經(jīng)過了恰當(dāng)編碼以確保2000年安全。
· 在MySQL 3.22和以后的版本中,YEAR列類型能夠在1個字節(jié)內(nèi)保存0年以及1901~2155年,并能使用兩位或四位數(shù)字顯示它們。所有的兩位數(shù)字年份均被視為介于1970~2069年之間,這意味著,如果你在YEAR列中保存了01,MySQL服務(wù)器會將其當(dāng)作2001年。
通過下面的簡單演示示例,表明MySQL服務(wù)器在處理直至9999年的DATE或DATETIME值方面不存在問題,在處理2030年以前的TIMESTAMP值方面也不存在問題:
mysql> DROP TABLE IF EXISTS y2k;Query OK, 0 rows affected (0.01 sec) mysql> CREATE TABLE y2k (date DATE, -> date_time DATETIME, -> time_stamp TIMESTAMP);Query OK, 0 rows affected (0.01 sec) mysql> INSERT INTO y2k VALUES -> ('1998-12-31','1998-12-31 23:59:59',19981231235959), -> ('1999-01-01','1999-01-01 00:00:00',19990101000000), -> ('1999-09-09','1999-09-09 23:59:59',19990909235959), -> ('2000-01-01','2000-01-01 00:00:00',20000101000000), -> ('2000-02-28','2000-02-28 00:00:00',20000228000000), -> ('2000-02-29','2000-02-29 00:00:00',20000229000000), -> ('2000-03-01','2000-03-01 00:00:00',20000301000000), -> ('2000-12-31','2000-12-31 23:59:59',20001231235959), -> ('2001-01-01','2001-01-01 00:00:00',20010101000000), -> ('2004-12-31','2004-12-31 23:59:59',20041231235959), -> ('2005-01-01','2005-01-01 00:00:00',20050101000000), -> ('2030-01-01','2030-01-01 00:00:00',20300101000000), -> ('2040-01-01','2040-01-01 00:00:00',20400101000000), -> ('9999-12-31','9999-12-31 23:59:59',99991231235959);Query OK, 14 rows affected (0.01 sec)Records: 14 Duplicates: 0 Warnings: 2 mysql> SELECT * FROM y2k;+------------+---------------------+----------------+| date | date_time | time_stamp |+------------+---------------------+----------------+| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 || 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 || 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 || 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 || 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 || 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 || 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 || 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 || 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 || 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 || 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 || 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 || 2040-01-01 | 2040-01-01 00:00:00 | 00000000000000 || 9999-12-31 | 9999-12-31 23:59:59 | 00000000000000 |+------------+---------------------+----------------+14 rows in set (0.00 sec)最后2個TIMESTAMP列的值為0,這是因為年份值(2040,9999)超出了TIMESTAMP的最大范圍。TIMESTAMP數(shù)據(jù)類型用于保存當(dāng)前時間,在32位機(jī)器上,支持的取值范圍是19700101000000~20300101000000(帶符號值)。在64位機(jī)器上,TIMESTAMP能處理的值達(dá)2106(無符號值)。
盡管MySQL服務(wù)器本身不存在2000年安全問題,但如果使用了存在Y2K問題的應(yīng)用程序,也會遇到問題。例如,很多早期的應(yīng)用程序采用2位數(shù)值(兩可性)而不是4位數(shù)值來保存和處理年份數(shù)據(jù)。這類問題可能會被使用“00”或“99”的應(yīng)用程序合并為“丟失”值指示符。很不幸,這類問題或許很難更正,這是因為不同的應(yīng)用程序是由不同的程序員編寫的,每位程序員可能使用了不同的慣例集和日期處理函數(shù)。
因此,盡管MySQL服務(wù)器不存在Y2K問題,但應(yīng)用程序須提供無歧義的輸入值。關(guān)于MySQL服務(wù)器在處理含2位年份數(shù)值的兩可性日期輸入數(shù)據(jù)方面的作用,請參見11.3.4節(jié),“Y2K事宜和日期類型” . |
|