< Day Day Up > |
MySQL, the most popular Open Source SQL database management system, is developed, distributed, and supported by MySQL AB. MySQL AB is a commercial company, founded by the MySQL developers, that builds its business by providing services around the MySQL database management system. See Section 1.3, "Overview of MySQL AB." The MySQL Web site (http://www.mysql.com/) provides the latest information about MySQL software and MySQL AB.
The official way to pronounce "MySQL" is "My Ess Que Ell" (not "my sequel"), but we don't mind if you pronounce it as "my sequel" or in some other localized way. 1.2.1 History of MySQLWe started out with the intention of using mSQL to connect to our tables using our own fast low-level (ISAM) routines. However, after some testing, we came to the conclusion that mSQL was not fast enough or flexible enough for our needs. This resulted in a new SQL interface to our database but with almost the same API interface as mSQL . This API was designed to allow third-party code that was written for use with mSQL to be ported easily for use with MySQL. The derivation of the name MySQL is not clear. Our base directory and a large number of our libraries and tools have had the prefix "my" for well over 10 years. However, co-founder Monty Widenius's daughter is also named My. Which of the two gave its name to MySQL is still a mystery, even for us. The name of the MySQL Dolphin (our logo) is "Sakila," which was chosen by the founders of MySQL AB from a huge list of names suggested by users in our "Name the Dolphin" contest. The winning name was submitted by Ambrose Twebaze, an Open Source software developer from Swaziland, Africa. According to Ambrose, the name Sakila has its roots in SiSwati, the local language of Swaziland. Sakila is also the name of a town in Arusha, Tanzania, near Ambrose's country of origin, Uganda. 1.2.2 The Main Features of MySQLThe following list describes some of the important characteristics of the MySQL Database Software. See also Section 1.5, "MySQL Development Roadmap," for more information about current and upcoming features.
1.2.3 MySQL StabilityThis section addresses the questions, " How stable is MySQL Server? " and, " Can I depend on MySQL Server in this project? " We will try to clarify these issues and answer some important questions that concern many potential users. The information in this section is based on data gathered from the mailing lists, which are very active in identifying problems as well as reporting types of use. The original code stems back to the early 1980s. It provides a stable code base, and the ISAM table format used by the original storage engine remains backward-compatible . At TcX, the predecessor of MySQL AB, MySQL code has worked in projects since mid-1996, without any problems. When the MySQL Database Software initially was released to a wider public, our new users quickly found some pieces of untested code. Each new release since then has had fewer portability problems, even though each new release has also had many new features. Each release of the MySQL Server has been usable. Problems have occurred only when users try code from the "gray zones." Naturally, new users don't know what the gray zones are; this section therefore attempts to document those areas that are currently known. The descriptions mostly deal with Version 3.23 and 4.0 of MySQL Server. All known and reported bugs are fixed in the latest version, with the exception of those listed in the bugs section, which are design- related . See Section 1.8.7, "Known Errors and Design Deficiencies in MySQL." The MySQL Server design is multi-layered with independent modules. Some of the newer modules are listed here with an indication of how well-tested each of them is:
1.2.4 How Big MySQL Tables Can BeMySQL 3.22 had a 4GB (4 gigabyte) limit on table size . With the MyISAM storage engine in MySQL 3.23, the maximum table size was increased to 8 million terabytes (2 63 bytes). With this larger allowed table size, the maximum effective table size for MySQL databases now usually is determined by operating system constraints on file sizes, not by MySQL internal limits. The InnoDB storage engine maintains InnoDB tables within a tablespace that can be created from several files. This allows a table to exceed the maximum individual file size. The tablespace can include raw disk partitions, which allows extremely large tables. The maximum tablespace size is 64TB. The following table lists some examples of operating system file-size limits:
On Linux 2.2, you can get MyISAM tables larger than 2GB in size by using the Large File Support (LFS) patch for the ext2 filesystem. On Linux 2.4, patches also exist for ReiserFS to get support for big files. Most current Linux distributions are based on kernel 2.4 and already include all the required LFS patches. However, the maximum available file size still depends on several factors, one of them being the filesystem used to store MySQL tables. For a detailed overview about LFS in Linux, have a look at Andreas Jaeger's "Large File Support in Linux" page at http://www.suse.de/~aj/linux_lfs.html. By default, MySQL creates MyISAM tables with an internal structure that allows a maximum size of about 4GB. You can check the maximum table size for a table with the SHOW TABLE STATUS statement or with myisamchk -dv tbl_name . If you need a MyISAM table that will be larger than 4GB in size (and your operating system supports large files), the CREATE TABLE statement allows AVG_ROW_LENGTH and MAX_ROWS options. You can also change these options with ALTER TABLE after the table has been created, to increase the table's maximum allowable size. Other ways to work around file-size limits for MyISAM tables are as follows:
1.2.5 Year 2000 ComplianceThe MySQL Server itself has no problems with Year 2000 (Y2K) compliance:
The following simple demonstration illustrates that MySQL Server has no problems with DATE or DATETIME values through the year 9999, and no problems with TIMESTAMP values until after the year 2030: 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) The final two TIMESTAMP column values are zero because the final year values ( 2040 , 9999 ) exceed the TIMESTAMP maximum. The TIMESTAMP data type, which is used to store the current time, supports values that range from 19700101000000 to 20300101000000 on 32-bit machines (signed value). On 64-bit machines, TIMESTAMP handles values up to 2106 (unsigned value). Although MySQL Server itself is Y2K-safe, you may run into problems if you use it with applications that are not Y2K-safe. For example, many old applications store or manipulate years using two-digit values (which are ambiguous) rather than four-digit values. This problem may be compounded by applications that use values such as 00 or 99 as "missing" value indicators. Unfortunately, these problems may be difficult to fix because different applications may be written by different programmers, each of whom may use a different set of conventions and date-handling functions. Thus, even though MySQL Server has no Y2K problems, it is the application's responsibility to provide unambiguous input. |
< Day Day Up > |