|
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 trademark of MySQL AB
.
The MySQL
software is Dual Licensed
. Users can choose to
use the MySQL
software as an Open Source
/Free Software
product under the terms of the GNU General Public License
(http://www.gnu.org/licenses/) or can purchase a standard
commercial license from MySQL AB
.
See section MySQL Support and Licensing.
The MySQL
web site (http://www.mysql.com/) provides the
latest information about the MySQL
software.
The following list describes some sections of particular interest in this manual:
MySQL Database Server
,
see What Is MySQL AB?.
MySQL Database Server
,
see The Main Features of MySQL.
MySQL Database Software
to new architectures
or operating systems, see Porting to Other Systems.
MySQL Database Server
,
see MySQL Tutorial.
SQL
and benchmarking information, see the
benchmarking directory (`sql-bench' in the distribution).
Important:
Reports of errors (often called bugs), as well as questions and comments, should be sent to the general MySQL mailing list. See section The MySQL Mailing Lists. See section How to Report Bugs or Problems.
The mysqlbug
script should be used to generate bug reports on Unix.
(Windows distributions contain a file `mysqlbug.txt' in the base
directory that can be used as a template for a bug report.)
For source distributions, the mysqlbug
script can be found in the
`scripts' directory. For binary distributions, mysqlbug
can be found in the `bin' directory (`/usr/bin' for the
MySQL-server
RPM package).
If you have found a sensitive security bug in MySQL Server
,
you should send an e-mail to security@mysql.com.
This is the MySQL
reference manual; it documents MySQL
up to Version 3.23.58. Functional changes are always
indicated with reference to the version, so this manual is also suitable
if you are using an older version of the MySQL
software
(such as 3.23 or 4.0-production).
There are also references for version 5.0 (development).
Being a reference manual, it does not provide general instruction on
SQL
or relational database concepts.
As the MySQL Database Software
is under constant development,
the manual is also updated frequently.
The most recent version of this manual is available at
http://www.mysql.com/documentation/ in many different formats,
including HTML, PDF, and Windows HLP 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 a hard time finding information in the manual, you can try our searchable version at http://www.mysql.com/doc/.
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 Arjen Lentz, Paul DuBois and Stefan Hinz. For the many other contributors, see Credits.
The copyright (2003) to this manual is owned by the Swedish company
MySQL AB
. See section Copyrights and Licenses Used by MySQL.
1.1.1 Conventions Used in This Manual |
This manual uses certain typographical conventions:
constant
Constant-width font is used for command names and options; SQL statements;
database, table, and column names; C and Perl code; and environment variables.
Example: "To see how mysqladmin
works, invoke it with the
--help
option."
Constant-width font with surrounding quotes is used for filenames and pathnames. Example: "The distribution is installed under the `/usr/local/' directory."
Constant-width font with surrounding quotes is also used to indicate character sequences. Example: "To specify a wildcard, use the `%' character."
Italic font is used for emphasis, like this.
Boldface font is used in table headings and to convey especially strong emphasis.
When commands are shown that are meant to be executed by 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 command that you execute from the
mysql
client program:
shell> type a shell command here mysql> type a mysql command here |
Shell commands are shown using Bourne shell syntax. If you are using a
csh
-style shell, you may need to issue commands slightly differently.
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 |
For csh
, you would execute the sequence like this:
shell> setenv VARNAME value shell> some_command |
Database, table, and column names must often be substituted into commands. 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} |
MySQL
, the most popular Open Source
SQL database, is
developed, distributed, and supported by MySQL AB
. MySQL AB
is a
commercial company, founded by the MySQL developers, that builds its business
providing services around the MySQL
database.
See section What Is MySQL AB?.
The MySQL
web site (http://www.mysql.com/)
provides the latest information about MySQL
software and
MySQL AB
.
MySQL
is a database management system.A database is a structured collection of data. It may be anything from a
simple shopping list to a picture gallery or the vast amounts of
information in a corporate network. To add, access, and process data
stored in a computer database, you need a database management system
such as MySQL
Server. Since computers are very good at handling large
amounts of data, database management systems play a central role in computing,
as stand-alone utilities or as parts of other applications.
A relational database stores data in separate tables rather than putting
all the data in one big storeroom. This adds speed and flexibility.
The SQL
part of "MySQL
" stands for "Structured
Query Language
". SQL is the most common standardised language used to
access databases and is defined by the ANSI/ISO SQL Standard.(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-99
" refers to the standard released in 1999, and
"SQL:2003
" refers to the version of the standard that is expected
to be released in mid-2003.We use the term "the SQL standard
" to
mean the current version of the SQL Standard at any time.)
Open Source
.Open Source
means that it is possible for anyone to use and modify the software.
Anybody can download the MySQL
software from the Internet and use it
without paying anything. If you wish, you may study the source code
and change it to suit your needs. The MySQL
software uses the
GPL
(GNU General Public License
),
http://www.gnu.org/licenses/, to define what you
may and may not do with the software in different situations.
If you feel uncomfortable with the GPL
or need to embed
MySQL
code into a commercial application you can buy a
commercially licensed version from us.
See section MySQL Licenses.
The MySQL Database Server
is very fast, reliable, and easy to use.
If that is what you are looking for, you should give it a try.
MySQL Server
also has a practical set of features developed in
close cooperation with our users. You can find a performance comparison
of MySQL Server
with other database managers on our benchmark page.
See section The MySQL Benchmark Suite.
MySQL Server
was originally developed to handle large databases
much faster than existing solutions and has been successfully used in
highly demanding production environments for several years. Though
under constant development, MySQL Server
today offers a rich and
useful set of functions. Its connectivity, speed, and security make
MySQL Server
highly suited for accessing databases on the Internet.
For advanced technical information, see MySQL Language Reference.
The MySQL Database Software
is a client/server system that consists
of a multi-threaded SQL
server that supports different backends,
several different client programs and libraries, administrative tools,
and a wide range of programming interfaces (APIs).
We also provide MySQL Server
as a multi-threaded library which you
can link into your application to get a smaller, faster, easier-to-manage
product.
It is very likely that you will find that your favorite application or
language already supports the MySQL Database Server
.
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 localised way.
1.2.1 History of MySQL | ||
1.2.2 The Main Features of MySQL | ||
1.2.3 How Stable Is MySQL? | ||
1.2.4 How Big Can MySQL Tables Be? | ||
1.2.5 Year 2000 Compliance |
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
. See section MySQL 4.0 in a Nutshell.
MySQL
code gets tested with Purify
(a commercial memory leakage detector) as well as with Valgrind,
a GPL
tool (http://developer.kde.org/~sewardj/).
FLOAT
, DOUBLE
, CHAR
, VARCHAR
,
TEXT
, BLOB
, DATE
, TIME
, DATETIME
,
TIMESTAMP
, YEAR
, SET
, and ENUM
types.
See section Column Types.
SELECT
and WHERE
clauses of queries. For example:
mysql> SELECT CONCAT(first_name, " ", last_name) -> FROM tbl_name -> 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.
MySQL
-specific SHOW
command can be used to retrieve
information about databases, tables, and indexes. The EXPLAIN
command
can be used to determine how the optimiser 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 Is MySQL Picky About Reserved Words?.
MySQL Server
with databases that
contain 50 million records. We also know of users that
use MySQL Server
with 60,000 tables and about 5,000,000,000 rows.
MySQL Server
).
An index may use a prefix of a CHAR
or VARCHAR
field.
MySQL
server using TCP/IP Sockets,
Unix Sockets (Unix), or Named Pipes (NT).
MySQL
server. See section MySQL ODBC Support.
MySQL
server is started. To see an example of very advanced sorting, look
at the Czech sorting code. MySQL Server
supports many different
character sets that can be specified at compile and runtime.
myisamchk
, a very fast utility for table checking,
optimisation, and repair. All of the functionality of myisamchk
is also available through the SQL interface.
See section Database Administration.
MySQL
programs can be invoked with the --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 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. See section 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:
Large server clusters using replication are in production use, with
good results. Work on enhanced replication features is continuing
in MySQL
4.x.
InnoDB
tables - Stable (in 3.23 from 3.23.49)The 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 - GammaThe Berkeley DB
code is very stable, but we are still improving
the BDB
transactional storage engine interface in
MySQL Server
, so it will take some time before this is as well
tested as the other table types.
FULLTEXT
- BetaFull-text search works but is not yet widely used.
Important enhancements have been implemented in MySQL
4.0.
MyODBC 3.51
(uses ODBC SDK 3.51) - StableIn wide production use. Some issues brought up appear to be application-related and independent of the ODBC driver or underlying database server.
MyISAM
tables - GammaThis status applies only to the new code in the MyISAM
storage
engine that checks if the table was closed properly on open and
executes an automatic check/repair of the table if it wasn't.
New feature in MyISAM
tables in MySQL
4.0 for faster
insert of many rows.
This is very system-dependent. On some systems there are big problems
using standard OS locking (fcntl()
). In these cases, you should
run mysqld
with the --skip-external-locking
flag.
Problems are known to occur on some Linux systems, and on SunOS when
using NFS-mounted filesystems.
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:
Operating System | File-Size Limit |
Linux-Intel 32 bit | 2 GB, much more when using LFS |
Linux-Alpha | 8 TB (?) |
Solaris 2.5.1 | 2 GB (possible 4GB with patch) |
Solaris 2.6 | 4 GB (can be changed with flag) |
Solaris 2.7 Intel | 4 GB |
Solaris 2.7 UltraSPARC | 512 GB |
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
.
See section 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.
See section CREATE TABLE
Syntax. You can also set these parameters later, with
ALTER TABLE
. See section 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. See section myisampack
.
You can get around the operating system file limit for MyISAM
datafiles using the RAID
option. See section CREATE TABLE
Syntax.
Another solution can be the included MERGE
library, which allows
you to handle a collection of identical tables as one.
See section MERGE
tables.
The MySQL Server
itself has no problems with Year 2000 (Y2K)
compliance:
MySQL Server
uses Unix time functions and has no problems with dates
until 2069
. All 2-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
.
MySQL
date functions are stored in one file, `sql/time.cc',
and are coded very carefully to be year 2000-safe.
MySQL
Version 3.22 and later, the YEAR
column type
can store years 0
and 1901
to 2155
in one byte and
display them using two or four digits.
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 Y2K Issues and Date Types for MySQL Server
's
rules for dealing with ambiguous date input data (data containing 2-digit
year values).
MySQL AB
is the company of the MySQL
founders and main
developers. MySQL AB
was originally established in Sweden by
David Axmark, Allan Larsson, and Michael Monty
Widenius.
The developers of the MySQL
server are all employed by the company.
We are a virtual organisation with people in a dozen countries around
the world. We communicate extensively over the Net every day with one another
and with our users, supporters, and partners.
We are dedicated to developing the MySQL
software and spreading
our database to new users. MySQL AB
owns the copyright to the
MySQL
source code, the MySQL
logo and trademark, and this
manual. See section What Is MySQL?.
1.3.1 The Business Model and Services of MySQL AB | ||
1.3.2 Contact Information |
The MySQL
core values show our dedication to MySQL
and
Open Source
.
We want the MySQL Database Software
to be:
MySQL AB
and the people at MySQL AB
:
Open Source
philosophy and support the
Open Source
community.
The MySQL
web site (http://www.mysql.com/)
provides the latest information about MySQL
and MySQL AB
.
By the way, the "AB" part of the company name is the acronym for the Swedish "aktiebolag", or "stock company." It translates to "MySQL, Inc." In fact, MySQL Inc. and MySQL GmbH are examples of MySQL AB subsidiaries. They are located in the US and Germany, respectively.
One of the most common questions we encounter is: "How can you make a living from something you give away for free?" This is how.
MySQL AB
makes money on support, services, commercial licenses,
and royalties. We use these revenues to fund product development
and to expand the MySQL
business.
1.3.1.1 Support | ||
1.3.1.2 Training and Certification | ||
1.3.1.3 Consulting | ||
1.3.1.4 Commercial Licenses | ||
1.3.1.5 Partnering |
The company has been profitable since its inception. In October 2001, we accepted venture financing from leading Scandinavian investors and a handful of business angels. This investment is used to solidify our business model and build a basis for sustainable growth.
MySQL AB
is run and owned by the founders and main developers of
the MySQL
database. The developers are committed to giving support
to customers and other users in order to stay in touch with their needs
and problems. All our support is given by qualified developers. Really
tricky questions are answered by Michael Monty
Widenius, principal
author of the MySQL Server
.
See section Support Offered by MySQL AB.
For more information and ordering support at various levels, see http://www.mysql.com/support/ or contact our sales staff at sales@mysql.com.
MySQL AB
delivers MySQL
and related training worldwide.
We offer both open courses and in-house courses tailored to the
specific needs of your company. MySQL Training
is also available
through our partners, the Authorised MySQL Training Centers
.
Our training material uses the same example databases used in our
documentation and our sample applications, and is always updated
to reflect the latest MySQL
version. Our trainers are backed by
the development team to guarantee the quality of the training and the
continuous development of the course material. This also ensures
that no questions raised during the courses remain unanswered.
Attending our training courses will enable you to achieve your MySQL
application goals. You will also:
MySQL Certification
.
If you are interested in our training as a potential participant or as a training partner, please visit the training section at http://www.mysql.com/training/ or contact us at: training@mysql.com.
For details about the MySQL Certification Program
, please see
http://www.mysql.com/certification/.
MySQL AB
and its Authorised Partners
offer consulting
services to users of MySQL Server
and to those who embed
MySQL Server
in their own software, all over the world.
Our consultants can help you design and tune your databases, construct
efficient queries, tune your platform for optimal performance, resolve
migration issues, set up replication, build robust transactional
applications, and more.
We also help customers embed MySQL Server
in their products and
applications for large-scale deployment.
Our consultants work in close collaboration with our development team,
which ensures the technical quality of our professional services.
Consulting assignments range from 2-day power-start sessions to
projects that span weeks and months. Our expertise not only covers
MySQL Server
--it also extends into programming and scripting
languages such as PHP, Perl, and more.
If you are interested in our consulting services or want to become a consulting partner, please visit the consulting section of our web site at http://www.mysql.com/consulting/ or contact our consulting staff at consulting@mysql.com.
The MySQL
database is released under the
GNU General Public License
(GPL
).
This means that the MySQL
software can be used free of charge
under the GPL
. If you do not want to be bound by the GPL
terms (such as the requirement that your application must also be GPL
,
you may purchase a commercial license for the same product
from MySQL AB
; see http://www.mysql.com/products/pricing.html.
Since MySQL AB
owns the copyright to the MySQL
source code,
we are able to employ Dual Licensing
, which means that the same
product is available under GPL
and under a commercial
license. This does not in any way affect the Open Source
commitment of MySQL AB
. For details about when a commercial
license is required, please see MySQL Licenses.
We also sell commercial licenses of third-party Open Source GPL
software that adds value to MySQL Server
. A good example is the
InnoDB
transactional storage engine that offers ACID
support, row-level locking, crash recovery, multi-versioning, foreign
key support, and more. See section InnoDB
Tables.
MySQL AB
has a worldwide partner programme that covers training
courses, consulting and support, publications, plus reselling and
distributing MySQL
and related products. MySQL AB Partners
get visibility on the http://www.mysql.com/ web site and the right
to use special versions of the MySQL
trademarks to identify their
products and promote their business.
If you are interested in becoming a MySQL AB Partner
, please e-mail
partner@mysql.com.
The word MySQL
and the MySQL
dolphin logo are trademarks of
MySQL AB
. See section MySQL AB Logos and Trademarks.
These trademarks represent a significant value that the MySQL
founders have built over the years.
The MySQL
web site (http://www.mysql.com/) is popular among
developers and users. In October 2001, we served 10 million page views.
Our visitors represent a group that makes purchase decisions and
recommendations for both software and hardware. Twelve percent of our
visitors authorise purchase decisions, and only nine percent are not
involved in purchase decisions at all. More than 65% have made one or
more online business purchases within the last half-year, and 70% plan
to make one in the next few months.
The MySQL
web site (http://www.mysql.com/)
provides the latest information about MySQL
and MySQL AB
.
For press services and inquiries not covered in our News releases (http://www.mysql.com/news/), please send an e-mail to press@mysql.com.
If you have a valid support contract with MySQL AB
, you will
get timely, precise answers to your technical questions about the
MySQL
software. For more information, see Support Offered by MySQL AB.
On our web site, see http://www.mysql.com/support/, or send
an e-mail to sales@mysql.com.
For information about MySQL
training, please visit the training
section at http://www.mysql.com/training/. If you have
restricted access to the Internet, please contact the MySQL AB
training staff via e-mail at training@mysql.com.
See section Training and Certification.
For information on the MySQL Certification Program
, please see
http://www.mysql.com/certification/.
See section Training and Certification.
If you're interested in consulting, please visit the consulting
section of our web site at http://www.mysql.com/consulting/. If you have
restricted access to the Internet, please contact the MySQL AB
consulting staff via e-mail at consulting@mysql.com.
See section Consulting.
Commercial licenses may be purchased online at
https://order.mysql.com/. There you will also find information
on how to fax your purchase order to MySQL AB
. More information
about licensing can be found at
http://www.mysql.com/products/pricing.html.
If you have
questions regarding licensing or you want a quote for a high-volume
license deal, please fill in the contact form on our web site
(http://www.mysql.com/) or send an e-mail message
to licensing@mysql.com (for licensing questions) or to
sales@mysql.com (for sales inquiries).
See section MySQL Licenses.
If you represent a business that is interested in partnering with
MySQL AB
, please send an e-mail to partner@mysql.com.
See section Partnering.
For more information on the MySQL
trademark policy, refer to
http://www.mysql.com/company/trademark.html or send an e-mail to
trademark@mysql.com.
See section MySQL AB Logos and Trademarks.
If you are interested in any of the MySQL AB
jobs listed in our
jobs section (http://www.mysql.com/company/jobs/),
please send an e-mail to jobs@mysql.com.
Please do not send your CV as an attachment, but rather as plain text
at the end of your e-mail message.
For general discussion among our many users, please direct your attention to the appropriate mailing list. See section MySQL Mailing Lists.
Reports of errors (often called bugs), as well as questions and
comments, should be sent to the general MySQL mailing list.
See section The MySQL Mailing Lists.
If you have found a sensitive
security bug in the MySQL Server
, please send an e-mail
to security@mysql.com.
See section How to Report Bugs or Problems.
If you have benchmark results that we can publish, please contact us via e-mail at benchmarks@mysql.com.
If you have suggestions concerning additions or corrections to this manual, please send them to the manual team via e-mail at docs@mysql.com.
For questions or comments about the workings or content of the
MySQL
web site (http://www.mysql.com/),
please send an e-mail to webmaster@mysql.com.
MySQL AB
has a privacy policy, which can be read at
http://www.mysql.com/company/privacy.html.
For any queries regarding this policy, please send an e-mail to
privacy@mysql.com.
For all other inquires, please send an e-mail to info@mysql.com.
This section describes MySQL
support and licensing arrangements.
1.4.1 Support Offered by MySQL AB | ||
1.4.2 Copyrights and Licenses Used by MySQL | ||
1.4.3 MySQL Licenses | ||
1.4.4 MySQL AB Logos and Trademarks |
Technical support from MySQL AB
means individualised answers
to your unique problems direct from the software engineers who code
the MySQL
database engine.
We try to take a broad and inclusive view of technical support. Almost
any problem involving MySQL
software is important to us if it's
important to you.
Typically customers seek help on how to get different commands and
utilities to work, remove performance bottlenecks, restore crashed
systems, understand operating system or networking impacts on MySQL
,
set up best practices for backup and recovery, utilise APIs, and so on.
Our support covers only the MySQL
server and our own utilities,
not third-party products that access the MySQL
server, though we
try to help with these where we can.
Detailed information about our various support options is given at http://www.mysql.com/support/, where support contracts can also be ordered online. If you have restricted access to the Internet, please contact our sales staff via e-mail at sales@mysql.com.
Technical support is like life insurance. You can live happily
without it for years, but when your hour arrives it becomes
critically important, yet it's too late to buy it.
If you use MySQL Server
for important applications and encounter
sudden difficulties, it may be too time consuming to figure out all the answers
yourself. You may need immediate access to the most experienced
MySQL
troubleshooters available, those employed by MySQL AB
.
MySQL AB
owns the copyright to the MySQL
source code,
the MySQL
logos and trademarks and this manual.
See section What Is MySQL AB?.
Several different licenses are relevant to the MySQL
distribution:
MySQL
-specific source in the server, the mysqlclient
library and the client, as well as the GNU
readline
library
is covered by the GNU General Public License
.
See section GNU General Public License.
The text of this license can be found as the file `COPYING'
in the distribution.
GNU
getopt
library is covered by the
GNU Lesser General Public License
.
See section GNU Lesser General Public License.
regexp
library) are covered
by a Berkeley-style copyright.
MySQL
(3.22 and earlier) are subject to a
stricter license
(http://www.mysql.com/products/mypl.html).
See the documentation of the specific version for information.
MySQL
reference manual is currently not distributed
under a GPL
-style license. Use of the manual is subject to the
following terms:
MySQL AB
is required.
Please send an e-mail to docs@mysql.com for more information or if you are interested in doing a translation.
For information about how the MySQL
licenses work in practice,
please refer to MySQL Licenses.
Also see MySQL AB Logos and Trademarks.
The MySQL
software is released under the
GNU General Public License
(GPL
),
which is probably the best known Open Source
license.
The formal terms of the GPL
license can be found at
http://www.gnu.org/licenses/.
See also http://www.gnu.org/licenses/gpl-faq.html and
http://www.gnu.org/philosophy/enforcing-gpl.html.
Since the MySQL
software is released under the GPL
,
it may often be used for free, but for certain uses you may want
or need to buy commercial licenses from MySQL AB
at
https://order.mysql.com/.
See http://www.mysql.com/products/licensing.html for
more information.
Older versions of MySQL
(3.22 and earlier) are subject to a
stricter license
(http://www.mysql.com/products/mypl.html).
See the documentation of the specific version for information.
Please note that the use of the MySQL
software under commercial
license, GPL
, or the old MySQL
license does not
automatically give you the right to use MySQL AB
trademarks.
See section MySQL AB Logos and Trademarks.
1.4.3.1 Using the MySQL Software Under a Commercial License | ||
1.4.3.2 Using the MySQL Software for Free Under GPL |
The GPL
license is contagious in the sense that when a program
is linked to a GPL
program all the source code for all the parts
of the resulting product must also be released under the GPL
.
If you do not follow this GPL
requirement, you break the license
terms and forfeit your right to use the GPL
program altogether.
You also risk damages.
You need a commercial license:
GPL
code from the MySQL
software and don't want the resulting product to be licensed under GPL
,
perhaps because you want to build a commercial product or keep the added
non-GPL
code closed source for other reasons. When purchasing
commercial licenses, you are not using the MySQL
software under
GPL
even though it's the same code.
GPL
application that only works with the
MySQL
software and ship it with the MySQL
software. This type
of solution is considered to be linking even if it's done over a network.
MySQL
software without providing
the source code as required under the GPL
license.
MySQL
database even if you don't formally need a commercial license.
Purchasing support directly from MySQL AB
is another good way
of contributing to the development of the MySQL
software, with
immediate advantages for you.
See section Support Offered by MySQL AB.
If you require a license, you will need one for each installation of the
MySQL
software. This covers any number of CPUs on a machine, and there
is no artificial limit on the number of clients that connect to the server
in any way.
For commercial licenses, please visit our website at http://www.mysql.com/products/licensing.html. For support contracts, see http://www.mysql.com/support/. If you have special needs or you have restricted access to the Internet, please contact our sales staff via e-mail at sales@mysql.com.
You can use the MySQL
software for free under the GPL
if
you adhere to the conditions of the GPL
.
For additional details, including answers to common questions about the GPL
,
see the generic FAQ from the Free Software Foundation at
http://www.gnu.org/licenses/gpl-faq.html.
Common uses of the GPL
include:
MySQL
source code under the GPL
with your product.
MySQL
source code bundled with other
programs that are not linked to or dependent on the MySQL
system
for their functionality even if you sell the distribution commercially.
This is called mere aggregation in the GPL
license.
MySQL
system, you can use it for free.
MySQL
servers for your customers.
We encourage people to use ISPs that have MySQL support,
as this will give them the confidence that their ISP will, in fact,
have the resources to solve any problems they may experience with
the MySQL
installation. Even if an ISP does not have
a commercial license for MySQL Server
, their customers
should at least be given read access to the source of the MySQL
installation so that the customers can verify that it is correctly patched.
MySQL
database software in conjunction with a
web server, you do not need a commercial license (so long as it is not
a product you distribute). This is true even if you run a commercial
web server that uses MySQL Server
, because you are not
distributing any part of the MySQL
system. However, in this
case we would like you to purchase MySQL
support because the
MySQL
software is helping your enterprise.
If your use of MySQL
database software does not require a commercial
license, we encourage you to purchase support from MySQL AB
anyway.
This way you contribute toward MySQL
development and also gain
immediate advantages for yourself. See section Support Offered by MySQL AB.
If you use the MySQL
database software in a commercial context
such that you profit by its use, we ask that you further the development
of the MySQL
software by purchasing some level of support. We feel
that if the MySQL
database helps your business, it is reasonable to
ask that you help MySQL AB
.
(Otherwise, if you ask us support questions, you are not only using
for free something into which we've put a lot a work, you're asking
us to provide free support, too.)
Many users of the MySQL
database want to display the
MySQL AB
dolphin logo on their web sites, books, or
boxed products. We welcome and encourage this, although it should be
noted that the word MySQL
and the MySQL
dolphin logo
are trademarks of MySQL AB
and may only be used as stated in
our trademark policy at
http://www.mysql.com/company/trademark.html.
The MySQL
dolphin logo was designed by the Finnish advertising
agency Priority in 2001. The dolphin was chosen as a suitable symbol
for the MySQL
database since it is a smart, fast, and lean animal,
effortlessly navigating oceans of data. We also happen to like dolphins.
The original MySQL
logo may only be used by representatives of
MySQL AB
and by those having a written agreement allowing them
to do so.
We have designed a set of special Conditional Use logos that may be
downloaded from our web site at
http://www.mysql.com/press/logos.html
and used on third-party web sites without written permission from
MySQL AB
.
The use of these logos is not entirely unrestricted but, as the name
implies, subject to our trademark policy that is also available on our
web site. You should read through the trademark policy if you plan to
use them. The requirements are basically as follows:
MySQL AB
, are the creator and
owner of the site that displays the MySQL
trademark.
MySQL AB
or to the value of MySQL AB
trademarks. We reserve the right to
revoke the right to use the MySQL AB
trademark.
MySQL
database under GPL
in an
application, your application must be Open Source
and must
be able to connect to a MySQL
server.
Contact us via e-mail at trademark@mysql.com to inquire about special arrangements to fit your needs.
You need written permission from MySQL AB
before using MySQL
logos in the following cases:
MySQL AB
logo anywhere except on your web site.
MySQL AB
logo except the Conditional Use
logos mentioned previously on web sites or elsewhere.
Due to legal and commercial reasons we monitor the use of MySQL
trademarks on products, books, and other items. We usually require a fee for
displaying MySQL AB
logos on commercial products, since we think
it is reasonable that some of the revenue is returned to fund further
development of the MySQL
database.
MySQL
partnership logos may be used only by companies and persons
having a written partnership agreement with MySQL AB
. Partnerships
include certification as a MySQL
trainer or consultant.
For more information, please see Partnering.
MySQL
in Printed Text or Presentations MySQL AB
welcomes references to the MySQL
database, but
it should be noted that the word MySQL
is a trademark of MySQL AB
.
Because of this, you must append the trademark symbol (TM
) to
the first or most prominent use of the word MySQL
in a text and,
where appropriate, state that MySQL
is a trademark of
MySQL AB
. For more information, please refer to our trademark policy at
http://www.mysql.com/company/trademark.html.
MySQL
in Company and Product Names Use of the word MySQL
in product or company names or in Internet
domain names is not allowed without written permission from MySQL AB
.
This section provides a snapshot of the MySQL development roadmap, including major features implemented or planned for MySQL 4.0, 4.1, and 5.0. The following sections provide information for each release. Plans for some of the most requested features are summarized in the following table.
Feature | MySQL version |
Unions | 4.0 |
Subqueries | 4.1 |
R-trees | 4.1 (for MyISAM tables) |
Stored procedures | 5.0 |
Cursors | 5.0 |
Foreign keys | 5.1 (3.23 with InnoDB) |
Views | 5.1 |
Triggers | 5.1 |
Full outer join | 5.1 |
Constraints | 5.1 |
1.5.1 MySQL 4.0 in a Nutshell | ||
1.5.2 MySQL 4.1 in a Nutshell | ||
1.5.3 MySQL 5.0, The Next Development Release |
Long promised by MySQL AB
and long awaited by our users,
MySQL Server 4.0 is now available in production version.
MySQL 4.0 is available for download from http://www.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.
MySQL Version 4.0.12 was declared stable for production use in March 2003. This means that, in future, only bug fixes will be done for the 4.0 release series and only critical bug fixes will be done for the older 3.23 series. See section Upgrading From Version 3.23 to 4.0.
New features to the MySQL
software are being added to MySQL 4.1
which is now also available (alpha version).
See section MySQL 4.1 in a Nutshell.
1.5.1.1 Features Available in MySQL 4.0 | ||
1.5.1.2 Embedded MySQL Server |
INSERT
s, searching on
packed indexes, creation of FULLTEXT
indexes, and COUNT(DISTINCT)
.
InnoDB
storage engine is now offered as a standard feature of the
MySQL
server. This means full support for ACID transactions,
foreign keys with cascading UPDATE/DELETE, and row-level locking
are now standard features.
See section InnoDB
Tables.
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 customise minimal word
length and define your own stop word lists in any human language,
enabling a new set of applications to be built on MySQL Server.
See section MySQL Full-text Search.
TRUNCATE TABLE
(as in Oracle).
UNION
statement, a long-awaited standard SQL feature.
MySQL
now
supports a new character set, latin1_de
, which ensures that the
German sorting order sorts words with umlauts in the same order
as do German telephone books.
In the process of building features for new users, we have not forgotten requests from our community of loyal users.
mysqld
parameters (startup options) can now be set without taking
down the servers. This is a convenient feature for Database Administrators (DBAs).
See section SET
Syntax.
DELETE
and UPDATE
statements have been added..
symbolic linking
to MyISAM
at the table
level (and not just the database level as before) and for enabling
symlink handling by default on Windows.
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 Changes in release 4.0.x (Production).
libmysqld
makes MySQL Server suitable for a vastly expanded realm of
applications. Using the embedded MySQL server library, one 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.
The embedded MySQL library uses the same interface as the normal
client library, so it is convenient and easy to use. See section libmysqld, the Embedded MySQL Server Library.
MySQL Server 4.0 laid the foundation for new features such as nested subqueries and Unicode (implemented in version 4.1) and for the work on SQL-99 stored procedures being done for version 5.0. These features come at the top of the wish list of many of our customers.
With these additions, critics of the MySQL Database Server have to be more imaginative than ever in pointing out deficiencies in the MySQL Database Management System. Already well-known for its stability, speed, and ease of use, MySQL Server will be able to fulfill the requirement checklists of very demanding buyers.
1.5.2.1 Features Available in MySQL 4.1 | ||
1.5.2.2 Stepwise Rollout | ||
1.5.2.3 Ready for Immediate Development Use |
The features listed in this section are implemented in MySQL 4.1. A few other features are still planned for MySQL 4.1. See section New Features Planned For 4.1.
Most new features being coded, such as stored procedures, will be available in MySQL 5.0. See section New Features Planned For 5.0.
SELECT * FROM t1 WHERE t1.a=(SELECT t2.b FROM t2); SELECT * FROM t1 WHERE (1,2,3) IN (SELECT a,b,c FROM t2); |
FROM
clause of a SELECT
statement. Here is
an example:
SELECT t1.a FROM t1, (SELECT * FROM t2) t3 WHERE t1.a=t3.a; |
BTREE
indexing is now supported for HEAP
tables,
significantly improving response time for non-exact searches.
CREATE TABLE table LIKE table
allows you to create a new table
with the exact structure of an existing table, using a single command.
SHOW WARNINGS
shows warnings for the last command.
See section SHOW WARNINGS | ERRORS
.
HELP command
that can be used in the mysql
command line
client (and other clients) to get help for SQL commands.
The advantage of having this information on the server side is that the
information is always applicable for that particular server version.
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
key (index).
See section INSERT
Syntax.
GROUP_CONCAT()
,
adding the extremely useful capability of concatenating columns from
grouped rows into a single result string.
See section Functions and Modifiers for Use with GROUP BY
Clauses.
The news section in this manual includes a more in-depth list of features. See section Changes in release 4.1.x (Alpha).
New features are being added to MySQL 4.1, which is already available for download (alpha version). See section Ready for Immediate Development Use.
The set of features that are being added to version 4.1 is mostly fixed. Additional development is already ongoing for version 5.0. MySQL 4.1 will go through the steps of Alpha (during which time new features might still be added/changed), Beta (when we have feature freeze and only bug corrections will be done), and Gamma (indicating that a production release is just weeks ahead). At the end of this process, MySQL 4.1 will become the new production release.
MySQL 4.1 is currently in the alpha stage, and binaries are available for download at http://www.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 Changes in release 4.1.x (Alpha).
For those wishing to use the most recent development source for MySQL 4.1, we have made our 4.1 BitKeeper repository publicly available. See section Installing from the Development Source Tree.
New development for MySQL is focused on the 5.0 release, featuring Stored Procedures and other new features. See section New Features Planned For 5.0.
For those wishing to take a look at the bleeding edge of MySQL development, we have made our BitKeeper repository for MySQL version 5.0 publicly available. See section Installing from the Development Source Tree.
1.6.1 MySQL Mailing Lists | ||
1.6.2 MySQL Community Support on IRC (Internet Relay Chat) |
1.6.1.1 The MySQL Mailing Lists | ||
1.6.1.2 Asking Questions or Reporting Bugs | ||
1.6.1.3 How to Report Bugs or Problems | ||
1.6.1.4 Guidelines for Answering Questions on the Mailing List |
This section introduces you to the MySQL mailing lists and gives some guidelines as to how the lists should be used. When you subscribe to a mailing list, you will receive, as e-mail messages, all postings to the list. You will also be able to 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/. 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
This list is for announcements of new versions of MySQL and related programs. This is a low-volume list to which all MySQL users should subscribe.
mysql
This is the main list for general MySQL discussion. Please note that some topics are better discussed on the more-specialised lists. If you post to the wrong list, you may not get an answer.
mysql-digest
This is the mysql
list in digest form. Subscribing to this list means
you will get all list messages, sent as one large mail message once a day.
bugs
This list will be of interest to you if you want to stay informed about
issues reported since the last release of MySQL
or if you want to be
actively involved in the process of bug hunting and fixing.
See section How to Report Bugs or Problems.
bugs-digest
This is the bugs
list in digest form.
internals
This list is for people who work on the MySQL code. This is also the forum for discussions on MySQL development and post patches.
internals-digest
This is the internals
list in digest form.
mysqldoc
This list is for people who work on the MySQL documentation: people from MySQL AB, translators, and other community members.
mysqldoc-digest
This is the mysqldoc
list in digest form.
benchmarks
This list is for anyone interested in performance issues. Discussions concentrate on database performance (not limited to MySQL) but also include broader categories such as performance of the kernel, file system, disk system, and so on.
benchmarks-digest
This is the benchmarks
list in digest form.
packagers
This list is for discussions on packaging and distributing MySQL. This is the forum used by distribution maintainers to exchange ideas on packaging MySQL and on ensuring that MySQL looks and feels as similar as possible on all supported platforms and operating systems.
packagers-digest
This is the packagers
list in digest form.
java
This list is for discussions about the MySQL server and Java.It is mostly used to discuss JDBC drivers, including MySQL Connector/J.
java-digest
This is the java
list in digest form.
win32
This list is for all things concerning the MySQL software on Microsoft operating systems, such as Windows 9x/Me/NT/2000/XP.
win32-digest
This is the win32
list in digest form.
myodbc
This list is for all things concerning connecting to the MySQL server with ODBC.
myodbc-digest
This is the myodbc
list in digest form.
mysqlcc
This list is for all things concerning the MySQL Control Center
graphical client.
mysqlcc-digest
This is the mysqlcc
list in digest form.
plusplus
This list is for all things concerning programming with the C++ API to MySQL.
plusplus-digest
This is the plusplus
list in digest form.
msql-mysql-modules
This list is for all things concerning the Perl support for MySQL with msql-mysql-modules
,
which is now named DBD-mysql
.
msql-mysql-modules-digest
This is the msql-mysql-modules
list in digest form.
If you're unable to get an answer to your question(s) from a MySQL
mailing list, one
option is to pay for support from MySQL AB. This will put you
in direct contact with MySQL developers. See section Support Offered by MySQL AB.
The following table shows some MySQL mailing lists in languages other than English. These lists are not operated by MySQL AB, so we can't guarantee their quality.
mysql-france-subscribe@yahoogroups.com A French mailing list
list@tinc.net A Korean mailing list
E-mail subscribe mysql your@e-mail.address
to this list.
mysql-de-request@lists.4t2.com A German mailing list
E-mail subscribe mysql-de your@e-mail.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 A Portuguese mailing list
E-mail subscribe mysql-br your@e-mail.address
to this list.
mysql-alta@elistas.net A Spanish mailing list
E-mail subscribe mysql your@e-mail.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.
Our bugs database is public, and can be browsed and searched by anyone at http://bugs.mysql.com/. If you log into 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 instance, 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
' on the
included test case or run 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 will also post a patch that fixes the problem.
The normal place to report bugs is http://bugs.mysql.com/.
If you have found a sensitive security bug in MySQL, please send an e-mail to security@mysql.com.
If you have a repeatable bug report, please report this into 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: if you are in doubt about stating something, state it. It is a thousand times faster and less troublesome to write a couple of lines more in your report than to be forced to ask again and wait for the answer because you didn't include enough information the first time.
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.
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 all the things 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 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 case should be observed.) You should never try to remember what the error message was; instead, copy and paste the entire message into your report.
If you have a problem with MyODBC, please try to generate a MyODBC trace file and send it with your report. See section Reporting Problems with MyODBC.
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
. mysqladmin
can be
found in the `bin' directory under your MySQL installation
directory.
uname -a
. If
you work with Windows, you can usually get the name and version number
by double-clicking your "My Computer" icon and pulling down the "Help/About Windows"
menu.
mysqld
died, you should also report the query that crashed
mysqld
. You can usually find this out by running mysqld
with
logging enabled. See section Using Log Files to Find Cause of Errors in mysqld.
mysqldump --no-data db_name tbl_name1 tbl_name2 ...
. 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 of course be posted with the mysqlbug
script).
Example run using 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://support.mysql.com/pub/mysql/secret/. Then enter
the problem into our bugs database at http://bugs.mysql.com/.
ftp
to transfer it to
ftp://support.mysql.com/pub/mysql/secret/. If the data is really top
secret and you don't want to show it even to us, then go ahead and provide
an example using other names, but please regard this as the last choice.
mysqld
daemon as well as the options that you use to run any MySQL client programs.
The options to programs like 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 number(s) 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.
If we can't verify exactly what the patch is meant for, we won't use it. Test cases will help us here. Show that the patch will handle all the situations that may occur. If we find a borderline case (even a rare one) where the patch won't work, it may be useless.
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://www.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 e-mail
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 MySQL Change History.
myisamchk
or CHECK TABLE
and
REPAIR TABLE
. See section Database Administration.
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 How to Determine What Is Causing Problems.
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 if someone else has experienced (and perhaps solved) the problem.
For information on reporting bugs in MyODBC
, see How to Report Problems with MyODBC.
For solutions to some common problems, see Problems and Common Errors.
When answers are sent to you individually and not to the mailing list, it is considered good etiquette to summarise 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 summarise 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 SQL questions welcome.
#mysqlphp
Questions about MySQL+PHP, a popular combination.
#mysqlperl
Questions about MySQL+Perl, another popular combination.
#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.
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.
Our goal is to not, without a very good reason, restrict MySQL Server usability for any usage. Even if we don't have the resources to do 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-99 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 big
part of our users. (The new HANDLER
interface in MySQL Server 4.0
is an example of this strategy. See section HANDLER
.)
We will continue to support transactional and non-transactional databases to satisfy both heavy web/logging usage and mission-critical 24/7 usage.
MySQL Server was designed from the start to work with medium size databases (10-100 million rows, or about 100 MB per table) on small computer systems. We will continue to extend MySQL Server to work even better with terabyte-size databases, as well as to make it possible to compile a reduced MySQL version that is more suitable for hand-held devices and embedded usage. The compact design of the MySQL server makes both of these directions possible without any conflicts in the source tree.
We are currently not targeting realtime support or clustered databases (even if you can already do a lot of things with our replication services).
We are looking at providing XML support in the database server.
Entry-level SQL-92. ODBC levels 0-3.51.
We are aiming toward supporting the full SQL-99 standard, but without concessions to speed and quality of the code.
If you start mysqld
with the --ansi
or --sql-mode=ANSI
option, the following behaviours of MySQL Server change:
||
is a string concatenation operator rather than a synonym for
OR
.
USER()
function,
the name of the user
table in the mysql
database and the User
column in that table become reserved,
so you must quote them:
SELECT "User" FROM mysql."user"; |
REAL
is a synonym for FLOAT
instead of a synonym for
DOUBLE
.
SERIALIZABLE
.
See section SET TRANSACTION
.
GROUP BY
that is not in the
field list.
Running the server in ANSI mode is the same as starting it with these options:
--sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY --transaction-isolation=SERIALIZABLE |
In MySQL 4.1, you can achieve the same effect with these two statements:
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET GLOBAL sql_mode = "REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY"; |
In MySQL 4.1.1, the sql_mode
options shown can be also be set with:
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 by doing:
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 '!'
, the syntax will be
executed only if the MySQL version is equal to or newer than the used
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 is a list of MySQL extensions:
MEDIUMINT
, SET
, ENUM
, and the
different BLOB
and TEXT
types.
AUTO_INCREMENT
, BINARY
, NULL
,
UNSIGNED
, and ZEROFILL
.
BINARY
attribute or use the BINARY
cast, which causes
comparisons to be done according to the ASCII order used on the
MySQL server host.
This has a few implications:
db_name.tbl_name
syntax. Some SQL servers provide
the same functionality but call this User space
.
MySQL Server doesn't support tablespaces as in:
create table ralph.my_table...IN my_tablespace
.
LIKE
is allowed on numeric columns.
INTO OUTFILE
and STRAIGHT_JOIN
in a SELECT
statement. See section SELECT
.
SQL_SMALL_RESULT
option in a SELECT
statement.
EXPLAIN SELECT
to get a description of how tables are joined.
INDEX
or KEY
in a CREATE TABLE
statement. See section CREATE TABLE
.
TEMPORARY
or IF NOT EXISTS
with CREATE TABLE
.
COUNT(DISTINCT list)
where list
has more than one element.
CHANGE col_name
, DROP col_name
, or DROP
INDEX
, IGNORE
or RENAME
in an ALTER TABLE
statement. See section ALTER TABLE
.
RENAME TABLE
. See section RENAME TABLE
.
ADD
, ALTER
, DROP
, or CHANGE
clauses in an ALTER TABLE
statement.
DROP TABLE
with the keywords IF EXISTS
.
DROP TABLE
statement.
ORDER BY
and LIMIT
clauses of the UPDATE
and
DELETE
statements.
DELAYED
clause of the INSERT
and REPLACE
statements.
LOW_PRIORITY
clause of the INSERT
, REPLACE
,
DELETE
, and UPDATE
statements.
LOAD DATA INFILE
. In many cases, this syntax is compatible with
Oracle's LOAD DATA INFILE
. See section LOAD DATA
.
ANALYZE TABLE
, CHECK TABLE
, OPTIMIZE TABLE
, and
REPAIR TABLE
statements.
SHOW
statement.
See section SHOW
.
SET
statement. See section SET
.
GROUP BY
part.
This gives better performance for some very specific, but quite normal
queries.
See section Functions and Modifiers for Use with GROUP BY
Clauses.
ASC
and DESC
with GROUP BY
.
||
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-99 ||
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.
CREATE DATABASE
or DROP DATABASE
.
See section CREATE DATABASE
.
%
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.
See section mysql_insert_id()
.
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()
, or
WEEKDAY()
functions.
TRIM()
to trim substrings. SQL-99 supports removal
of single characters only.
GROUP BY
functions STD()
, BIT_OR()
,
BIT_AND()
, and GROUP_CONCAT()
.
See section Functions and Modifiers for Use with GROUP BY
Clauses.
REPLACE
instead of DELETE
+ INSERT
.
See section REPLACE
.
FLUSH
, RESET
and DO
statements.
:=
:
SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg FROM test_table; SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3; |
We try to make MySQL Server follow the ANSI SQL standard (SQL-92/SQL-99) and the ODBC SQL standard, but in some cases MySQL Server does things differently:
VARCHAR
columns, trailing spaces are removed when the value is
stored. See section Known Errors and Design Deficiencies in MySQL.
CHAR
columns are silently changed to VARCHAR
columns. See section Silent Column Specification Changes.
REVOKE
to revoke privileges for
a table. See section GRANT
.
NULL AND FALSE
will evaluate to NULL
and not to FALSE
.
This is because we don't think it's good to have to evaluate a lot of
extra conditions in this case.
For a prioritised list indicating when new extensions will be added to MySQL Server, you should consult the online MySQL TODO list at http://www.mysql.com/doc/en/TODO.html. That is the latest version of the TODO list in this manual. See section MySQL and The Future (The TODO).
Subqueries are supported in MySQL version 4.1. See section Features Available in MySQL 4.1.
Up to version 4.0, only nested queries of the form
INSERT ... SELECT ...
and REPLACE ... SELECT ...
are supported.
You can, however, use the function IN()
in other contexts.
You can often rewrite the query without a subquery:
SELECT * FROM table1 WHERE id IN (SELECT id FROM table2); |
This can be rewritten as:
SELECT table1.* FROM table1,table2 WHERE table1.id=table2.id; |
The queries:
SELECT * FROM table1 WHERE id NOT IN (SELECT id FROM table2); SELECT * FROM table1 WHERE NOT EXISTS (SELECT id FROM table2 WHERE table1.id=table2.id); |
Can be rewritten as:
SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id WHERE table2.id IS NULL; |
Using a LEFT [OUTER] JOIN
is generally much faster than an
equivalent subquery because the server can optimise it better,
a fact that is not specific to MySQL Server alone.
Prior to SQL-92, outer joins did not exist, so subqueries were the
only way to do certain things in those bygone days. But that is no
longer the case, MySQL Server and many other modern database
systems offer a whole range of outer joins types.
For more complicated subqueries you can often create temporary tables
to hold the subquery. In some cases, however, this option will not
work. The most frequently encountered of these cases arises with
DELETE
statements, for which standard SQL does not support joins
(except in subqueries). For this situation there are three options
available:
SELECT
query to obtain the primary keys
for the records to be deleted, and then use these values to construct
the DELETE
statement (DELETE FROM ... WHERE ... IN (key1,
key2, ...)
).
DELETE
statements automatically, using the MySQL
extension CONCAT()
(in lieu of the standard ||
operator).
For example:
SELECT CONCAT('DELETE FROM tab1 WHERE pkid = ', "'", tab1.pkid, "'", ';') FROM tab1, tab2 WHERE tab1.col1 = tab2.col2; |
You can place this query in a script file and redirect input from it to
the mysql
command-line interpreter, piping its output back to a
second instance of the interpreter:
shell> mysql --skip-column-names mydb < myscript.sql | mysql mydb |
MySQL Server 4.0 supports multi-table DELETE
s that can be used to
efficiently delete rows based on information from one table or even
from many tables at the same time.
SELECT INTO TABLE
MySQL Server doesn't yet support the Oracle SQL extension:
SELECT ... INTO TABLE ...
. Instead, MySQL Server supports the
SQL-99 syntax INSERT INTO ... SELECT ...
, which is basically
the same thing. See section INSERT ... SELECT
Syntax.
INSERT INTO tblTemp2 (fldID) SELECT tblTemp1.fldOrder_ID FROM tblTemp1 WHERE tblTemp1.fldOrder_ID > 100; |
Alternatively, you can use SELECT INTO OUTFILE...
or
CREATE TABLE ... SELECT
.
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 MySQL Table Types.
The other non-transactional table types (such as MyISAM
) in
MySQL Server 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, the user is able to decide if he needs the speed of atomic operations or if he needs to use transactional features in his applications. This choice can be made on a per-table basis.
As noted, the trade off for transactional vs. non-transactional table
types lies mostly in performance. Transactional tables have significantly
higher memory and diskspace requirements, and more CPU overhead.
That said, transactional table types such as InnoDB
do of course
offer many unique features. MySQL Server's modular design allows the
concurrent use of all these different storage engines to suit different
requirements and deliver optimum performance in all situations.
But how does one 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
instead of
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.
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, one 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.
To be safe with MySQL Server, whether using transactional tables or not, you only need to have backups and have the binary logging turned on. With this you can recover from any situation that you could with any other transactional database system. It is, of course, always good to have backups, independent of which database system you use.
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 only obtain a read lock
(as opposed to a write lock), reads and inserts are still allowed
to happen. The new inserted records will not be seen by any of the
clients that have a read lock until they release their read
locks. 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 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 when you can 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.
This is usually a much faster method than using transactions with
possible ROLLBACK
s, although not always. The only situation
this solution doesn't handle is when someone kills the threads in the
middle of an update. In this case, all locks will be released but some
of the updates may not have been executed.
For example, when we are doing updates to some customer information, we
update only the customer data that has changed and test only that none of
the changed data, or data that depends on the changed data, has changed
compared to the original row. The test for changed data is done with the
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 the user can decide which version of the customer record
he should 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_he_owes_us=money_he_owes_us-125 WHERE customer_id=id AND address='old address' AND phone='old phone'; |
As you can see, this is very efficient and works even if another client
has changed the values in the pay_back
or money_he_owes_us
columns.
ROLLBACK
and/or LOCK
TABLES
for the purpose of managing unique identifiers for some tables.
This can be handled much more efficiently by using an
AUTO_INCREMENT
column and either the SQL function
LAST_INSERT_ID()
or the C API function mysql_insert_id()
.
See section mysql_insert_id()
.
You can generally code around row-level locking. Some situations really
need it, but they are very few. InnoDB
tables support row-level
locking. With MyISAM, 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 being implemented in our version 5.0 development tree. See section Installing from the Development Source Tree.
This effort is based on SQL-99, which has a basic syntax similar (but not identical) to Oracle PL/SQL. In addition to this, we are implementing the SQL-99 framework to hook in external languages.
A stored procedure is a set of SQL commands that can be compiled and stored in the server. Once this has been done, clients don't need to keep re-issuing the entire query but can refer to the stored procedure. This provides better overall performance because the query has to be parsed only once, and less information needs to be sent between the server and the client. You can also raise the conceptual level by having libraries of functions in the server. However, stored procedures of course do increase the load on the database server system, as more of the work is done on the server side and less on the client (application) side.
Triggers will also be implemented. A trigger is effectively a type of stored procedure, one that is invoked when a particular event occurs. For example, you can install a stored procedure that is triggered each time a record is deleted from a transactional table and that stored procedure automatically deletes the corresponding customer from a customer table when all his transactions are deleted.
In MySQL Server 3.23.44 and up, InnoDB
tables support checking of
foreign key constraints, including CASCADE
, ON DELETE
, and
ON UPDATE
. See section FOREIGN KEY
Constraints.
For other table types, MySQL Server only parses the FOREIGN KEY
syntax in CREATE TABLE
commands, but does not use/store this info.
Note that foreign keys in SQL are not used to join tables, but are used
mostly for checking referential integrity (foreign key constraints). If
you want to get results from multiple tables from a SELECT
statement, you do this by joining tables:
SELECT * FROM table1,table2 WHERE table1.id = table2.id; |
See section JOIN
. See section Using Foreign Keys.
When used as a constraint, FOREIGN KEY
s don't need to be used if
the application inserts rows into MyISAM
tables in the proper order.
For MyISAM
tables, you can work around the lack of ON DELETE
by adding the appropriate DELETE
statement to an application when you
delete records from a table that has a foreign key. In practice this is as
quick (in some cases quicker) and much more portable than using foreign keys.
In MySQL Server 4.0 you can use multi-table delete to delete rows from many
tables with one command. See section DELETE
Syntax.
The FOREIGN KEY
syntax without ON DELETE ...
is often used
by ODBC applications to produce automatic WHERE
clauses.
In the near future we will extend the FOREIGN KEY
implementation
so that the information is stored in the table specification file
and may be retrieved by mysqldump
and ODBC. At a later stage we
will implement foreign key constraints for MyISAM
tables as well.
Do keep in mind that foreign keys are often misused, which can cause severe problems. Even when used properly, it is not a magic solution for the referential integrity problem, although it can make things easier.
Some advantages of foreign key enforcement:
Disadvantages:
We plan to implement views in MySQL Server in version 5.1
Historically, MySQL Server has been most used in applications and on web systems where the application writer has full control over database usage. Of course, usage has shifted over time, and so we find that an increasing number of users now regard views as an important aspect.
Views are useful for allowing users to access a set of relations as if it were a single table, and limiting their access to just that. Many DBMS don't allow updates to a view, instead you have to perform the updates on the individual tables.
Views can also be used to restrict access to rows (a subset of a particular table). One does not need views to restrict access to columns, as MySQL Server has a sophisticated privilege system. See section General Security Issues and the MySQL Access Privilege System.
In designing our implementation of views, we aim toward (as fully as possible within the confines of SQL) compliance with "Codd's Rule #6" for relational database systems: all views that are theoretically updatable, should in practice also be updatable. This is a complex issue, and we are taking the time to make sure we get it right.
The implementation itself will be done in stages.
Unnamed views (derived tables, a subquery in the FROM
clause of a SELECT
) are already implemented in version 4.1.
Note: If you are an enterprise level user with an urgent need for views, please contact sales@mysql.com to discuss sponsoring options. Targeted financing of this particular effort by one or more companies would allow us to allocate additional resources to it. One example of a feature sponsored in the past is replication.
Some other SQL databases use `--' to start comments.
MySQL Server has `#' as the start comment character. You can also use
the C comment style /* this is a comment */
with MySQL Server.
See section Comment Syntax.
MySQL Server Version 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). This is because this
comment style has caused many 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 tbl_name SET credit=credit-!payment! |
Think about what happens if the value of payment
is negative.
Because 1--1
is legal in SQL, the consequences of allowing
comments to start with `--' are terrible.
Using our implementation of this method of commenting in MySQL Server
Version 3.23.3 and up, 1-- This is a comment
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:
shell> replace " --" " #" < text-file-with-funny-comments.sql \ | mysql database |
instead of the usual:
shell> mysql database < 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 |
As MySQL allows you to work with both transactional and non-transactional tables (which don't allow rollback), constraint handling is a bit different in MySQL than in other databases.
We have to handle the case when you have updated a lot of rows with a non-transactional table which can't rollback on errors.
The basic philosophy is to try to give an error for anything that we can detect on compile time but try to recover from any errors we get run time. We do this in most cases, but not yet for all. See section New Features Planned For The Near Future.
The basic options MySQL has is to stop the statement in the middle or do it's best to recover from the problem and continue.
Here follows what happens with the different types of constraints.
1.7.5.1 Constraint PRIMARY KEY / UNIQUE | ||
1.7.5.2 Constraint NOT NULL and DEFAULT values | ||
1.7.5.3 Constraint ENUM and SET |
Normally you will get an error when you try to INSERT
/
UPDATE
a row that causes a primary key, unique key or foreign key
violation. If you are using a transactional storage engine, like
InnoDB, MySQL will automatically roll back the transaction. If you are
using a non-transactional storage engine MySQL will stop at the wrong
row and leave the rest of the rows unprocessed.
To make life easier MySQL has added support for the IGNORE
directive to most commands that can cause a key violation (like
INSERT IGNORE ...
). In this case MySQL will ignore any key
violation and continue with processing the next row. You can get
information of what MySQL did with the mysql_info()
API function
and in later MySQL 4.1 version with the SHOW WARNINGS
command. See section mysql_info()
. See section SHOW WARNINGS | ERRORS
.
Note that for the moment only InnoDB
tables support foreign keys.
See section FOREIGN KEY
Constraints.
Foreign key support in MyISAM
tables is scheduled for inclusion
in the MySQL 5.0 source tree.
NOT NULL
and DEFAULT
values To be able to support easy handling of non-transactional tables all fields in MySQL have default values.
If you insert a 'wrong' value in a column like a NULL
in a
NOT NULL
column or a too big numerical value in a numerical
column, MySQL will instead of giving an error instead set the column to
the 'best possible value'. For numerical values this is 0, the smallest
possible values or the largest possible value. For strings this is
either the empty string or the longest possible string that can be in
the column.
This means that if you try to store NULL
into a column that
doesn't take NULL
values, MySQL Server will store 0 or ''
(empty string) in it instead. This last behaviour can, for single row
inserts, be changed with the -DDONT_USE_DEFAULT_FIELDS
compile
option.) See section Typical configure
Options.
This causes INSERT
statements to generate an error unless you
explicitly specify values for all columns that require a non-NULL
value.
The reason for the above rules is that we can't check these conditions before the query starts to execute. If we encounter a problem after updating a few rows, we can't just rollback as the table type may not support this. The option to stop is not that good as 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 we plan to improve this by providing warnings for automatic field conversions, plus an option to let you roll back statements that only use transactional tables in case one such statement does a field assignment that is not allowed.
The above means that one should generally not use MySQL to check field content, but instead handle this in the application.
ENUM
and SET
In MySQL 4.x ENUM
is not a real constrain but a more efficient
way to store fields that can only contain a given set of values.
This is because of the same reasons NOT NULL
is not honoured.
See section Constraint NOT NULL
and DEFAULT
values.
If you insert an wrong value in an ENUM
field, it will be set to
the reserved enum number 0
, which will be displayed as an empty
string in string context. See section The ENUM
Type.
If you insert an wrong option in a SET
field, the wrong value
will be ignored. See section The SET
Type.
1.7.6.1 Errors in 3.23 Fixed in a Later MySQL Version | ||
1.7.6.2 Open Bugs / Design Deficiencies in MySQL |
The following known errors/bugs are not fixed in MySQL 3.23 because fixing them would involves changing a lot of code which could introduce other even worse bugs. The bugs are also classified as 'not fatal' or 'bearable'.
LOCK TABLE
on multiple tables
and then in the same connection doing a DROP TABLE
on one of
them while another thread is trying to lock the table. One can however
do a KILL
on any of the involved threads to resolve this.
Fixed in 4.0.12.
SELECT MAX(key_column) FROM t1,t2,t3...
where one of the tables are
empty doesn't return NULL
but instead the maximum value for the
column. Fixed in 4.0.11.
DELETE FROM heap_table
without a WHERE
doesn't work on a locked
HEAP table.
The following problems are known and fixing them is a high priority:
FLUSH TABLES WITH READ LOCK
does not block CREATE TABLE
or
COMMIT
, which make cause a problem with the binary log position when
doing a full backup of tables and the binary log.
ANALYZE TABLE
on a BDB table may in some cases make the table
unusable until one has restarted mysqld
. When this happens you will
see errors like the following in the MySQL error file:
001207 22:07:56 bdb: log_flush: LSN past current end-of-log |
FROM
part, but silently
ignores them. The reason for not giving an error is that many clients
that automatically generate queries add parentheses in the FROM
part even where they are not needed.
RIGHT JOINS
or combining LEFT
and
RIGHT
join in the same query may not give a correct answer as
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
part.
ALTER TABLE
on a BDB
table on which you are
running multi-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.
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 big table
cache.
CREATE ... SELECT
or
INSERT ... SELECT
which
feeds zeros or NULL
s into an auto_increment
column.
DELETE
if you are
deleting rows from a table which has foreign keys with ON DELETE
CASCADE
properties.
REPLACE ... SELECT
,
INSERT IGNORE ... SELECT
if you have
duplicate key values in the inserted data.
IF and only if all these queries have NO ORDER BY
clause guaranteeing a deterministic order.
Indeed, 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 optimisers on the master and
slave. A query will be optimised 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, since MySQL 4.1.1, OPTIMIZE
, ANALYZE
and REPAIR
are written to the binary log).
key_buffer_size
etc) are different on
the master and slave.
This problem may also affect database restoration using mysqlbinlog|mysql
.
The easiest way to avoid this problem in all cases is add an
ORDER BY
clause to
such non-deterministic queries to ensure that the rows are always
stored/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:
LIKE
is not multi-byte character
safe. Comparison is done
character by character.
RPAD
function, or any other string function that ends
up adding blanks to the right, in a query that has to use temporary
table to be resolved, then all resulting strings will be RTRIM'ed. This
is an example of the query:
SELECT RPAD(t1.field1, 50, ' ') AS f2, RPAD(t2.field2, 50, '
') AS f1 FROM table1 as t1 LEFT JOIN table2 AS t2 ON
t1.record=t2.joinID ORDER BY t2.record;
Final result of this bug is that use will not be able to get blanks on the right side of the resulting field.
The above behaviour exists in all versions of MySQL.
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 behaviour will be fixed in one of the 4.1 series releases.
CHAR(255)
) in table names, column names or enums.
This is scheduled to be fixed in version 5.1 when we have new table
definition format files.
SET CHARACTER SET
, one can't use translated
characters in database, table, and column names.
_
or %
with ESCAPE
in LIKE
... ESCAPE
.
DECIMAL
column with a number stored in different
formats (+01.00, 1.00, 01.00), GROUP BY
may regard each value
as a different value.
DELETE FROM merge_table
used without a WHERE
will only clear the mapping for the table, not delete everything in the
mapped tables.
BLOB
values can't "reliably" be used in GROUP BY
or
ORDER BY
or DISTINCT
. Only the first max_sort_length
bytes (default 1024) are used when comparing BLOB
s in these cases.
This can be changed with the -O max_sort_length
option to
mysqld
. A workaround for most cases is to use a substring:
SELECT DISTINCT LEFT(blob,2048) FROM tbl_name
.
BIGINT
or DOUBLE
(both are
normally 64 bits long). It depends on the function which precision one
gets. 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. One should try to
avoid using unsigned long long values if they resolve to be bigger than
63 bits (9223372036854775807) for anything else 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, and may be regarded as a feature according to SQL-92. 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 `'hostname'.err' instead of `'hostname'.log' so 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 will get the updated value instead of the
original value. For example:
mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1; |
This will update KEY
with 2
instead of with 1
.
mysql> SELECT * FROM temporary_table, temporary_table AS t2; |
RENAME
doesn't work with TEMPORARY
tables or tables used in a
MERGE
table.
DISTINCT
differently if you are using
'hidden' columns in a join or not. In a join, hidden columns are
counted as part of the result (even if they are not shown) while 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 may in MySQL Server 3.23.x get two identical rows
in the result set (because 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, something that you are not allowed to do in SQL-92.
rollback
data, some things
behave a little differently in MySQL Server than in other SQL servers.
This is just to ensure that MySQL Server never needs to do a rollback
for an SQL command. This may be a little awkward at times as column
values must be checked in the application, but this will actually give
you a nice speed increase as it allows MySQL Server to do some
optimisations that otherwise would be very hard to do.
If you set a column to an incorrect value, MySQL Server will, instead of
doing a rollback, store the best possible value
in the column:
NULL
into a column that doesn't take
NULL
values, MySQL Server will store 0 or ''
(empty
string) in it instead. (This behaviour can, however, be changed with the
-DDONT_USE_DEFAULT_FIELDS compile option.)
DATE
and
DATETIME
columns (like 2000-02-31 or 2000-02-00). The idea is
that it's not the SQL server job to validate date. If MySQL can store a
date and retrieve exactly the same date, then MySQL will store the
date. If the date is totally wrong (outside the server's ability to store
it), then the special date value 0000-00-00 will be stored in the column.
ENUM
column to an unsupported value, it will be set to
the error value empty string
, with numeric value 0.
SET
column to an unsupported value, the value will
be ignored.
PROCEDURE
on a query that returns an empty set,
in some cases the PROCEDURE
will not transform the columns.
MERGE
doesn't check if the underlying
tables are of compatible types.
NaN
, -Inf
, and Inf
values in double. Using these will cause problems when trying to export
and import data. We should as an intermediate solution change NaN
to
NULL
(if possible) and -Inf
and Inf
to the
minimum respective maximum possible double
value.
LIMIT
on negative numbers are treated as big positive numbers.
ALTER TABLE
to first add a UNIQUE
index to a
table used in a MERGE
table and then use ALTER TABLE
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
keys before
normal keys to be able to detect duplicate keys as early as possible.
The following are known bugs in earlier versions of MySQL:
DROP TABLE
on a table that is
one among many tables that is locked with LOCK TABLES
.
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:
mysql> 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 platform-specific bugs, see the sections about compiling and porting.
This section summarises the features that we plan to implement in
MySQL Server
. The lists are broken up per version, and the items
are approximately in the order they will be done.
Note: If you are an enterprise level user with an urgent need for a particular feature, please contact sales@mysql.com to discuss sponsoring options. Targeted financing by one or more companies allows us to allocate additional resources for that specific purpose. One example of a feature sponsored in the past is replication.
The features below are not yet implemented in MySQL 4.1, but are planned for implementation before MySQL 4.1 moves into its beta phase. For a list what is already done in MySQL 4.1, see Features Available in MySQL 4.1.
Development of other things has already shifted to the 5.0 tree.
The following features are planned for inclusion into MySQL 5.0. Note that because we have many developers that are working on different projects, there will also be many additional features. There is also a small chance that some of these features will be added to MySQL 4.1. For a list what is already done in MySQL 4.1, see Features Available in MySQL 4.1.
For those wishing to take a look at the bleeding edge of MySQL development, we have made our BitKeeper repository for MySQL version 5.0 publicly available. See section Installing from the Development Source Tree.
RTREE
index for MyISAM tables. In 4.1 RTREE indexes are
used internally for geometrical data, but not directly usable.
VARCHAR
support (there is already support for this in
MyISAM
).
SHOW COLUMNS FROM table_name
(used by mysql
client to allow
expansions of column names) should not open the table, only the
definition file. This will require less memory and be much faster.
DELETE
on MyISAM
tables to use the record cache.
To do this, we need to update the threads record cache when we update
the `.MYD' file.
HEAP
) tables:
SET CHARACTER SET
we should translate the whole query
at once and not only strings. This will enable users to use the translated
characters in database, table, and column names.
RENAME TABLE
on a table used in an active
MERGE
table possibly corrupting the table.
FOREIGN KEY
support for all table types.
BIT
type to take 1 bit (now BIT
takes 1 char).
RENAME DATABASE
. To make this safe for all storage engines,
it should work as follows:
RENAME
command.
CONNECT BY PRIOR ...
to search tree-like (hierarchical)
structures.
SUM(DISTINCT)
.
INSERT SQL_CONCURRENT
and mysqld --concurrent-insert
to do
a concurrent insert at the end of the file if the file is read-locked.
UPDATE
statements. For example:
UPDATE TABLE foo SET @a=a+b,a=@a, b=@a+c
.
GROUP BY
, as in the following example:
SELECT id, @a:=COUNT(*), SUM(sum_col)/@a FROM table_name GROUP BY id
.
IMAGE
option to LOAD DATA INFILE
to not update
TIMESTAMP
and AUTO_INCREMENT
fields.
LOAD DATA INFILE ... UPDATE
syntax.
LOAD DATA INFILE ... REPLACE INTO
now.
LOAD DATA INFILE
understand syntax like:
LOAD DATA INFILE 'file_name.txt' INTO TABLE tbl_name TEXT_FIELDS (text_field1, text_field2, text_field3) SET table_field1=CONCAT(text_field1, text_field2), table_field3=23 IGNORE text_field3 |
This can be used to skip over extra columns in the text file, or update columns based on expressions of the read data.
SET
type columns:
ADD_TO_SET(value,set)
REMOVE_FROM_SET(value,set)
mysql
in the middle of a query, you should open
another connection and kill the old running query.
Alternatively, an attempt should be made to detect this in the server.
SHOW INFO FROM tbl_name
for basic table information
should be implemented.
SELECT a FROM crash_me LEFT JOIN crash_me2 USING (a)
; in this
case a
is assumed to come from the crash_me
table.
DELETE
and REPLACE
options to the UPDATE
statement
(this will delete rows when one gets a duplicate key error while updating).
DATETIME
to store fractions of seconds.
DEFAULT
values to columns. Give an error
when using an INSERT
that doesn't contain a column that doesn't
have a DEFAULT
.
ANY()
, EVERY()
, and SOME()
group functions. In
standard SQL these work only on boolean columns, but we can extend these to
work on any columns/expressions by applying: value == 0 -> FALSE and
value <> 0 -> TRUE.
MAX(column)
is the same as the column type:
mysql> CREATE TABLE t1 (a DATE); mysql> INSERT INTO t1 VALUES (NOW()); mysql> CREATE TABLE t2 SELECT MAX(a) FROM t1; mysql> SHOW COLUMNS FROM t2; |
INSERT ... SELECT
to optionally use concurrent inserts.
pread()
/pwrite()
on Windows to enable
concurrent inserts.
SELECT MIN(column) ... GROUP BY
.
long_query_time
with a granularity
in microseconds.
myisampack
code into the server, enabling a PACK or
COMPRESS command on the server.
INSERT/DELETE/UPDATE
so that we
can gracefully recover if the index file gets full.
ALTER TABLE
on a table that is symlinked to another
disk, create temporary tables on this disk.
DATE/DATETIME
type that handles time zone information
properly so that dealing with dates in different time zones is easier.
MyISAM
)
without threads.
LIMIT
, like in LIMIT @a,@b
.
mysql
to a web browser.
LOCK DATABASES
(with various options).
SHOW STATUS
. Records reads and
updates. Selects on 1 table and selects with joins. Mean number of
tables in select. Number of ORDER BY
and GROUP BY
queries.
mysqladmin copy database new-database
; requires COPY
command to be added to mysqld
.
SHOW HOSTS
for printing information about the hostname cache.
NULL
for calculated columns.
Item_copy_string
on numerical values to avoid
number->string->number conversion in case of:
SELECT COUNT(*)*(id+0) FROM table_name GROUP BY id
ALTER TABLE
doesn't abort clients
that execute INSERT DELAYED
.
UPDATE
clause,
they contain the old values from before the update started.
get_changed_tables(timeout,table1,table2,...)
.
SET TIMESTAMP=#;
.
MINUS
, INTERSECT
, and FULL OUTER JOIN
.
(Currently UNION
[in 4.0] and LEFT|RIGHT OUTER JOIN
are supported.)
SQL_OPTION MAX_SELECT_TIME=#
to put a time limit on a query.
LIMIT
to allow retrieval of data from the end of a result set.
mysqld_safe
: according to FSSTND (which
Debian tries to follow) PID files should go into `/var/run/<progname>.pid'
and log files into `/var/log'. It would be nice if you could put the
"DATADIR" in the first declaration of "pidfile" and "log", so the
placement of these files can be changed with a single statement.
zlib()
for gzip
-ed files to LOAD DATA INFILE
.
BLOB
columns (partly solved now).
AUTO_INCREMENT
value when one sets a column to 0.
Use NULL
instead.
JOIN
with parentheses.
GET_LOCK
. When doing this,
one must also handle the possible deadlocks this change will introduce.
Time is given according to amount of work, not real time.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Hosting by: Hurra Communications Ltd.
Generated: 2007-01-26 17:58:44