- 论坛徽章:
- 0
|
1.4.3. MySQL稳定性
本节回答了如下问题:“MySQL服务器有多稳定?”,以及“在本项目中我能依靠MySQL服务器吗”? 我们将尝试阐明这类问题,并回答很多潜在用户关心的某些重要问题。本节所给出的信息基于通过邮件列表收集的数据,在确定问题和通报使用类型方面,邮件列表十分有用。
最初的代码可回溯至20世纪80年代初。它提供了稳定的编码基数,最初存储引擎使用的ISAM表格式仍保持向后兼容性。在MySQL AB公司的前身TcX,自1996年中期以来,MySQL代码在多个项目中工作良好,未出现任何问题。当MySQL数据库软件首次向更广泛的公众发布时,我们的用户很快发现了一些未经测试的代码段。自那以后,尽管每个新版本具有很多新的特性,但每次新发布的版本均存在少量的移植性问题。
每次发布的MySQL服务器均是可用的。仅当用户尝试源自“灰色区域”的代码时才会出现问题。当然,新用户不了解“灰色区域”是什么。因此,在本节中,我们介绍了目前已知的这类区域。本节所作的介绍主要针对MySQL服务器3.23版和更高版本。在最新的版本中,更正了所有已知和通报的缺陷,但“缺陷”一节所列的除外,这类缺陷与设计有关。请参见A.8节,“MySQL中的已知事宜”。
MySQL服务器采用了多层设计和独立模块。在此列出了一些较新的模块,并指明了它们的测试情况。
· Replication(稳定)
大量使用复制功能的服务器均处于生产模式下,结果良好。在MySQL 5.x中,将继续增强复制功能。
· InnoDB表(稳定)
自3.23.49版以来,InnoDB事务存储引擎一直很稳定。InnoDB正用于大型、重负荷生产系统。
· BDB表(稳定)
Berkeley DB码十分稳定,但在MySQL服务器中,我们仍在改进BDB事务存储引擎。
· 全文本搜索(稳定)
全文本搜索的使用范围十分广泛。在MySQL 4.0和4.1中,增加了重要的特性增强。
· MyODBC 3.51(稳定)
MyODBC 3.51采用了ODBC SDK 3.51,并广泛用于生产活动中。某些出现的情况看上去与应用程序相关,与ODBC驱动程序或底层数据库服务器无关。
1.4.4. MySQL表最大能达到多少
MySQL 3.22限制的表大小为4GB。由于在MySQL 3.23中使用了MyISAM存储引擎,最大表尺寸增加到了65536TB(2567 – 1字节)。由于允许的表尺寸更大,MySQL数据库的最大有效表尺寸通常是由操作系统对文件大小的限制决定的,而不是由MySQL内部限制决定的。
InnoDB存储引擎将InnoDB表保存在一个表空间内,该表空间可由数个文件创建。这样,表的大小就能超过单独文件的最大容量。表空间可包括原始磁盘分区,从而使得很大的表成为可能。表空间的最大容量为64TB。
在下面的表格中,列出了一些关于操作系统文件大小限制的示例。这仅是初步指南,并不是最终的。要想了解最新信息,请参阅关于操作系统的文档。
操作系统
文件大小限制
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文件系统的大文件支持(LFS)补丁,可以获得超过2GB的MyISAM表。在Linux 2.4平台下,存在针对ReiserFS的补丁,可支持大文件(高达2TB)。目前发布的大多数Linux版本均基于2.4内核,包含所有所需的LFS补丁。使用JFS和XFS,petabyte(千兆兆)和更大的文件也能在Linux上实现。然而,最大可用的文件容量仍取决于多项因素,其中之一就是用于存储MySQL表的文件系统。
关于Linux中LFS的详细介绍,请参见Andreas Jaeger的“Linux中的大文件支持”页面:http://www.suse.de/~aj/linux_lfs.html。
Windows用户请注意: FAT和VFAT (FAT32)不适合MySQL的生产使用。应使用NTFS。
在默认情况下,MySQL创建的MyISAM表允许的最大尺寸为4GB。你可以使用SHOW TABLE STATUS语句或myisamchk -dv tbl_name检查表的最大尺寸。请参见13.5.4节,“SHOW语法”。
如果需要使用大于4GB的MyISAM表(而且你的操作系统支持大文件),可使用允许AVG_ROW_LENGTH和MAX_ROWS选项的CREATE TABLE语句。请参见13.1.5节,“CREATE TABLE语法”。创建了表后,也可以使用ALTER TABLE更改这些选项,以增加表的最大允许容量。请参见13.1.2节,“ALTER TABLE语法”。
处理MyISAM表文件大小的其他方式:
· 如果你的大表是只读的,可使用myisampack压缩它。myisampack通常能将表压缩至少50%,因而,从结果上看,可获得更大的表。此外,myisampack还能将多个表合并为1个表。请参见8.2节,“myisampack:生成压缩、只读MyISAM表”。
· MySQL包含一个允许处理MyISAM表集合的MERGE库,这类MyISAM表具有与单个MERGE表相同的结构。请参见15.3节,“MERGE存储引擎”。
1.4.5. 2000年兼容性
MySQL服务器本身不存在2000年(Y2K)兼容性问题:
· MySQL服务器采用了Unix的时间功能,对于TIMESTAMP值,可处理的日期至2037年。对于DATE和DATETIME值,可接受的日期可至9999年。
· 所有的MySQL日期函数均是在1个源文件sql/time.cc中实现的,并经过了恰当编码以确保2000年安全。
· 在MySQL 3.22和以后的版本中,YEAR列类型能够在1个字节内保存0年以及1901~2155年,并能使用两位或四位数字显示它们。所有的两位数字年份均被视为介于1970~2069年之间,这意味着,如果你在YEAR列中保存了01,MySQL服务器会将其当作2001年。
通过下面的简单演示示例,表明MySQL服务器在处理直至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数据类型用于保存当前时间,在32位机器上,支持的取值范围是19700101000000~20300101000000(带符号值)。在64位机器上,TIMESTAMP能处理的值达2106(无符号值)。
尽管MySQL服务器本身不存在2000年安全问题,但如果使用了存在Y2K问题的应用程序,也会遇到问题。例如,很多早期的应用程序采用2位数值(两可性)而不是4位数值来保存和处理年份数据。这类问题可能会被使用“00”或“99”的应用程序合并为“丢失”值指示符。很不幸,这类问题或许很难更正,这是因为不同的应用程序是由不同的程序员编写的,每位程序员可能使用了不同的惯例集和日期处理函数。
因此,尽管MySQL服务器不存在Y2K问题,但应用程序须提供无歧义的输入值。关于MySQL服务器在处理含2位年份数值的两可性日期输入数据方面的作用,请参见11.3.4节,“Y2K事宜和日期类型” . |
|