We 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 nor 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 chosen to ease porting of third-party code.

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 (some years younger) 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. Sakila 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.

The following list describes some of the important characteristics of the MySQL Database Software. Section 1.5.1, “MySQL 4.0 in a Nutshell ”.

This 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 list, which is very active in identifying problems as well as reporting types of use.

Original code stems back from the early '80s, providing a stable code base, and the ISAM table format 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 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 things that are design-related. Section 1.7.6, “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:

MySQL AB provides high-quality support for paying customers, and the MySQL mailing list usually provides answers to common questions. Bugs are usually fixed right away with a patch; for serious bugs, there is almost always a new release.

MySQL Version 3.22 had a 4 GB (4 gigabyte) limit on table size. With the MyISAM table type in MySQL Version 3.23, the maximum table size was pushed up to 8 million terabytes (2 ^ 63 bytes).

In effect, then, the table size for MySQL databases is normally limited by the operating system.

Note, however, that operating systems have their own file-size limits. Here are some examples:

On Linux 2.2 you can get tables larger than 2 GB in size by using the LFS patch for the ext2 filesystem. On Linux 2.4 patches also exist for ReiserFS to get support for big files. Most current distributions are based on kernel 2.4 and already include all the required Large File Support (LFS) patches. However, the maximum available file size still depends on several factors, one of them being the file system used to store MySQL tables.

For a very 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 tables have a maximum size of about 4 GB. You can check the maximum table size for a table with the SHOW TABLE STATUS command or with the myisamchk -dv table_name. Section 4.5.7, “SHOW Syntax ”.

If you need a table that will be larger than 4 GB in size (and your operating system supports it), set the AVG_ROW_LENGTH and MAX_ROWS parameters accordingly when you create your table. Section 6.5.3, “CREATE TABLE Syntax ”. You can also set these parameters later, with ALTER TABLE. Section 6.5.4, “ALTER TABLE Syntax ”.

If your big table is a read-only table, you could use myisampack to merge and compress many tables into one. myisampack usually compresses a table by at least 50%, so you can have, in effect, much bigger tables. Section 4.7.4, “myisampack, The MySQL Compressed Read-only Table Generator ”.

You can get around the operating system file limit for MyISAM datafiles using the RAID option. Section 6.5.3, “CREATE TABLE Syntax ”.

Another solution can be the included MERGE library, which allows you to handle a collection of identical tables as one. Section 7.2, “MERGE Tables ”.

The MySQL Server itself has no problems with Year 2000 (Y2K) compliance:

You may run into problems with applications that use MySQL Server in a way that is not Y2K-safe. For example, many old applications store or manipulate years using 2-digit values (which are ambiguous) rather than 4-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.

Here is a simple demonstration illustrating that MySQL Server doesn't have any problems with dates until 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.00 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),
    - ("2050-01-01","2050-01-01 00:00:00",20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13  Duplicates: 0  Warnings: 0

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 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)

This example shows that the DATE and DATETIME datatypes will not give any problems with future dates (they handle dates until the year 9999).

The TIMESTAMP datatype, 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).

Even though MySQL Server is Y2K-compliant, it is your responsibility to provide unambiguous input. See Section 6.2.2.1, “Y2K Issues and Date Types ” for MySQL Server's rules for dealing with ambiguous date input data (data containing 2-digit year values).