The MySQL (R) software delivers a very fast, multi-threaded, multi-user, and robust SQL (Structured Query Language) database server. MySQL Server is intended for mission-critical, heavy-load production systems as well as for embedding into mass-deployed software. MySQL is a registered trademark of MySQL AB.
The MySQL software is Dual Licensed. Users can choose to use the MySQL software as an Open Source product under the terms of the GNU General Public License (http://www.fsf.org/licenses/) or can purchase a standard commercial license from MySQL AB. See http://www.mysql.com/company/legal/licensing/ for more information on our licensing policies.
The following list describes some sections of particular interest in this manual:
Important:
Reports of errors (often called ``bugs''), as well as questions and comments, should be sent to http://bugs.mysql.com. See section 1.4.1.3 How to Report Bugs or Problems.
If you have found a sensitive security bug in MySQL Server, please let us know immediately by sending an email message to security@mysql.com.
This is the Reference Manual for the MySQL Database System. It documents MySQL up to Version 5.0.3-alpha, but is also applicable for older versions of the MySQL software (such as 3.23 or 4.0-production) because functional changes are indicated with reference to a version number.
Because this manual serves as a reference, it does not provide general instruction on SQL or relational database concepts. It also will not teach you how to use your operating system or command-line interpreter.
The MySQL Database Software is under constant development, and the Reference Manual is updated frequently as well. The most recent version of the manual is available online in searchable form at http://dev.mysql.com/doc/. Other formats also are available, including HTML, PDF, and Windows CHM versions.
The primary document is the Texinfo file.
The HTML version is produced automatically using a modified version of
texi2html.
The plain text and Info versions are produced with makeinfo.
The PostScript version is produced using texi2dvi and dvips.
The PDF version is produced with pdftex.
If you have any suggestions concerning additions or corrections to this manual, please send them to the documentation team at docs@mysql.com.
This manual was initially written by David Axmark and Michael ``Monty'' Widenius. It is now maintained by the MySQL Documentation Team, consisting of Paul DuBois, Stefan Hinz, Mike Hillyer, and Jon Stephens. For the many other contributors, see section B Credits.
The copyright (2004) to this manual is owned by the Swedish company MySQL AB. MySQL and the MySQL logo are (registered) trademarks of MySQL AB. Other trademarks and registered trademarks referred to in this manual are the property of their respective owners, and are used for identification purposes only.
This manual uses certain typographical conventions:
constant
mysqladmin works, invoke it with the
--help option.''
When commands are shown that are meant to be executed from within a particular
program, the program is indicated by a prompt shown before the command. For
example, shell> indicates a command that you execute from your login
shell, and mysql> indicates a statement that you execute from the
mysql client program:
shell> type a shell command here mysql> type a mysql statement here
The ``shell'' is your command interpreter. On Unix, this is typically a
program such as sh or csh. On Windows, the equivalent program is
command.com or cmd.exe, typically run in a console window.
When you enter a command or statement shown in an example, do not type the prompt shown in the example.
Database, table, and column names must often be substituted into statements. To indicate that such substitution is necessary, this manual uses db_name, tbl_name, and col_name. For example, you might see a statement like this:
mysql> SELECT col_name FROM db_name.tbl_name;
This means that if you were to enter a similar statement, you would supply your own database, table, and column names, perhaps like this:
mysql> SELECT author_name FROM biblio_db.author_list;
SQL keywords are not case sensitive and may be written in uppercase or lowercase. This manual uses uppercase.
In syntax descriptions, square brackets (`[' and `]') are used
to indicate optional words or clauses. For example, in the following
statement, IF EXISTS is optional:
DROP TABLE [IF EXISTS] tbl_name
When a syntax element consists of a number of alternatives, the alternatives are separated by vertical bars (`|'). When one member from a set of choices may be chosen, the alternatives are listed within square brackets (`[' and `]'):
TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)
When one member from a set of choices must be chosen, the alternatives are listed within braces (`{' and `}'):
{DESCRIBE | DESC} tbl_name [col_name | wild]
An ellipsis (...) indicates the omission of a section of a statement,
typically to provide a shorter version of more complex syntax. For example,
INSERT ... SELECT is shorthand for the form of INSERT statement
that is followed by a SELECT statement.
An ellipsis can also indicate that the preceding syntax element of a statement may be repeated. In the following example, multiple reset_option values may be given, with each of those after the first preceded by commas:
RESET reset_option [,reset_option] ...
Commands for setting shell variables are shown using Bourne shell syntax. For example, the sequence to set an environment variable and run a command looks like this in Bourne shell syntax:
shell> VARNAME=value some_command
If you are using csh or tcsh, you must issue commands somewhat
differently. You would execute the sequence just shown like this:
shell> setenv VARNAME value shell> some_command
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. It is a second generation Open Source company that unites Open Source values and methodology with a successful business model.
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.
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 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.
The following list describes some of the important characteristics of the MySQL Database Software. See also section 1.3 MySQL Development Roadmap for more information about current and upcoming features.
MyISAM) with index compression.
FLOAT, DOUBLE, CHAR, VARCHAR,
TEXT, BLOB, DATE, TIME, DATETIME,
TIMESTAMP, YEAR, SET, ENUM, and OpenGIS spatial
types.
See section 11 Column Types.
SELECT and WHERE
clauses of queries. For example:
mysql> SELECT CONCAT(first_name, ' ', last_name)
-> FROM citizen
-> WHERE income/dependents > 10000 AND age > 30;
GROUP BY and
ORDER BY clauses. Support
for group functions (COUNT(),
COUNT(DISTINCT ...),
AVG(), STD(),
SUM(), MAX(), MIN(), and GROUP_CONCAT()).
LEFT OUTER JOIN and RIGHT OUTER JOIN with both standard
SQL and ODBC syntax.
DELETE, INSERT, REPLACE, and UPDATE return
the number of rows that were changed (affected). It is possible to return
the number of rows matched instead by setting a flag when connecting to the
server.
SHOW command can be used to retrieve
information about databases, tables, and indexes. The EXPLAIN command
can be used to determine how the optimizer resolves a query.
ABS is a valid column name. The only restriction is that for a
function call, no spaces are allowed between the function name and the
`(' that follows it. See section 9.6 Treatment of Reserved Words in MySQL.
CHAR, VARCHAR,
BLOB, or TEXT column types.
--shared-memory option. Clients can
connect through shared memory by using the --protocol=memory option.
latin1 (ISO-8859-1), german, big5, ujis,
and more. For example,
the Scandinavian characters `â', `ä' and `ö' are
allowed in table and column names.
Unicode support is available as of MySQL 4.1.
mysqlcheck client. MySQL also includes
myisamchk, a very fast command-line utility for performing these
operations on MyISAM tables.
See section 5 Database Administration.
--help or -?
options to obtain online assistance.
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 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, 4.0 and 4.1 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.5.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:
InnoDB tables (Stable)
InnoDB transactional storage engine has been declared
stable in the MySQL 3.23 tree, starting from version 3.23.49.
InnoDB is being used in large, heavy-load production systems.
BDB tables (Stable)
Berkeley DB code is very stable, but we are still improving
the BDB transactional storage engine interface in MySQL Server.
MyODBC 3.51 (Stable)
MyODBC 3.51 uses ODBC SDK 3.51 and is in wide production use.
Some issues brought up appear to be application-related and independent of
the ODBC driver or underlying database server.
MySQL 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. This is only a rough guide and is not intended to be definitive. For the most up-to-date information, be sure to check the documentation specific to your operating system.
| Operating System | File-size Limit |
| 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 (possibly larger) |
| MacOS X w/ HFS+ | 2TB |
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 (up to 2TB). Most
current Linux distributions are based on kernel 2.4 and already include all
the required LFS patches. With JFS and XFS, petabyte and larger files
are possible on Linux. 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.
Windows users please note: FAT and VFAT (FAT32) are not considered suitable for production use with MySQL. Use NTFS instead.
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.
See section 13.5.4 SHOW Syntax.
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.
See section 13.2.6 CREATE TABLE Syntax.
You can also change these options with ALTER TABLE after the table has
been created, to increase the table's maximum allowable size.
See section 13.2.2 ALTER TABLE Syntax.
Other ways to work around file-size limits for MyISAM tables are as
follows:
myisampack to
compress it. myisampack usually compresses a table by at
least 50%, so you can have, in effect, much bigger tables.
myisampack also can merge multiple tables into a single table.
See section 8.2 myisampack, the MySQL Compressed Read-only Table Generator.
MyISAM
data files is by using the RAID options.
See section 13.2.6 CREATE TABLE Syntax.
MERGE library that allows
you to handle a collection of MyISAM tables that have identical
structure as a single MERGE table.
See section 14.2 The MERGE Storage Engine.
The MySQL Server itself has no problems with Year 2000 (Y2K) compliance:
2037 for TIMESTAMP values. For DATE and DATETIME
values, dates through the year 9999 are accepted.
YEAR column type
can store years 0 and 1901 to 2155 in one byte and
display them using two or four digits.
All two-digit years are considered to be in the range
1970 to 2069, which means that if you store 01 in a
YEAR column, MySQL Server treats it as 2001.
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
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. See section 11.3.4 Y2K Issues and Date Types for MySQL Server's rules for dealing with ambiguous date input data that contains two-digit year values.
This section provides a snapshot of the MySQL development roadmap, including major features implemented or planned for MySQL 4.0, 4.1, 5.0, and 5.1. The following sections provide information for each release series.
The current production release series is MySQL 4.1, which was declared stable for production use as of Version 4.1.7, released in October 2004. The previous production release series is MySQL 4.0, which was declared stable for production use as of Version 4.0.12, released in March 2003. Production status means that future 4.1 and 4.0 development is limited only to bugfixes. For the older MySQL 3.23 series, only critical bugfixes are made.
Active MySQL development currently is taking place in the MySQL 5.0 release series, this means that new features are being added there. MySQL 5.0 is available in alpha status.
Before upgrading from one release series to the next, please see the notes at section 2.10 Upgrading MySQL.
Plans for some of the most requested features are summarized in the following table.
| Feature | MySQL Series |
| Unions | 4.0 |
| Subqueries | 4.1 |
| R-trees | 4.1 (for MyISAM tables)
|
| Stored procedures | 5.0 |
| Views | 5.0 |
| Cursors | 5.0 |
| Foreign keys | 5.1 (already implemented in 3.23 for InnoDB)
|
| Triggers | 5.0 and 5.1 |
| Full outer join | 5.1 |
| Constraints | 5.1 |
MySQL Server 4.0 is available in production status.
MySQL 4.0 is available for download at http://dev.mysql.com/ and from our mirrors. MySQL 4.0 has been tested by a large number of users and is in production use at many large sites.
The major new features of MySQL Server 4.0 are geared toward our existing business and community users, enhancing the MySQL database software as the solution for mission-critical, heavy-load database systems. Other new features target the users of embedded databases.
INSERT statements, searching on
packed indexes, full-text searching (using FULLTEXT indexes), and
COUNT(DISTINCT).
InnoDB storage engine as standard
InnoDB storage engine is offered as a standard feature of the
MySQL server. This means full support for ACID transactions, foreign
keys with cascading UPDATE and DELETE, and row-level locking
are now standard features.
See section 15 The InnoDB Storage Engine.
FULLTEXT search properties of MySQL Server 4.0 enables
FULLTEXT indexing of large text masses with both binary
and natural-language searching logic. You can customize minimal word
length and define your own stop word lists in any human language,
enabling a new set of applications to be built with MySQL Server.
See section 12.6 Full-Text Search Functions.
UNION statement, a long-awaited standard SQL feature.
TRUNCATE TABLE (as in Oracle).
latin1_de, which ensures that the
German sorting order sorts words with umlauts in the same order
as do German telephone books.
mysqld parameters (startup options) can be set without taking
down the server. This is a convenient feature for database administrators
(DBAs).
See section 13.5.3 SET Syntax.
DELETE and UPDATE statements have been added.
MyISAM storage engine supports symbolic
linking at the table level (and not just the database level as before).
SQL_CALC_FOUND_ROWS and FOUND_ROWS() are new functions that make it
possible to find out the number of rows a SELECT query that includes a
LIMIT clause would have returned without that clause.
The news section of this manual includes a more in-depth list of features. See section D.3 Changes in release 4.0.x (Production).
The libmysqld embedded server library makes MySQL Server suitable for
a vastly expanded realm of applications. By using this library, developers can
embed MySQL Server into various applications and electronics devices, where
the end user has no knowledge of there actually being an underlying
database. Embedded MySQL Server is ideal for use behind
the scenes in Internet appliances, public kiosks, turnkey
hardware/software combination units, high performance Internet
servers, self-contained databases distributed on CD-ROM, and so on.
Many users of libmysqld will benefit from the MySQL
Dual Licensing. For those not wishing to be bound by the GPL,
the software is also made available under a commercial license.
See http://www.mysql.com/company/legal/licensing/ for more information
on the licensing policy of MySQL AB.
The embedded MySQL library uses the same interface as the normal
client library, so it is convenient and easy to use.
See section 21.2.16 libmysqld, the Embedded MySQL Server Library.
On Windows there are two different libraries:
libmysqld.lib | Dynamic library for threaded applications. |
mysqldemb.lib | Static library for not threaded applications. |
MySQL Server 4.0 laid the foundation for new features implemented in MySQL 4.1, such as subqueries and Unicode support, and for the work on stored procedures being done in version 5.0. These features come at the top of the wish list of many of our customers. Already well-known for its stability, speed, and ease of use, MySQL Server is now able to fulfill the requirement checklists of very demanding buyers.
MySQL Server 4.1 is currently in production status, and binaries are available for download at http://dev.mysql.com/downloads/mysql/4.1.html. All binary releases pass our extensive test suite without any errors on the platforms on which we test. See section D.2 Changes in release 4.1.x (Production).
For those wishing to use the most recent development source for MySQL 4.1, we also make our BitKeeper repositories publicly available. See section 2.8.3 Installing from the Development Source Tree.
This section lists features implemented in MySQL 4.1. New features that will be available in MySQL 5.0 are described in section C.1 New Features Planned for 5.0.
SELECT statement nested within another statement.
A ``derived table'' (an unnamed view) is a subquery in the FROM clause
of another statement.
See section 13.1.8 Subquery Syntax.
BTREE indexing is supported for HEAP tables,
significantly improving response time for non-exact searches.
CREATE TABLE tbl_name2 LIKE tbl_name1 allows you to create, with
a single statement, a new table with a structure exactly like that of an
existing table.
MyISAM storage engine supports
OpenGIS spatial types for storing geographical data.
See section 18 Spatial Extensions in MySQL.
SHOW WARNINGS shows warnings for the last command.
See section 13.5.4.20 SHOW WARNINGS Syntax.
utf8 and ucs2 character sets.
HELP command that can be used
to get help information for SQL statements.
The advantage of having this information on the server side is that the
information is always applicable to the particular server version that you
actually are using.
Because this information is available by issuing an SQL statement, any client
can be written to access it.
For example, the help command of the mysql command-line client
has been modified to have this capability.
INSERT ... ON DUPLICATE KEY UPDATE ... syntax has been
implemented. This allows you to UPDATE an existing row if the
INSERT would have caused a duplicate in a PRIMARY or
UNIQUE index.
See section 13.1.4 INSERT Syntax.
GROUP_CONCAT()
adds the extremely useful capability of concatenating column values from
grouped rows into a single result string.
See section 12.9 Functions and Modifiers for Use with GROUP BY Clauses.
The news section of this manual includes a more in-depth list of features. See section D.2 Changes in release 4.1.x (Production).
New development for MySQL is focused on the 5.0 release, featuring stored procedures, views (including updatable views), rudimentary triggers, and other new features. See section C.1 New Features Planned for 5.0.
For those wishing to take a look at the bleeding edge of MySQL development, we make our BitKeeper repository for MySQL version 5.0 publicly available. See section 2.8.3 Installing from the Development Source Tree. As of December 2003, binary builds of version 5.0 have also been available.
This section introduces the MySQL mailing lists and provides guidelines as to how the lists should be used. When you subscribe to a mailing list, you will receive all postings to the list as email messages. You can also send your own questions and answers to the list.
To subscribe to or unsubscribe from any of the mailing lists described in this section, visit http://lists.mysql.com/. For most of them, you can select the regular version of the list where you get individual messages, or a digest version where you get one large message per day.
Please do not send messages about subscribing or unsubscribing to any of the mailing lists, because such messages are distributed automatically to thousands of other users.
Your local site may have many subscribers to a MySQL mailing list.
If so, the site may have a local mailing list, so that messages sent from
lists.mysql.com to your site are propagated to the local list. In such
cases, please contact your system administrator to be added to or dropped
from the local MySQL list.
If you wish to have traffic for a mailing list go to a separate mailbox in
your mail program, set up a filter based on the message headers. You can
use either the List-ID: or Delivered-To: headers to identify
list messages.
The MySQL mailing lists are as follows:
announce
mysql
bugs
internals
mysqldoc
benchmarks
packagers
java
win32
myodbc
gui-tools
MySQL
Administrator and the MySQL Control Center graphical client.
cluster
dotnet
plusplus
perl
DBD::mysql.
If you're unable to get an answer to your questions from a MySQL mailing list, one option is to purchase support from MySQL AB. This will put you in direct contact with MySQL developers.
The following table shows some MySQL mailing lists in languages other than English. These lists are not operated by MySQL AB.
mysql-france-subscribe@yahoogroups.com
list@tinc.net
subscribe mysql your@email.address to this list.
mysql-de-request@lists.4t2.com
subscribe mysql-de your@email.address to this list.
You can find information about this mailing list at
http://www.4t2.com/mysql/.
mysql-br-request@listas.linkway.com.br
subscribe mysql-br your@email.address to this list.
mysql-alta@elistas.net
subscribe mysql your@email.address to this list.
Before posting a bug report or question, please do the following:
If you can't find an answer in the manual or the archives, check with your local MySQL expert. If you still can't find an answer to your question, please follow the guidelines on sending mail to a MySQL mailing list, outlined in the next section, before contacting us.
The normal place to report bugs is http://bugs.mysql.com/, which is the address for our bugs database. This database is public, and can be browsed and searched by anyone. If you log in to the system, you will also be able to enter new reports.
Writing a good bug report takes patience, but doing it right the first time saves time both for us and for yourself. A good bug report, containing a full test case for the bug, makes it very likely that we will fix the bug in the next release. This section will help you write your report correctly so that you don't waste your time doing things that may not help us much or at all.
We encourage everyone to use the mysqlbug script to generate a bug
report (or a report about any problem). mysqlbug can be
found in the `scripts' directory (source distribution) and in the
`bin' directory under your MySQL installation directory (binary distribution).
If you are unable to use mysqlbug (for example, if you are running
on Windows), it is still vital that you include all the necessary information
noted in this section (most importantly, a description of the operating system
and the MySQL version).
The mysqlbug script helps you generate a report by determining much
of the following information automatically, but if something important is
missing, please include it with your message. Please read this section
carefully and make sure that all the information described here is included
in your report.
Preferably, you should test the problem using the latest production or
development version of MySQL Server before posting. Anyone should be
able to repeat the bug by just using mysql test < script_file on the
included test case or by running the shell or Perl script that is included in the
bug report.
All bugs posted in the bugs database at http://bugs.mysql.com/ will be corrected or documented in the next MySQL release. If only minor code changes are needed to correct a problem, we may also post a patch that fixes the problem.
If you have found a sensitive security bug in MySQL, you can send email to security@mysql.com.
If you have a repeatable bug report, please report it to the bugs
database at http://bugs.mysql.com/. Note that even in this case
it's good to run the mysqlbug script first to find information
about your system. Any bug that we are able to repeat has a high chance
of being fixed in the next MySQL release.
To report other problems, you can use one of the MySQL mailing lists.
Remember that it is possible for us to respond to a message containing too much information, but not to one containing too little. People often omit facts because they think they know the cause of a problem and assume that some details don't matter. A good principle is this: If you are in doubt about stating something, state it. It is faster and less troublesome to write a couple more lines in your report than to wait longer for the answer if we must ask you to provide information that was missing from the initial report.
The most common errors made in bug reports are (a) not including the version number of the MySQL distribution used, and (b) not fully describing the platform on which the MySQL server is installed (including the platform type and version number). This is highly relevant information, and in 99 cases out of 100, the bug report is useless without it. Very often we get questions like, ``Why doesn't this work for me?'' Then we find that the feature requested wasn't implemented in that MySQL version, or that a bug described in a report has already been fixed in newer MySQL versions. Sometimes the error is platform-dependent; in such cases, it is next to impossible for us to fix anything without knowing the operating system and the version number of the platform.
If you compiled MySQL from source, remember also to provide information about your compiler, if it is related to the problem. Often people find bugs in compilers and think the problem is MySQL-related. Most compilers are under development all the time and become better version by version. To determine whether your problem depends on your compiler, we need to know what compiler you use. Note that every compiling problem should be regarded as a bug and reported accordingly.
It is most helpful when a good description of the problem is included in the bug report. That is, give a good example of everything you did that led to the problem and describe, in exact detail, the problem itself. The best reports are those that include a full example showing how to reproduce the bug or problem. See section E.1.6 Making a Test Case If You Experience Table Corruption.
If a program produces an error message, it is very important to include the message in your report. If we try to search for something from the archives using programs, it is better that the error message reported exactly matches the one that the program produces. (Even the lettercase should be observed.) You should never try to reproduce from memory what the error message was; instead, copy and paste the entire message into your report.
If you have a problem with Connector/ODBC (MyODBC), please try to generate a trace file and send it with your report. See section 22.1.1.9 How to Report MyODBC Problems or Bugs.
Please remember that many of the people who will read your report will
do so using an 80-column display. When generating reports or examples
using the mysql command-line tool, you should therefore use
the --vertical option (or the \G statement terminator)
for output that would exceed the available width for such a display
(for example, with the EXPLAIN SELECT statement; see the
example later in this section).
Please include the following information in your report:
mysqladmin version. The mysqladmin
program can be found in the `bin' directory under your MySQL
installation directory.
uname -a.
mysqld died, you should also report the query that crashed
mysqld. You can usually find this out by running mysqld with
query logging enabled, and then looking in the log after mysqld crashes
See section E.1.5 Using Log Files to Find Cause of Errors in mysqld.
mysqldump --no-data db_name tbl_name. This is very easy
to do and is a powerful way to get information about any table in a database.
The information will help us create a situation matching the one you have.
SELECT statements, you
should always include the output of EXPLAIN SELECT ..., and at
least the number of rows that the SELECT statement produces. You
should also include the output from SHOW CREATE TABLE tbl_name
for each involved table. The more information you give about your
situation, the more likely it is that someone can help you.
The following is an example of a very good bug report. It should be posted
with the mysqlbug script. The example uses the mysql
command-line tool. Note the use of the \G statement terminator for
statements whose output width would otherwise exceed that of an 80-column
display device.
mysql> SHOW VARIABLES;
mysql> SHOW COLUMNS FROM ...\G
<output from SHOW COLUMNS>
mysql> EXPLAIN SELECT ...\G
<output from EXPLAIN>
mysql> FLUSH STATUS;
mysql> SELECT ...;
<A short version of the output from SELECT,
including the time taken to run the query>
mysql> SHOW STATUS;
<output from SHOW STATUS>
mysqld, try to provide an
input script that will reproduce the anomaly. This script should include any
necessary source files. The more closely the script can reproduce your
situation, the better. If you can make a reproducible test case, you should
post it on http://bugs.mysql.com/ for high-priority treatment.
If you can't provide a script, you should at least include the output
from mysqladmin variables extended-status processlist in your mail to
provide some information on how your system is performing.
mysqldump and create a `README' file
that describes your problem.
Create a compressed archive of your files using
tar and gzip or zip, and use FTP to transfer the
archive to ftp://ftp.mysql.com/pub/mysql/upload/. Then enter
the problem into our bugs database at http://bugs.mysql.com/.
mysqld
server as well as the options that you use to run any MySQL client programs.
The options to programs such as mysqld and mysql, and to the
configure script, are often keys to answers and are very relevant.
It is never a bad idea to include them. If you use any modules, such
as Perl or PHP, please include the version numbers of those as well.
mysqlaccess, the output of mysqladmin reload, and all
the error messages you get when trying to connect. When you test your
privileges, you should first run mysqlaccess. After this, execute
mysqladmin reload version and try to connect with the program that
gives you trouble. mysqlaccess can be found in the `bin'
directory under your MySQL installation directory.
parse error, please check your syntax closely. If
you can't find something wrong with it, it's extremely likely that your
current version of MySQL Server doesn't support the syntax you are
using. If you are using the current version and the manual at
http://dev.mysql.com/doc/ doesn't cover the
syntax you are using, MySQL Server doesn't support your query. In this
case, your only options are to implement the syntax yourself or email
licensing@mysql.com and ask for an offer to implement it.
If the manual covers the syntax you are using, but you have an older version
of MySQL Server, you should check the MySQL change history to see
when the syntax was implemented. In this case, you have the option of
upgrading to a newer version of MySQL Server. See section D MySQL Change History.
CHECK TABLE and REPAIR TABLE
or with myisamchk.
See section 5 Database Administration.
If you are running Windows, please verify that lower_case_table_names
is 1 or 2 with SHOW VARIABLES LIKE 'lower_case_table_names'.
mysqld should never crash a table if nothing killed it in the
middle of an update. If you can find the cause of mysqld dying,
it's much easier for us to provide you with a fix for the problem.
See section A.1 How to Determine What Is Causing a Problem.
If you are a support customer, please cross-post the bug report to mysql-support@mysql.com for higher-priority treatment, as well as to the appropriate mailing list to see whether someone else has experienced (and perhaps solved) the problem.
For information on reporting bugs in MyODBC, see section 22.1.1.9 How to Report MyODBC Problems or Bugs.
For solutions to some common problems, see section A Problems and Common Errors.
When answers are sent to you individually and not to the mailing list, it is considered good etiquette to summarize the answers and send the summary to the mailing list so that others may have the benefit of responses you received that helped you solve your problem.
If you consider your answer to have broad interest, you may want to post it to the mailing list instead of replying directly to the individual who asked. Try to make your answer general enough that people other than the original poster may benefit from it. When you post to the list, please make sure that your answer is not a duplication of a previous answer.
Try to summarize the essential part of the question in your reply; don't feel obliged to quote the entire original message.
Please don't post mail messages from your browser with HTML mode turned on. Many users don't read mail with a browser.
In addition to the various MySQL mailing lists, you can find experienced
community people on IRC (Internet Relay Chat).
These are the best networks/channels currently known to us:
#mysql
Primarily MySQL questions, but other database and general SQL questions are welcome.
Questions about PHP, Perl or C in combination with MySQL are also common.
#mysql
MySQL questions.
If you are looking for IRC client software to connect to an IRC network,
take a look at X-Chat (http://www.xchat.org/).
X-Chat (GPL licensed) is available for Unix as well as for Windows platforms.
The latest community support resource are the forums at http://forums.mysql.com.
There are a variety of forums available, grouped in the following general categories:
This section describes how MySQL relates to the ANSI/ISO SQL standards. MySQL Server has many extensions to the SQL standard, and here you will find out what they are and how to use them. You will also find information about functionality missing from MySQL Server, and how to work around some differences.
The SQL standard has been evolving since 1986 and several versions exist. In this manual, ``SQL-92'' refers to the standard released in 1992, ``SQL:1999'' refers to the standard released in 1999, and ``SQL:2003'' refers to the current version of the standard. We use the phrase ``the SQL standard'' to mean the current version of the SQL Standard at any time.
Our goal is to not restrict MySQL Server usability for any usage without a very good reason for doing so. Even if we don't have the resources to perform development for every possible use, we are always willing to help and offer suggestions to people who are trying to use MySQL Server in new territories.
One of our main goals with the product is to continue to work toward
compliance with the SQL standard, but without sacrificing speed or reliability.
We are not afraid to add extensions to SQL or support for non-SQL
features if this greatly increases the usability of MySQL Server for a large
segment of our user base.
The HANDLER interface in MySQL Server 4.0 is an example of this
strategy. See section 13.1.3 HANDLER Syntax.
We will continue to support transactional and non-transactional databases to satisfy both mission-critical 24/7 usage and heavy Web or logging usage.
MySQL Server was originally designed to work with medium size databases (10-100 million rows, or about 100MB per table) on small computer systems. Today MySQL Server handles terabyte-size databases, but the code can also be compiled in a reduced version suitable for hand-held and embedded devices. The compact design of the MySQL server makes development in both directions possible without any conflicts in the source tree.
Currently, we are not targeting realtime support, although MySQL replication capabilities already offer significant functionality.
Database cluster support now exists through third-party clustering solutions as well as the integration of our acquired NDB Cluster technology into a new storage engine, available from version 4.1.2. See section 16 MySQL Cluster.
We are also looking at providing XML support in the database server.
We are aiming toward supporting the full ANSI/ISO SQL standard, but without making concessions to speed and quality of the code.
ODBC levels 0-3.51.
The MySQL server can operate in different SQL modes, and can apply these modes differentially for different clients. This allows an application to tailor server operation to its own requirements.
Modes define what SQL syntax MySQL should support and what kind of validation checks it should perform on the data. This makes it easier to use MySQL in a lot of different environments and to use MySQL together with other database servers.
You can set the default SQL mode by starting mysqld with the
--sql-mode="modes" option. Beginning with MySQL 4.1, you can also
change the mode after startup time by setting the sql_mode variable
with a SET [SESSION|GLOBAL] sql_mode='modes' statement.
For more information on setting the server mode, see section 5.2.2 The Server SQL Mode.
You can tell mysqld to use the ANSI mode with the --ansi
startup option. See section 5.2.1 mysqld Command-Line Options.
Running the server in ANSI mode is the same as starting it with these options
(specify the --sql_mode value on a single line):
--transaction-isolation=SERIALIZABLE --sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES, IGNORE_SPACE,ONLY_FULL_GROUP_BY
In MySQL 4.1, you can achieve the same effect with these two statements
(specify the sql_mode value on a single line):
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET GLOBAL sql_mode = 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES, IGNORE_SPACE,ONLY_FULL_GROUP_BY';
See section 1.5.2 Selecting SQL Modes.
In MySQL 4.1.1, the sql_mode options shown can be also be set with
this statement:
SET GLOBAL sql_mode='ansi';
In this case, the value of the sql_mode variable will be set to all
options that are relevant for ANSI mode. You can check the result like this:
mysql> SET GLOBAL sql_mode='ansi';
mysql> SELECT @@global.sql_mode;
-> 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,
IGNORE_SPACE,ONLY_FULL_GROUP_BY,ANSI';
MySQL Server includes some extensions that you probably will not find in
other SQL databases. Be warned that if you use them, your code will not be
portable to other SQL servers. In some cases, you can write code that
includes MySQL extensions, but is still portable, by using comments
of the form /*! ... */. In this case, MySQL Server will parse and
execute the code within the comment as it would any other MySQL
statement, but other SQL servers will ignore the extensions. For example:
SELECT /*! STRAIGHT_JOIN */ col_name FROM table1,table2 WHERE ...
If you add a version number after the `!' character, the syntax within the comment will be executed only if the MySQL version is equal to or newer than the specified version number:
CREATE /*!32302 TEMPORARY */ TABLE t (a INT);
This means that if you have Version 3.23.02 or newer, MySQL
Server will use the TEMPORARY keyword.
The following descriptions list MySQL extensions, organized by category.
MyISAM or ISAM storage engines.
For example, to rename a MyISAM table, rename the `.MYD',
`.MYI', and `.frm' files to which the table corresponds.
User space.
MySQL Server doesn't support tablespaces such as used in statements like this:
CREATE TABLE ralph.my_table...IN my_tablespace.
ANALYZE TABLE, CHECK TABLE, OPTIMIZE TABLE, and
REPAIR TABLE statements.
CREATE DATABASE and DROP DATABASE statements.
See section 13.2.4 CREATE DATABASE Syntax.
DO statement.
EXPLAIN SELECT to get a description of how tables are joined.
FLUSH and RESET statements.
SET statement. See section 13.5.3 SET Syntax.
SHOW statement.
See section 13.5.4 SHOW Syntax.
LOAD DATA INFILE. In many cases, this syntax is compatible with
Oracle's LOAD DATA INFILE. See section 13.1.5 LOAD DATA INFILE Syntax.
RENAME TABLE. See section 13.2.12 RENAME TABLE Syntax.
REPLACE instead of DELETE + INSERT.
See section 13.1.6 REPLACE Syntax.
CHANGE col_name, DROP col_name, or DROP
INDEX, IGNORE or RENAME in an ALTER TABLE
statement.
Use of multiple ADD, ALTER, DROP, or CHANGE
clauses in an ALTER TABLE statement.
See section 13.2.2 ALTER TABLE Syntax.
INDEX or KEY in a CREATE TABLE
statement. See section 13.2.6 CREATE TABLE Syntax.
TEMPORARY or IF NOT EXISTS with CREATE TABLE.
IF EXISTS with DROP TABLE.
DROP TABLE statement.
ORDER BY and LIMIT clauses of the UPDATE and
DELETE statements.
INSERT INTO ... SET col_name = ... syntax.
DELAYED clause of the INSERT and REPLACE
statements.
LOW_PRIORITY clause of the INSERT, REPLACE,
DELETE, and UPDATE statements.
INTO OUTFILE and STRAIGHT_JOIN in a SELECT
statement. See section 13.1.7 SELECT Syntax.
SQL_SMALL_RESULT option in a SELECT statement.
GROUP BY part.
This gives better performance for some very specific, but quite normal
queries.
See section 12.9 Functions and Modifiers for Use with GROUP BY Clauses.
ASC and DESC with GROUP BY.
:= assignment
operator:
mysql> SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg
-> FROM test_table;
mysql> SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
MEDIUMINT, SET, ENUM, and the
different BLOB and TEXT types.
AUTO_INCREMENT, BINARY, NULL,
UNSIGNED, and ZEROFILL.
|| and && operators to mean
logical OR and AND, as in the C programming language. In MySQL Server,
|| and OR are synonyms, as are && and AND.
Because of this nice syntax, MySQL Server doesn't support
the standard SQL || operator for string concatenation; use
CONCAT() instead. Because CONCAT() takes any number
of arguments, it's easy to convert use of the || operator to
MySQL Server.
COUNT(DISTINCT list) where list has more than one element.
BINARY attribute or use the BINARY cast, which causes
comparisons to be done using the underlying character code values rather
then a lexical ordering.
% operator is a synonym for MOD(). That is,
N % M is equivalent to MOD(N,M). % is supported
for C programmers and for compatibility with PostgreSQL.
=, <>, <= ,<, >=,>,
<<, >>, <=>, AND, OR, or LIKE
operators may be used in column comparisons to the left of the
FROM in SELECT statements. For example:
mysql> SELECT col1=1 AND col2=2 FROM tbl_name;
LAST_INSERT_ID() function that returns the most recent
AUTO_INCREMENT value.
See section 12.8.3 Information Functions.
LIKE is allowed on numeric columns.
REGEXP and NOT REGEXP extended regular expression
operators.
CONCAT() or CHAR() with one argument or more than two
arguments. (In MySQL Server, these functions can take any number of
arguments.)
BIT_COUNT(), CASE, ELT(),
FROM_DAYS(), FORMAT(), IF(), PASSWORD(),
ENCRYPT(), MD5(), ENCODE(), DECODE(),
PERIOD_ADD(), PERIOD_DIFF(), TO_DAYS(), and
WEEKDAY() functions.
TRIM() to trim substrings. Standard SQL supports removal
of single characters only.
GROUP BY functions STD(), BIT_OR(),
BIT_AND(), BIT_XOR(), and GROUP_CONCAT().
See section 12.9 Functions and Modifiers for Use with GROUP BY Clauses.
For a prioritized list indicating when new extensions will be added to MySQL Server, you should consult the online MySQL TODO list at http://dev.mysql.com/doc/mysql/en/TODO.html. That is the latest version of the TODO list in this manual. See section C MySQL and the Future (the TODO).
We try to make MySQL Server follow the ANSI SQL standard and the ODBC SQL standard, but MySQL Server performs operations differently in some cases:
VARCHAR columns, trailing spaces are removed when the value is
stored. (Fixed in MySQL 5.0.3). See section 1.5.7 Known Errors and Design Deficiencies in MySQL.
CHAR columns are silently converted to VARCHAR
columns when you define a table or alter its structure. (Fixed in MySQL 5.0.3).
See section 13.2.6.1 Silent Column Specification Changes.
REVOKE statement to revoke
privileges for a table. See section 13.5.1.2 GRANT and REVOKE Syntax.
MySQL 4.1 supports subqueries and derived tables.
A ``subquery'' is a SELECT statement nested within another statement.
A ``derived table'' (an unnamed view) is a subquery in the FROM clause
of another statement.
See section 13.1.8 Subquery Syntax.
For MySQL versions older than 4.1, most subqueries can be rewritten using joins or other methods. See section 13.1.8.11 Rewriting Subqueries as Joins for Earlier MySQL Versions for examples that show how to do this.
SELECT INTO TABLE
MySQL Server doesn't support the Sybase SQL extension:
SELECT ... INTO TABLE .... Instead, MySQL Server supports the
standard SQL syntax INSERT INTO ... SELECT ..., which is basically
the same thing. See section 13.1.4.1 INSERT ... SELECT Syntax.
INSERT INTO tbl_temp2 (fld_id)
SELECT tbl_temp1.fld_order_id
FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;
Alternatively, you can use SELECT INTO OUTFILE ... or
CREATE TABLE ... SELECT.
From version 5.0, MySQL supports SELECT ... INTO with user
variables. The same syntax may also be used inside stored procedures using
cursors and local variables.
See section 19.1.6.3 SELECT ... INTO Statement.
MySQL Server (version 3.23-max and all versions 4.0 and above) supports
transactions with the InnoDB and BDB
transactional storage engines.
InnoDB provides full ACID compliance.
See section 14 MySQL Storage Engines and Table Types.
The other non-transactional storage engines in MySQL Server (such as
MyISAM) follow a different paradigm for data integrity called
``atomic operations.'' In transactional terms, MyISAM
tables effectively always operate in AUTOCOMMIT=1 mode.
Atomic operations often offer comparable integrity with higher performance.
With MySQL Server supporting both paradigms, you can decide whether your applications are best served by the speed of atomic operations or the use of transactional features. This choice can be made on a per-table basis.
As noted, the trade-off for transactional versus non-transactional table
types lies mostly in performance. Transactional tables have significantly
higher memory and diskspace requirements, and more CPU overhead.
On the other hand, transactional table types such as InnoDB also
offer many significant features. MySQL Server's modular design allows the
concurrent use of different storage engines to suit different
requirements and deliver optimum performance in all situations.
But how do you use the features of MySQL Server to maintain rigorous
integrity even with the non-transactional MyISAM tables, and how
do these features compare with the transactional table types?
ROLLBACK rather than
COMMIT in critical situations, transactions are more
convenient. Transactions also ensure that unfinished updates or
corrupting activities are not committed to the database; the server is
given the opportunity to do an automatic rollback and your database is
saved.
If you use non-transactional tables,
MySQL Server in almost all cases allows you to resolve potential problems
by including simple checks before updates and by running simple scripts
that check the databases for inconsistencies and automatically repair
or warn if such an inconsistency occurs. Note that just by using the
MySQL log or even adding one extra log, you can normally fix tables
perfectly with no data integrity loss.
LOCK TABLES or atomic updates, ensuring
that you never will get an automatic abort from the server, which is
a common problem with transactional database systems.
The transactional paradigm has its benefits and its drawbacks. Many users and application developers depend on the ease with which they can code around problems where an abort appears to be, or is necessary. However, even if you are new to the atomic operations paradigm, or more familiar with transactions, do consider the speed benefit that non-transactional tables can offer on the order of three to five times the speed of the fastest and most optimally tuned transactional tables.
In situations where integrity is of highest importance, MySQL Server offers
transaction-level reliability and integrity even for non-transactional tables.
If you lock tables with LOCK TABLES, all updates will stall
until any integrity checks are made. If you obtain a READ LOCAL lock
(as opposed to a write lock) for a table that allows concurrent inserts at the
end of the table, reads are allowed, as are inserts by other clients.
The new inserted records will not be seen by the
client that has the read lock until it releases the lock.
With INSERT DELAYED, you can queue inserts into a local
queue, until the locks are released, without having the client wait
for the insert to complete. See section 13.1.4.2 INSERT DELAYED Syntax.
``Atomic,'' in the sense that we mean it, is nothing magical. It only means that you can be sure that while each specific update is running, no other user can interfere with it, and there will never be an automatic rollback (which can happen with transactional tables if you are not very careful). MySQL Server also guarantees that there will not be any dirty reads.
Following are some techniques for working with non-transactional tables:
LOCK TABLES, and you don't need cursors to update
records on the fly.
ROLLBACK, you can use the following strategy:
LOCK TABLES to lock all the tables you want to access.
UNLOCK TABLES to release your locks.
WHERE clause in the UPDATE statement. If the record wasn't
updated, we give the client a message: ``Some of the data you have changed
has been changed by another user.'' Then we show the old row versus the new
row in a window so that the user can decide which version of the customer
record to use.
This gives us something that is similar to column locking but is actually
even better because we only update some of the columns, using values that
are relative to their current values. This means that typical UPDATE
statements look something like these:
UPDATE tablename SET pay_back=pay_back+125;
UPDATE customer
SET
customer_date='current_date',
address='new address',
phone='new phone',
money_owed_to_us=money_owed_to_us-125
WHERE
customer_id=id AND address='old address' AND phone='old phone';
This is very efficient and works even if another client
has changed the values in the pay_back or money_owed_to_us
columns.
LOCK TABLES and/or ROLLBACK
for the purpose of managing unique identifiers. This can be handled much
more efficiently without locking or rolling back by using an
AUTO_INCREMENT column and either the
LAST_INSERT_ID() SQL function or the mysql_insert_id() C API function.
See section 12.8.3 Information Functions.
See section 21.2.3.33 mysql_insert_id().
You can generally code around the need for row-level locking. Some situations
really do need it, and InnoDB tables support row-level locking. With
MyISAM tables, you can use a flag column in the table and do something
like the following:
UPDATE tbl_name SET row_flag=1 WHERE id=ID;MySQL returns 1 for the number of affected rows if the row was found and
row_flag wasn't already 1 in the original row.
You can think of it as though MySQL Server changed the preceding query to:
UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;
Stored procedures are implemented in MySQL version 5.0. See section 19 Stored Procedures and Functions.
Triggers are currently being implemented, with basic functionality in MySQL 5.0, with further development planned for MySQL 5.1.
In MySQL Server 3.23.44 and up, the InnoDB storage engine supports
checking of foreign key constraints, including CASCADE, ON
DELETE, and ON UPDATE. See section 15.7.4 FOREIGN KEY Constraints.
For storage engines other than InnoDB, MySQL Server parses the
FOREIGN KEY syntax in CREATE TABLE statements, but does not
use or store it. In the future, the implementation will be
extended to store this information in the table specification file so that it
may be retrieved by mysqldump and ODBC. At a later stage,
foreign key constraints will be implemented for MyISAM tables as well.
Foreign key enforcement offers several benefits to database developers:
Do keep in mind that these benefits come at the cost of additional overhead for the database server to perform the necessary checks. Additional checking by the server affects performance, which for some applications may be sufficiently undesirable as to be avoided if possible. (Some major commercial applications have coded the foreign-key logic at the application level for this reason.)
MySQL gives database developers the choice of which approach to use. If you
don't need foreign keys and want to avoid the overhead associated with
enforcing referential integrity, you can choose another table type instead,
such as MyISAM. (For example, the MyISAM storage engine offers
very fast performance for applications that perform only INSERT and
SELECT operations, because the inserts can be performed concurrently
with retrievals. See section 7.3.2 Table Locking Issues.)
If you choose not to take advantage of referential integrity checks, keep the following considerations in mind:
ON DELETE is the only referential integrity capability an
application needs, note that as of MySQL Server 4.0, you can use
multiple-table DELETE statements to delete rows from many
tables with a single statement. See section 13.1.1 DELETE Syntax.
ON DELETE is to add
the appropriate DELETE statement to your application when you
delete records from a table that has a foreign key. In practice, this is often
as quick as using foreign keys, and is more portable.
Be aware that the use of foreign keys can in some instances lead to problems:
FOREIGN KEY Constraints.
As of MySQL 4.1.1,
mysqldump generates dump files that take advantage of this
capability automatically when reloaded.)
Note that foreign keys in SQL are used to check and enforce referential
integrity, not to join tables. If you want to get results from multiple
tables from a SELECT statement, you do this by performing a join
between them:
SELECT * FROM t1, t2 WHERE t1.id = t2.id;
See section 13.1.7.1 JOIN Syntax. See section 3.6.6 Using Foreign Keys.
The FOREIGN KEY syntax without ON DELETE ... is often used
by ODBC applications to produce automatic WHERE clauses.
Views (including updatable views) are being implemented in the 5.0 version
of MySQL Server. They are already available in binary releases from 5.0.1
and up.
See section 13.2.7 CREATE VIEW Syntax.
Views are useful for allowing users to access a set of relations (tables) as if it were a single table, and limiting their access to just that. Views can also be used to restrict access to rows (a subset of a particular table). For access control to columns, you can also use the sophisticated privilege system in MySQL Server. See section 5.5 The MySQL Access Privilege System.
In designing an implementation of views, our ambitious goal, as much as is possible within the confines of SQL, has been full compliance with ``Codd's Rule #6'' for relational database systems: ``All views that are theoretically updatable, should in practice also be updatable.''
Some other SQL databases use `--' to start comments.
MySQL Server uses `#' as the start comment character. You can also use
the C comment style /* this is a comment */ with MySQL Server.
See section 9.5 Comment Syntax.
MySQL Server 3.23.3 and above support the `--' comment style,
provided the comment is followed by a space (or by a control character such
as a newline). The requirement for a space is to prevent problems with
automatically generated SQL queries that have used something like the following code, where we automatically insert the value of the payment for
!payment!:
UPDATE account SET credit=credit-!payment!
Think about what happens if the value of payment is a negative value
such as -1:
UPDATE account SET credit=credit--1
credit--1 is a legal expression in SQL, but if -- is interpreted
as the start of a comment, part of the expression is discarded. The result is a
statement that has a completely different meaning than intended:
UPDATE account SET credit=credit
The statement produces no change in value at all! This illustrates that allowing comments to start with `--' can have serious consequences.
Using our implementation of this method of commenting in MySQL Server
3.23.3 and up, credit--1 is actually safe.
Another safe feature is that the mysql command-line client
removes all lines that start with `--'.
The following information is relevant only if you are running a MySQL version earlier than 3.23.3:
If you have an SQL program in a text file that contains `--'
comments, you should use the replace utility as follows to convert the
comments to use `#' characters:
shell> replace " --" " #" < text-file-with-funny-comments.sql \
| mysql db_name
instead of the usual:
shell> mysql db_name < text-file-with-funny-comments.sql
You can also edit the command file ``in place'' to change the `--' comments to `#' comments:
shell> replace " --" " #" -- text-file-with-funny-comments.sql
Change them back with this command:
shell> replace " #" " --" -- text-file-with-funny-comments.sql
MySQL allows you to work both with transactional tables that allow rollback and with non-transactional tables that do not. Because of this, constraint handling is a bit different in MySQL than in other databases. We must handle the case when you have inserted or updated a lot of rows in a non-transactional table for which changes cannot be rolled back when an error occurs.
The basic philosophy is that MySQL Server tries to produce an error for anything that it can detect while parsing a statement to be executed, and tries to recover from any errors that occur while executing the statement. We do this in most cases, but not yet for all. See section C.3 New Features Planned for the Near Future.
The options MySQL has when an error occurs are to stop the statement in the middle or to recover as well as possible from the problem and continue. By default, the server follows the latter course. This means, for example, that the server may coerce illegal values to the closest legal values.
Beginning with MySQL 5.0.2, several SQL mode options are available to provide greater control over how accepting to be of bad data values and whether to continue executing a statement or abort it when errors occur. Using these options, you can configure MySQL Server to act in a more traditional fashion that is like other DBMSs that reject improper input. The SQL mode can be set at runtime, which enables individual clients to select the behavior most appropriate for their requirements. See section 5.2.2 The Server SQL Mode.
The following sections describe what happens for the different types of constraints.
PRIMARY KEY and UNIQUE Index Constraints
Normally, an error occurs when you try to INSERT or UPDATE
a row that causes a primary key, unique key, or foreign key violation.
If you are using a transactional storage engine such as InnoDB, MySQL
automatically rolls back the statement. If you are using a non-transactional
storage engine, MySQL stops processing the statement at the row for which
the error occurred and leaves any remaining rows unprocessed.
If you wish to ignore such key violations, MySQL supports an IGNORE
keyword for INSERT and UPDATE. In this case, MySQL ignores
any key violations and continues processing with the next row.
See section 13.1.4 INSERT Syntax.
See section 13.1.10 UPDATE Syntax.
You can get information about the number of rows actually inserted or
updated with the mysql_info() C API function.
See section 21.2.3.31 mysql_info().
In MySQL 4.1 and up, you also can use the SHOW WARNINGS statement.
See section 13.5.4.20 SHOW WARNINGS Syntax.
For the moment, only InnoDB tables support foreign keys.
See section 15.7.4 FOREIGN KEY Constraints.
Foreign key support in MyISAM tables is scheduled for implementation
in MySQL 5.1.
Before MySQL 5.0.2, MySQL is forgiving of illegal or improper data values and coerces them to legal values for data entry. In MySQL 5.0.2 and up, that remains the default behavior, but you can select more traditional treatment of bad values such that the server rejects them and aborts the statement in which they occur. This section describes the default (forgiving) behavior of MySQL, as well as the newer strict SQL mode and how it differs.
The following holds true when you are not using strict mode.
If you insert an ``incorrect'' value into a column, such as a NULL
into a NOT NULL column or a too-large numeric value into a
numeric column, MySQL sets the column to the ``best possible value''
instead of producing an error:
NULL into a column that doesn't take NULL
values, MySQL Server stores 0 or '' (the empty string) instead.
DATE and
DATETIME columns (such as '2000-02-31' or '2000-02-00').
The idea is that it's not the job of the SQL server to validate dates. If
MySQL can store a date value and retrieve exactly the same value, MySQL
stores it as given. If the date is totally wrong (outside the server's
ability to store it), the special date value '0000-00-00' is stored
in the column instead.
INSERT statement specifies no value for a column, MySQL inserts
its default value if the column definition includes an explicit DEFAULT
clause. If the definition has no such DEFAULT clause, MySQL inserts
the implicit default value for the column data type. In general,
this is the empty string for string columns, 0 for numeric columns,
and '0000-00-00' for date columns. Implicit default values are
discussed in section 13.2.6 CREATE TABLE Syntax.
The reason for the preceding rules is that we can't check these conditions until the statement has begun executing. We can't just roll back if we encounter a problem after updating a few rows, because the storage engine may not support rollback. The option of terminating the statement is not that good; in this case, the update would be ``half done,'' which is probably the worst possible scenario. In this case, it's better to ``do the best you can'' and then continue as if nothing happened.
In MySQL 5.0.2 and up, you can select stricter treatment of input values by
using the STRICT_TRANS_TABLES or STRICT_ALL_TABLES SQL modes.
See section 5.2.2 The Server SQL Mode.
STRICT_TRANS_TABLES works like this: For transactional storage
engines, bad data values occurring anywhere in the statement causes
the to abort and roll back. For non-transactional storage engines,
the statement aborts if the error occurs in the first row to be inserted
or updated. (In this case, the statement can be regarded to leave the
table unchanged, just as for a transactional table.) Errors in rows
after the first do not abort the statement. Instead, bad data values
are adjusted and result in warnings rather than errors. In other words,
with STRICT_TRANS_TABLES, a wrong value causes MySQL to roll back,
if it can, all updates done so far.
For stricter checking, enable STRICT_ALL_TABLES. This is the same as
STRICT_TRANS_TABLES except that for non-transactional storage engines,
errors abort the statement even for bad data in rows following the first row.
This means that if an error occurs partway through a multiple-row insert or
update for a non-transactional table, a partial update results. Earlier rows
are inserted or updated, but those from the point of the error on are not.
To avoid this for non-transactional tables, either use single-row statements
or else use STRICT_TRANS_TABLES if conversion warnings rather than
errors are acceptable. To avoid problems in the first place, do not use
MySQL to check column content. It is safest (and often faster) to let the
application ensure that it passes only legal values to the database.
With either of the strict mode options, you can cause errors to be treated
as warnings by using INSERT IGNORE or UPDATE IGNORE.
ENUM and SET Constraints
ENUM and SET columns provide an efficient way to define columns
that can contain only a given set of values. However, before MySQL 5.0.2,
ENUM and SET are not real constraints. This is for the same
reasons that NOT NULL is not honored.
See section 1.5.6.2 Constraints on Invalid Data.
ENUM columns always have a default value. If you don't specify
a default value, then it will be NULL for columns that can have
NULL, otherwise the first enumeration value is used as the default
value.
If you insert an incorrect value into an ENUM column or if you
force a value into an ENUM column with IGNORE, it is set
to the reserved enumeration value of 0, which is displayed as an
empty string in string context. See section 11.4.4 The ENUM Type.
If you insert an incorrect value into a SET column, the incorrect value
is ignored. For example, if the column can contain the values
'a', 'b', and 'c', an attempt to assign 'a,x,b,y'
results in a value of 'a,b'.
See section 11.4.5 The SET Type.
As of MySQL 5.0.2, you can configure the server to use strict SQL mode.
See section 5.2.2 The Server SQL Mode.
When strict mode is not enabled, values entered into ENUM and SET
columns are handled as just described for MySQL 4.x. However, if strict
mode is enabled, the definition of a ENUM or SET column does
act as a constraint on values entered into the column. An error occurs
for values that do not satisify these conditions:
ENUM value must be one of those listed in the column definition, or
the internal numeric equivalent thereof. The value cannot be the error value
(that is, 0 or the empty string).
For a column defined as ENUM('a','b','c'), values such as '',
'd', and 'ax' are illegal and are rejected.
SET value must be the empty string or a value consisting of one or
more of the values listed in the column definition separated by commas.
For a column defined as SET('a','b','c'), values such as
'd', and 'a,b,c,d' are illegal and are rejected.
Errors for invalid values can be suppressed in strict mode if you use
INSERT IGNORE or UPDATE IGNORE. In this case, a warning is
generated rather than an error. For ENUM, the value is inserted as the
error member (0). For SET, the value is inserted as given except
that any invalid substrings are deleted. For example, 'a,x,b,y'
results in a value of 'a,b', as described earlier.
The following known errors or bugs are not fixed in MySQL 3.23 because fixing them would involve changing a lot of code that could introduce other even worse bugs. The bugs are also classified as ``not fatal'' or ``bearable.''
LOCK TABLE to lock
multiple tables and then in the same connection use DROP TABLE to
drop one of them while another thread is trying to lock it. (To break the
deadlock, you can use KILL to terminate any of the threads involved.)
This issue is resolved as of MySQL 4.0.12.
SELECT MAX(key_column) FROM t1,t2,t3... where one of the tables are
empty doesn't return NULL but instead returns the maximum value for the
column. This issue is resolved as of MySQL 4.0.11.
DELETE FROM heap_table without a WHERE clause doesn't work on
a locked HEAP table.
The following known errors or bugs are not fixed in MySQL 4.0 because fixing them would involve changing a lot of code that could introduce other even worse bugs. The bugs are also classified as ``not fatal'' or ``bearable.''
UNION, the first SELECT determines the type,
max_length, and NULL properties for the resulting
columns. This issue is resolved as of MySQL 4.1.1; the property values are
based on the rows from all UNION parts.
DELETE with many tables, you can't refer to tables to be
deleted through an alias. This is fixed as of MySQL 4.1.
UNION ALL and UNION DISTINCT in the same query.
If you use ALL for one UNION, it is used for all
of them. This is fixed as of MySQL 4.1.2. The rules for mixed UNION
types are given in section 13.1.7.2 UNION Syntax.
FLUSH TABLES WITH READ LOCK does not block CREATE TABLE, which
may cause a problem with the binary log position when
doing a full backup of tables and the binary log.
mysqldump --single-transaction --master-data behaved like
mysqldump --master-data, so the dump was a blocking one. This is fixed
starting from MySQL 4.1.8.
The following problems are known and fixing them is a high priority:
lower_case_table_names=2 (which enables
MySQL to remember the used case for databases and table names) MySQL
will not on case insensitive systems remember the used case for database
names for the function DATABASE() or in various logs.
FOREIGN KEY constraint doesn't work in replication because
the constraint may have another name on the slave.
REPLACE (and LOAD DATA with the REPLACE option) does not
trigger ON DELETE CASCADE.
DISTINCT with ORDER BY doesn't work inside GROUP_CONCAT()
if you don't use all and only those columns that are in the
DISTINCT list.
DROP TABLE command before the table is
used in the transaction itself. We plan to fix this in 5.0 by
having the DROP TABLE wait until the table is not used in any
transaction.
FLUSH TABLES WITH READ LOCK does not block COMMIT if the server
is running without binary logging, which may cause a problem (of consistency
between tables) when doing a full backup.
ANALYZE TABLE on a BDB table may in some cases make the table
unusable until you restart mysqld. If this happens, you will
see errors of the following form in the MySQL error file:
001207 22:07:56 bdb: log_flush: LSN past current end-of-log
FROM clause of a SELECT
statement, but silently
ignores them. The reason for not giving an error is that many clients
that automatically generate queries add parentheses in the FROM
clause even where they are not needed.
RIGHT JOINS or combining LEFT and
RIGHT join in the same query may not give a correct answer because
MySQL only generates NULL rows for the table preceding a LEFT or
before a RIGHT join. This will be fixed in 5.0 at the same time
we add support for parentheses in the FROM clause.
ALTER TABLE on a BDB table on which you are
running multiple-statement transactions until all those transactions complete.
(The transaction will probably be ignored.)
ANALYZE TABLE, OPTIMIZE TABLE, and REPAIR TABLE may
cause problems on tables for which you are using INSERT DELAYED.
LOCK TABLE ... and FLUSH TABLES ... doesn't
guarantee that there isn't a half-finished transaction in progress on the
table.
BDB tables are a bit slow to open. If you have many BDB tables
in a database, it will take a long time to use the mysql client on
the database if you are not using the -A option or if you are using
rehash. This is especially notable when you have a large table cache.
CREATE ... SELECT or
INSERT ... SELECT statements that
insert zero or NULL values into an AUTO_INCREMENT column.
DELETE if you are
deleting rows from a table that has foreign keys with ON DELETE
CASCADE properties.
REPLACE ... SELECT,
INSERT IGNORE ... SELECT if you have
duplicate key values in the inserted data.
ORDER BY
clause guaranteeing a deterministic order.
For example, for INSERT ... SELECT with no ORDER
BY, the SELECT may return rows in a different order
(which will result in a row having different ranks, hence getting a
different number in the AUTO_INCREMENT column),
depending on the choices made by the optimizers on the master and
slave. A query will be optimized differently on the master and slave only if:
OPTIMIZE TABLE was run on the master tables and not on
the slave tables. (To fix this, OPTIMIZE TABLE, ANALYZE TABLE,
and REPAIR TABLE are written to the binary log as of MySQL 4.1.1).
InnoDB on the master,
but MyISAM on the slave if the slave has less available disk
space.)
key_buffer_size, and so on) are different on
the master and slave.
mysqlbinlog|mysql.
The easiest way to avoid this problem in all cases is to add an
ORDER BY clause to
such non-deterministic queries to ensure that the rows are always
stored or modified in the same order.
In future MySQL versions, we will automatically add an ORDER BY
clause when needed.
The following problems are known and will be fixed in due time:
--log-bin=old_host_name-bin if you change your hostname to something
else. Another option is to just rename the old files to reflect your
hostname change. See section 5.2.1 mysqld Command-Line Options.
mysqlbinlog will not delete temporary files left after a
LOAD DATA INFILE command. See section 8.5 The mysqlbinlog Binary Log Utility.
RENAME doesn't work with TEMPORARY tables or tables used in a
MERGE table.
RPAD() function in a query that has to be
resolved by using a temporary table, all resulting strings will
have rightmost spaces removed. This is an example of such a query:
SELECT RPAD(t1.column1, 50, ' ') AS f2, RPAD(t2.column2, 50, ' ') AS f1 FROM table1 as t1 LEFT JOIN table2 AS t2 ON t1.record=t2.joinID ORDER BY t2.record;The final result of this bug is that you will not be able to get spaces on the right side of the resulting values. The problem also occurs for any other string function that adds spaces to the right. The reason for this is due to the fact that
HEAP tables, which are used
first for temporary tables, are not capable of handling VARCHAR columns.
This behavior exists in all versions of MySQL.
It will be fixed in one of the 4.1 series releases.
CHAR(255)) in table names, column names, or enumerations.
This is scheduled to be fixed in version 5.1 when we have new table
definition format files.
SET CHARACTER SET, you can't use translated
characters in database, table, and column names.
ESCAPE in LIKE
... ESCAPE.
DECIMAL column in which the same number is stored in
different formats (for example, +01.00, 1.00, 01.00),
GROUP BY may regard each value as a different value.
BLOB and TEXTvalues can't ``reliably'' be used in GROUP
BY or ORDER BY or DISTINCT. Only the first
max_sort_length bytes are used when comparing BLOB values in
these cases. The default value of max_sort_length value is 1024. It
can be changed at server startup time. As of MySQL 4.0.3, it can also be
changed at runtime. For older versions, a workaround for most cases is to
use a substring. For example:
SELECT DISTINCT LEFT(blob_col,2048) FROM tbl_name;
BIGINT or DOUBLE (both are
normally 64 bits long). Which precision you get depends on the function.
The general rule is that bit functions are done with BIGINT
precision, IF and ELT() with BIGINT or DOUBLE
precision, and the rest with DOUBLE precision. You should try to
avoid using unsigned long long values if they resolve to be bigger than
63 bits (9223372036854775807) for anything other than bit fields.
MySQL Server 4.0 has better BIGINT handling than 3.23.
BLOB and TEXT columns, automatically
have all trailing spaces removed when retrieved. For CHAR types, this
is okay. The bug is
that in MySQL Server, VARCHAR columns are treated the same way.
ENUM and SET columns in one table.
MIN(), MAX(), and other aggregate functions, MySQL
currently compares ENUM and SET columns by their string
value rather than by the string's relative position in the set.
mysqld_safe redirects all messages from mysqld to the
mysqld log. One problem with this is that if you execute
mysqladmin refresh to close and reopen the log,
stdout and stderr are still redirected to the old log.
If you use --log extensively, you should edit mysqld_safe to
log to `host_name.err' instead of `host_name.log' so that you can
easily reclaim the space for the old log by deleting the old one and
executing mysqladmin refresh.
UPDATE statement, columns are updated from left to right. If
you refer to an updated column, you get the updated value instead of the
original value. For example, the following statement increments KEY
by 2, not 1:
mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1;
mysql> SELECT * FROM temp_table, temp_table AS t2; ERROR 1137: Can't reopen table: 'temp_table'
DISTINCT differently when you are using
``hidden'' columns in a join than when you are not. In a join, hidden
columns are counted as part of the result (even if they are not shown),
whereas in normal queries, hidden columns don't participate in the
DISTINCT comparison. We will probably change this in the future to
never compare the hidden columns when executing DISTINCT.
An example of this is:
SELECT DISTINCT mp3id FROM band_downloads
WHERE userid = 9 ORDER BY id DESC;
and
SELECT DISTINCT band_downloads.mp3id
FROM band_downloads,band_mp3
WHERE band_downloads.userid = 9
AND band_mp3.id = band_downloads.mp3id
ORDER BY band_downloads.id DESC;
In the second case, you might in MySQL Server 3.23.x get two identical rows in
the result set (because the values in the hidden id column may differ).
Note that this happens only for queries where you don't have the
ORDER BY columns in the result.
PROCEDURE on a query that returns an empty set,
in some cases the PROCEDURE will not transform the columns.
MERGE doesn't check whether the underlying
tables are of compatible types.
ALTER TABLE first to add a UNIQUE index to a
table used in a MERGE table and then to
add a normal index on the MERGE table, the key order will be
different for the tables if there was an old key that was not unique in the
table. This is because ALTER TABLE puts UNIQUE indexes before
normal indexes to be able to detect duplicate keys as early as possible.
The following are known bugs in earlier versions of MySQL:
LOCK TABLE with WRITE.
FLUSH TABLES.
UPDATE that updated a key with
a WHERE on the same key may have failed because the key was used to
search for records and the same row may have been found multiple times:
UPDATE tbl_name SET KEY=KEY+1 WHERE KEY > 100;A workaround is to use:
UPDATE tbl_name SET KEY=KEY+1 WHERE KEY+0 > 100;This will work because MySQL Server will not use an index on expressions in the
WHERE clause.
For information about platform-specific bugs, see the installation and porting instructions in section 2.12 Operating System-Specific Notes and section E Porting to Other Systems.
Go to the first, previous, next, last section, table of contents.