2.2.6 Which MySQL Version to Use

The first decision to make is whether you want to use the latest development release or the last production (stable) release:

• Normally, if you are beginning to use MySQL for the first time or trying to port it to some system for which there is no binary distribution, we recommend going with the production release (currently version 4.0). Note that all MySQL releases are checked with the MySQL benchmarks and an extensive test suite before each release (even the development releases).
• Otherwise, if you are running an old system and want to upgrade, but don't want to take chances with a non-seamless upgrade, you should upgrade to the latest in the same branch you are using (where only the last version number is newer than yours). We have tried to fix only fatal bugs and make small, relatively safe changes to that version.

The second decision to make is whether you want to use a source distribution or a binary distribution. In most cases you should probably use a binary distribution, if one exists for your platform, as this generally will be easier to install than a source distribution.

In the following cases you probably will be better off with a source installation:

• If you want to install MySQL at some explicit location. (The standard binary distributions are ``ready to run'' at any place, but you may want to get even more flexibility).
• To be able to satisfy different user requirements, we are providing two different binary versions: one compiled with the non-transactional storage engines (a small, fast binary), and one configured with the most important extended options like transaction-safe tables. Both versions are compiled from the same source distribution. All native MySQL clients can connect to both MySQL versions. The extended MySQL binary distribution is marked with the -max suffix and is configured with the same options as mysqld-max. See section 4.7.5 mysqld-max, An Extended mysqld Server. If you want to use the MySQL-Max RPM, you must first install the standard MySQL-server RPM.
• If you want to configure mysqld with some extra features that are not in the standard binary distributions. Here is a list of the most common extra options that you may want to use:
  • --with-innodb (default for MySQL 4.0 and onwards)
  • --with-berkeley-db (not available on all platforms)
  • --with-raid
  • --with-libwrap
  • --with-named-z-libs (This is done for some of the binaries)
  • --with-debug[=full]
• The default binary distribution is normally compiled with support for all character sets and should work on a variety of processors from the same processor family. If you want a faster MySQL server you may want to recompile it with support for only the character sets you need, use a better compiler (like pgcc), or use compiler options that are better optimised for your processor.
• If you have found a bug and reported it to the MySQL development team you will probably receive a patch that you need to apply to the source distribution to get the bug fixed.
• If you want to read (and/or modify) the C and C++ code that makes up MySQL, you should get a source distribution. The source code is always the ultimate manual. Source distributions also contain more tests and examples than binary distributions.

The MySQL naming scheme uses release numbers that consist of three numbers and a suffix. For example, a release name like mysql-3.21.17-beta is interpreted like this:

• The first number (3) describes the file format. All Version 3 releases have the same file format.
• The second number (21) is the release level. Normally there are two to choose from. One is the production branch (currently 3.23) and the other is the development branch (currently 4.0). Normally both are stable, but the development version may have quirks, may be missing documentation on new features, or may fail to compile on some systems.
• The third number (17) is the version number within the release level. This is incremented for each new distribution. Usually you want the latest version for the release level you have chosen.
• The suffix (beta) indicates the stability level of the release. The possible suffixes are:
  • alpha indicates that the release contains some large section of new code that hasn't been 100% tested. Known bugs (usually there are none) should be documented in the News section. See section D MySQL Change History. There are also new commands and extensions in most alpha releases. Active development that may involve major code changes can occur on an alpha release, but everything will be tested before doing a release. There should be no known bugs in any MySQL release.
  • beta means that all new code has been tested. No major new features that could cause corruption on old code are added. There should be no known bugs. A version changes from alpha to beta when there haven't been any reported fatal bugs within an alpha version for at least a month and we don't plan to add any features that could make any old command more unreliable.
  • gamma is a beta that has been around a while and seems to work fine. Only minor fixes are added. This is what many other companies call a release.
  • If there is no suffix, it means that the version has been run for a while at many different sites with no reports of bugs other than platform-specific bugs. Only critical bug fixes are applied to the release. This is what we call a production (stable) release.

All versions of MySQL are run through our standard tests and benchmarks to ensure that they are relatively safe to use. Because the standard tests are extended over time to check for all previously found bugs, the test suite keeps getting better.

Note that all releases have been tested at least with:

An internal test suite

This is part of a production system for a customer. It has many tables with hundreds of megabytes of data.

The MySQL benchmark suite

This runs a range of common queries. It is also a test to see whether the latest batch of optimisations actually made the code faster. See section 5.1.4 The MySQL Benchmark Suite.

The crash-me test

This tries to determine what features the database supports and what its capabilities and limitations are. See section 5.1.4 The MySQL Benchmark Suite.

Another test is that we use the newest MySQL version in our internal production environment, on at least one machine. We have more than 100 gigabytes of data to work with.

User Comments

Add your own comment.