 |
||
| ||
|
|
| ||||||
| ||||||
| ||||||
The MySQL (TM) 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 has Dual Licensing, which means
you can use the MySQL software free of charge under the GNU
General Public License (http://www.gnu.org/licenses/). You can
also purchase commercial MySQL licenses from MySQL AB
if you do not wish to be bound by the terms of the GPL. See section
1.4
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 section 1.3
What Is MySQL AB?.
MySQL Database
Server, see section 1.2.2
The Main Features of MySQL.
MySQL Database Software to new
architectures or operating systems, see section E
Porting to Other Systems.
MySQL Database Server, see
section 3
Tutorial Introduction.
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 mailing list at mysql@lists.mysql.com. See section 1.6.2.3
How to Report Bugs or Problems. The mysqlbug script should be
used to generate bug reports. For source distributions, the
mysqlbug script can be found in the `scripts' directory.
For binary distributions, mysqlbug can be found in the
`bin' directory. 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 Version 4.0.2-alpha. 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 Texinfo, plain text, Info, HTML,
PostScript, 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 PHP 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 is written and maintained by David Axmark, Michael (Monty) Widenius, Jeremy Cole, Arjen Lentz, and Paul DuBois. For other contributors, see section C Credits.
The copyright (2002) to this manual is owned by the Swedish company
MySQL AB. See section 1.4.2
Copyrights and Licenses Used by MySQL.
This manual uses certain typographical conventions:
constant
mysqladmin works, invoke it with the
--help option.''
When commands are shown that are meant to be executed 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
Often database, table, and column names must 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 and provided by MySQL AB. MySQL AB is a
commercial company that builds its business providing services around the
MySQL database. See section 1.3
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.
MySQL
Server. Since computers are very good at handling large amounts of data,
database management plays a central role in computing, as stand-alone
utilities, or as parts of other applications.
SQL part of ``MySQL''
stands for ``Structured Query Language''@-the most common
standardised language used to access databases.
Open Source.
Open Source means that it is possible for anyone to use and
modify. Anybody can download the MySQL software from the Internet
and use it without paying anything. Anybody so inclined can study the source
code and change it to fit their 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 1.4.3
MySQL Licenses.
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 to some other database managers on our benchmark
page. See section 5.1.4
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.
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.
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.
We once 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 perfectly clear. Our
base directory and a large number of our libraries and tools have had the prefix
``my'' for well over 10 years. However, Monty'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 following list describes some of the important characteristics of the
MySQL Database Software. See section 1.5
MySQL 4.0 In A Nutshell.
MySQL code has been tested with
Purify, a commercial memory leakage detector.
FLOAT, DOUBLE, CHAR,
VARCHAR, TEXT, BLOB,
DATE, TIME, DATETIME,
TIMESTAMP, YEAR, SET, and
ENUM types. See section 6.2
Column Types.
INSERT to insert a subset of a table's columns; those columns
that are not explicitly given values are set to their default values.
SELECT and
WHERE parts 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(), and MIN()).
LEFT OUTER JOIN and RIGHT OUTER
JOIN with ANSI 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 6.1.6
Is MySQL Picky About Reserved Words?.
MySQL Server with
some databases that contain 50 million records and we 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).
ODBC (Open-DataBase-Connectivity) support for Win32 (with
source). All ODBC 2.5 functions and many others. For example, you can use MS
Access to connect to your MySQL server. See section 8.3
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 as well. See section 4
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, we noticed that there were some pieces of
``untested code'' that were quickly found by the new users who made different
types of queries from us. Each new release has had fewer portability problems
(even though each new release has had many new features).
Each release of the MySQL Server has been usable. There have
only been problems when users try code from the ``gray zones.'' Naturally, new
users don't know what the gray zones are; this section attempts to indicate
those that are currently known. The descriptions mostly deal with Version 3.23
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 1.7.5
Known Errors and Design Deficiencies in MySQL.
The MySQL Server design is multi-layered with independent
modules. Some of the newer modules are listed here with an indication of how
well-tested each of them is:
MySQL 4.0.
InnoDB tables -- Stable (in 3.23 from
3.23.49)
InnoDB transactional table handler has now 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 -- Gamma
Berkeley DB code is very stable, but we are still
improving the BDB transactional table handler interface in
MySQL Server, so it will take some time before this is as well
tested as the other table types.
FULLTEXT -- Beta
MySQL 4.0.
MyODBC 2.50 (uses ODBC SDK 2.5) -- Gamma
MyISAM tables -- Gamma
MyISAM table
handler that checks if the table was closed properly on open and executes an
automatic check/repair of the table if it wasn't.
MyISAM tables in MySQL 4.0 for
faster insert of many rows.
fcntl()). In these cases, you should
run mysqld with the --skip-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, but
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 has a 4G limit on table size. With the new
MyISAM table type in MySQL Version 3.23, the maximum
table size is pushed up to 8 million terabytes (2 ^ 63 bytes).
Note, however, that operating systems have their own file-size limits. Here are some examples:
| Operating System | File-Size Limit |
| Linux-Intel 32 bit | 2G, 4G or more, depends on Linux version |
| Linux-Alpha | 8T (?) |
| Solaris 2.5.1 | 2G (possible 4G with patch) |
| Solaris 2.6 | 4G (can be changed with flag) |
| Solaris 2.7 Intel | 4G |
| Solaris 2.7 UltraSPARC | 512G |
On Linux 2.2 you can get bigger tables than 2G by using the LFS patch for the ext2 filesystem. On Linux 2.4 patches also exist for ReiserFS to get support for big files.
This means that the table size for MySQL databases is normally
limited by the operating system.
By default, MySQL tables have a maximum size of about 4G. 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 4.5.6
SHOW Syntax.
If you need bigger tables than 4G (and your operating system supports this),
you should set the AVG_ROW_LENGTH and MAX_ROWS
parameter when you create your table. See section 6.5.3
CREATE TABLE Syntax. You can also set these later with
ALTER TABLE. See section 6.5.4
ALTER TABLE Syntax.
If your big table is going to be read-only, you could use
myisampack to merge and compress many tables to one.
myisampack usually compresses a table by at least 50%, so you can
have, in effect, much bigger tables. See section 4.7.4
myisampack, The MySQL Compressed Read-only Table Generator.
You can go around the operating system file limit for MyISAM
data files by using the RAID option. See section 6.5.3
CREATE TABLE Syntax.
Another solution can be the included MERGE library, which allows
you to handle a collection of identical tables as one. See section 7.2 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 regarded 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 new YEAR
column type can store years 0 and 1901 to
2155 in 1 byte and display them using 2 or 4 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 shows that the DATE and DATETIME types will
not give any problems with future dates (they handle dates until the year 9999).
The TIMESTAMP type, which is used to store the current time, has
a range up to only 2030-01-01. TIMESTAMP has a range
of 1970 to 2030 on 32-bit machines (signed value). On
64-bit machines it handles times up to 2106 (unsigned value).
Even though MySQL Server is Y2K-compliant, it is your
responsibility to provide unambiguous input. See section 6.2.2.1
Y2K Issues and Date Types for MySQL Server's rules for dealing
with ambiguous date input data (data containing 2-digit year values).
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.
All the developers of the MySQL server are 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 each other 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 1.2
What Is MySQL?.
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.
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, and we use these revenues to fund product development and to
expand the MySQL business.
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 1.4.1
Support Offered by MySQL AB.
To order support at various levels, please visit the order section at https://order.mysql.com/ 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 as our documentation
and our sample applications, and it 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 goals related
to your MySQL applications. 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.
We plan to release the MySQL Certification Program in 2002. For
details see http://www.mysql.com/training/certification.html.
If you would like to be kept informed about the MySQL Certification
Program, please e-mail certification@mysql.com.
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, but 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 (like the requirement that your
own application becomes GPL as well), you may purchase a commercial
license for the same product from MySQL AB at https://order.mysql.com/. 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
section 1.4.3
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 table handler that offers ACID
support, row-level locking, crash recovery, multi-versioning, foreign key
support, and more. See section 7.5
InnoDB Tables.
MySQL AB has a worldwide partner programme
that covers training courses, consulting & 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 1.4.4
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 purchase within the last
half-year, and 70% plan to make one in the next months.
If you are interested in placing banner ads on our web site, http://www.mysql.com/, please send an e-mail message to advertising@mysql.com.
The MySQL web site (http://www.mysql.com/) provides the latest
information about MySQL and MySQL AB.
For press service and inquiries not covered in our News releases (http://www.mysql.com/news/), please send 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 section 1.4.1
Support Offered by MySQL AB. You can order your support contract at https://order.mysql.com/, or send an e-mail
message 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 at training@mysql.com.
See section 1.3.1.2
Training and Certification.
For information on the MySQL Certification Program, please see
http://www.mysql.com/training/certification.html.
If you would like to be kept informed about the MySQL Certification
Program, please e-mail certification@mysql.com. See section
1.3.1.2
Training and Certification.
If you're interested in consulting, please visit the consulting section at http://www.mysql.com/consulting/. If
you have restricted access to the Internet, please contact the MySQL
AB consulting staff at consulting@mysql.com. See section 1.3.1.3
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. 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 1.4.3
MySQL Licenses.
If you represent a business that is interested in partnering with MySQL
AB, please send e-mail to partner@mysql.com. See section 1.3.1.5
Partnering.
If you are interested in placing a banner advertisement on the
MySQL web site (http://www.mysql.com/), please send e-mail to
advertising@mysql.com. See section 1.3.1.6
Advertising.
For more information on the MySQL trademark policy, refer to http://www.mysql.com/company/trademark.html
or send e-mail to trademark@mysql.com.
See section 1.4.4
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/development/jobs/),
please send an e-mail message 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 1.6.2 MySQL Mailing Lists.
Reports of errors (often called bugs), as well as questions and comments,
should be sent to the mailing list at mysql@lists.mysql.com. If you have found
a sensitive security bug in the MySQL Server, please send an e-mail
to security@mysql.com. See section 1.6.2.3
How to Report Bugs or Problems.
If you have benchmark results that we can publish, please contact us at benchmarks@mysql.com.
If you have any suggestions concerning additions or corrections to this manual, please send them to the manual team at docs@mysql.com.
For questions or comments about the workings or content of the
MySQL web site (http://www.mysql.com/), please send e-mail to
webmaster@mysql.com.
Questions about the MySQL Portals (http://www.mysql.com/portal/) may be
sent to portals@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 e-mail privacy@mysql.com.
For all other inquires, please send e-mail to info@mysql.com.
This section describes MySQL support and licensing arrangements.
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, etc. 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 https://order.mysql.com/, where support contracts can also be ordered online. If you have restricted access to the Internet, contact our sales staff 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 troubles, it might take too long 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
1.3
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 H
GNU General Public License. The text of this license can also be found as
the file `COPYING' in the distributions.
GNU getopt library is covered by the
GNU Lesser General Public License. See section I
GNU Lesser General Public License.
regexp library) are covered by
a Berkeley-style copyright.
MySQL (3.22 and earlier) are subject to a
more strict license (http://www.mysql.com/support/arrangements/mypl.html).
See the documentation of the specific version for information.
GPL-style license. Use of the manual is subject to the following
terms:
MySQL
AB is required. For information about how the MySQL licenses work in practice,
please refer to section 1.4.3
MySQL Licenses. Also see section 1.4.4
MySQL AB Logos and Trademarks.
The MySQL software is released under the GNU General
Public License (GPL), which probably is 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/.
Older versions of MySQL (3.22 and earlier) are subject to a more
strict license (http://www.mysql.com/support/arrangements/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 1.4.4
MySQL AB Logos and Trademarks.
The GPL license is contagious in the sense that when a program
is linked to a GPL program the resulting product must also be
released under GPL lest you break the license terms and forfeit
your right to use the GPL program altogether.
You need a commercial license:
MySQL software or
from GPL released clients and don't want the resulting product to
be GPL, maybe 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 actually
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 1.4.1
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.
To purchase commercial licenses and support, please visit the order section of our web site at https://order.mysql.com/. If you have special licensing needs or you have restricted access to the Internet, please contact our sales staff at sales@mysql.com.
You can use the MySQL software for free under the
GPL:
MySQL software and
release the resulting product under GPL.
MySQL source code bundled with other
programs that are not linked to or dependent on MySQL Server for
their functionality even if you sell the distribution commercially.
MySQL software internally in your company.
MySQL servers for your customers. On the other hand,
we do encourage people to use ISPs that have MySQL support, as
this will give them the confidence that if they have some problem with the
MySQL installation, their ISP will in fact have the resources to
solve the problem for them. All ISPs that want to keep themselves up-to-date
should subscribe to our announce mailing list so that they can be
aware of critical issues that may be relevant for their MySQL
installations. Note that even if an ISP does not have a commercial license for
MySQL Server, they should at least give their customers read
access to the source of the MySQL installation so that the
customers can verify that it is patched correctly.
MySQL
Database Software in conjunction with a web server, you do not need a
commercial license. This is true even if you run a commercial web server that
uses MySQL Server, because you are not selling an embedded
MySQL version yourself. 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 1.4.1
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/downloads/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:
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 be able
to connect to a MySQL server. Contact us at trademark@mysql.com to inquire about special arrangements to fit your needs.
In the following cases you need a written permission from MySQL
AB before using MySQL logos:
MySQL AB logo anywhere except on your web
site.
MySQL AB logo except the Conditional
Use logos mentioned previously on web sites or elsewhere. Out of legal and commercial reasons we have to monitor the use of MySQL
trademarks on products, books, etc. We will 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 only be used by companies and
persons having a written partnership agreement with MySQL AB.
Partnerships include certification as a MySQL trainer or
consultant. Please see section 1.3.1.5
Partnering.
MySQL
in Printed Text or PresentationsMySQL AB welcomes references to the MySQL database,
but note that the word MySQL is a trademark of MySQL
AB. Because of this, you should 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. Please refer to our
trademark policy at http://www.mysql.com/company/trademark.html
for details.
MySQL in Company and Product NamesUse of the word MySQL in product or company names or in Internet
domain names is not allowed without written permission from MySQL
AB.
Dateline: 16 October 2001, Uppsala, Sweden
Long promised by MySQL AB and long awaited by our users, MySQL
Server 4.0 is now available in alpha version for download from http://www.mysql.com/ and our mirrors.
Main 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.
The rollout of MySQL Server 4.0 will come in several steps, with the first version labelled 4.0.0 already containing most of the new features. Additional features will be incorporated into MySQL 4.0.1, 4.0.2, and onward; very probably within a couple of months, MySQL 4.0 will be labelled beta. Further new features will then be added in MySQL 4.1, which is targeted for alpha release in third quarter 2002.
Users are not recommended to switch their production systems to MySQL Server 4.0 until it is released in beta version. However, even the initial release has passed our extensive test suite without any errors on any of the platforms we test on. Due to the large number of new features, we thus recommend MySQL Server 4.0 even in alpha form for development use, with the release schedule of MySQL Server 4.0 being such that it will reach stable state before the deployment of user applications now under development.
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, etc.
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 8.4.9
libmysqld, the Embedded MySQL Server Library.
INSERTs, searching on packed
indexes, creation of FULLTEXT indexes, as well as
COUNT(DISTINCT).
InnoDB is now offered as a feature of the
standard MySQL server, including full support for transactions
and row-level locking.
Secure Socket Layer
(SSL) to secure the traffic between the the end user browser and
the web application, be it written in PHP, Perl, ASP or using any other web
development tool. However, the traffic between the development tool and the
mysqld server process has been protected only by virtue of them
being processes residing on computers within the same firewall. In MySQL
Server 4.0, the mysqld server daemon process can itself use
SSL, thus enabling secure traffic to MySQL databases from, say, a
Windows application residing outside the firewall.
latin_de, which corrects the German sorting
order, placing German umlauts in the same order as German telephone
books.
TRUNCATE TABLE (like in Oracle) and IDENTITY
as a synonym for automatically incremented keys (like in Sybase). Many users
will also be happy to learn that MySQL Server now supports the
UNION statement, a long-awaited standard SQL feature.
DELETE statements. By adding support for symbolic
linking to MyISAM on the table level (and not just the
database level as before), as well as by enabling symlink handling by default
on Windows, we hope to show that we take enhancement requests seriously.
Functions like SQL_CALC_FOUND_ROWS and FOUND_ROWS()
make it possible to know how many rows a query would have returned without a
LIMIT clause. For the upcoming MySQL Server 4.0 releases (4.0.1, 4.0.2, and onward), expect the following features now still under development:
fail-safe replication; already existing in
4.0.0, the LOAD DATA FROM MASTER command will soon automate slave
setup. The online backup will make it easy to add a new
replication slave without taking down the master, and have a very low
performance penalty on update-heavy systems.
mysqld parameters (startup options) can soon be set without
taking down the servers.
FULLTEXT search properties of MySQL Server 4.0 enable
the use of FULLTEXT indexing of large text masses with both
binary and natural-language searching logic. Users can customise minimal word
length and define their own stop word lists in any human language, enabling a
new set of applications to be built on MySQL Server.
key cache.
MySQL command
help in the client. Internally, through a new .frm file format for table definitions, MySQL
Server 4.0 lays the foundation for the new features of MySQL Server 4.1 and
onward, such as nested subqueries, stored procedures,
and foreign key integrity rules, which form the top of the wish
list for many of our customers. Along with those, we will also include simpler
additions, such as multi-table UPDATE statements.
After those additions, critics of the MySQL Database Server have to be more imaginative than ever in pointing out deficiencies in the MySQL Database Management System. For long already known for its stability, speed, and ease of use, MySQL Server will then match the requirement checklist of very demanding buyers.
The MySQL Portals (http://www.mysql.com/portal/) represent
the ultimate resource to find MySQL AB Partners, as well as books,
or other MySQL-related solutions that you may be looking for. Items
are categorised and rated in order to make it easy for you to locate
information.
By registering as a user, you will have the ability to comment on and rate items presented in portals. You will also receive relevant newsletters according to your user profile that you may update at any time.
Some of the current MySQL Portal categories include:
MySQL AB partners worldwide.
MySQL.
MySQL Server
for different purposes, with a description of each site. This information can
give you an idea of who uses the MySQL database software and how
MySQL Server can fulfill requirements. Let us know about
your site or success story, too! Visit http://www.mysql.com/feedback/testimonial.php.
MySQL server.
MySQL software.
MySQL-related services. This section introduces you to the MySQL mailing lists, and gives some guidelines as to how to use them. By subscribing to a mailing list, you will receive as e-mail messages all other postings on the list, and you will be able to send in your own questions and answers.
To subscribe to the main MySQL mailing list, send a message to the electronic mail address mysql-subscribe@lists.mysql.com.
To unsubscribe from the main MySQL mailing list, send a message to the electronic mail address mysql-unsubscribe@lists.mysql.com.
Only the address to which you send your messages is significant. The subject line and the body of the message are ignored.
If your reply address is not valid, you can specify your address explicitly,
by adding a hyphen to the subscribe or unsubscribe command word, followed by
your address with the `@' character in your address replaced by a
`='. For example, to subscribe your_name@host.domain,
send a message to
mysql-subscribe-your_name=host.domain@lists.mysql.com.
Mail to mysql-subscribe@lists.mysql.com or mysql-unsubscribe@lists.mysql.com is handled automatically by the ezmlm mailing list processor. Information about ezmlm is available at the ezmlm web site (http://www.ezmlm.org/).
To post a message to the list itself, send your message to
mysql@lists.mysql.com. However, please do not send
mail about subscribing or unsubscribing to mysql@lists.mysql.com because any mail
sent to that address is distributed automatically to thousands of other users.
Your local site may have many subscribers to mysql@lists.mysql.com. If so, it may
have a local mailing list, so 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 following MySQL mailing lists exist:
announce-subscribe@lists.mysql.com
announce
mysql-subscribe@lists.mysql.com
mysql
mysql-digest-subscribe@lists.mysql.com
mysql-digest
mysql list in digest form. That means you get all
individual messages, sent as one large mail message once a day.
bugs-subscribe@lists.mysql.com
bugs
mysqlbug script (if you are running on Windows, you should
include a description of the operating system and the MySQL version).
Preferably, you should test the problem using the latest stable 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. All bugs posted on this list will be corrected or documented in the next
MySQL release! If only small code changes are needed, we will also post a
patch that fixes the problem.
bugs-digest-subscribe@lists.mysql.com
bugs-digest
bugs list in digest form.
internals-subscribe@lists.mysql.com
internals
internals-digest-subscribe@lists.mysql.com
internals-digest
internals list.
java-subscribe@lists.mysql.com
java
java-digest-subscribe@lists.mysql.com
java-digest
java list.
win32-subscribe@lists.mysql.com
win32
win32-digest-subscribe@lists.mysql.com
win32-digest
win32 list.
myodbc-subscribe@lists.mysql.com
myodbc
myodbc-digest-subscribe@lists.mysql.com
myodbc-digest
myodbc list.
mycc-subscribe@lists.mysql.com
mycc
MyCC graphical client.
mycc-digest-subscribe@lists.mysql.com
mycc-digest
mycc list.
plusplus-subscribe@lists.mysql.com
plusplus
plusplus-digest-subscribe@lists.mysql.com
plusplus-digest
plusplus list.
msql-mysql-modules-subscribe@lists.mysql.com
msql-mysql-modules
msql-mysql-modules-digest-subscribe@lists.mysql.com
msql-mysql-modules-digest
msql-mysql-modules list. You subscribe or unsubscribe to all lists in the same way as described
previously. In your subscribe or unsubscribe message, just put the appropriate
mailing list name rather than mysql. For example, to subscribe to
or unsubscribe from the myodbc list, send a message to myodbc-subscribe@lists.mysql.com
or myodbc-unsubscribe@lists.mysql.com.
If you can't get an answer for your questions from the mailing list, one option is to pay for support from MySQL AB, which will put you in direct contact with MySQL developers. See section 1.4.1 Support Offered by MySQL AB.
The following table shows some MySQL mailing in languages other than English. Note that these are not operated by MySQL AB, so we can't guarantee the quality on these.
mysql-france-subscribe@yahoogroups.com
A French mailing list
list@tinc.net A Korean mailing
list
subscribe mysql your@e-mail.address to this list.
mysql-de-request@lists.4t2.com
A German mailing list
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 Portugese mailing list
subscribe mysql-br your@e-mail.address to this list.
mysql-alta@elistas.net A
Spanish mailing list
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, go ahead and read the next section about how to send mail to mysql@lists.mysql.com.
Writing a good bug report takes patience, but doing it right the first time saves time for us and for you. A good bug report containing a full test case for the bug will make it very likely that we will fix it 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), if possible. mysqlbug
can be found in the `scripts' directory in the source distribution, or
for a binary distribution, in the `bin' directory under your MySQL
installation directory. If you are unable to use mysqlbug, you
should still include all the necessary information listed in this section.
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.
The normal place to report bugs and problems is mysql@lists.mysql.com. If you can make a
test case that clearly demonstrates the bug, you should post it to the bugs@lists.mysql.com list. Note that on
this list you should only post a full, repeatable bug report using the
mysqlbug script. If you are running on Windows, you should include
a description of the operating system and the MySQL version. Preferably, you
should test the problem using the latest stable 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 on the
bugs list will be corrected or documented in the next MySQL
release! If only small code changes are needed to correct this problem, we will
also post a patch that fixes the problem.
If you have found a sensitive security bug in MySQL, you should send an e-mail to security@mysql.com.
Remember that it is possible to respond to a message containing too much information, but not to one containing too little. Often people 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 are that people don't indicate the version number of the MySQL distribution they are using, or don't indicate what platform they have the MySQL server installed on (including the platform 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 been fixed already in newer MySQL versions. Sometimes the error is platform-dependent; in such cases, it is next to impossible 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 is used. Note that every compiling problem should be regarded as a bug report and reported accordingly.
It is most helpful when a good description of the problem is included in the bug report. That is, a good example of all the things you did that led to the problem and the problem itself exactly described. The best reports are those that include a full example showing how to reproduce the bug or problem. See section E.1.6 Making a Test Case When 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, you should try to generate a MyODBC trace file. See section 8.3.7 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.
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 E.1.5
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 that 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.
The more information you give about your situation, the more likely it is that
someone can help you! For example, 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 reproduceable test case, you
should post this to bugs@lists.mysql.com for a
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 of 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 send a short description of the problem to bugs@lists.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 and 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 anyway! 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.
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 query 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 D MySQL
Change History.
myisamchk or CHECK
TABLE and REPAIR TABLE. See section 4
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 A.1
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 section 8.3.4
How to Report Problems with MyODBC.
For solutions to some common problems, see section A Problems and Common Errors.
When answers are sent to you individually and not to the mailing list, it is considered good etiquette to 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!
This section describes how MySQL relates to the ANSI SQL standards. MySQL Server has many extensions to the ANSI SQL standards, 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 ANSI 99
compliancy, 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 6.4.2
HANDLER Syntax.)
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 don't believe that one should have native XML support in the database, but will instead add the XML support our users request from us on the client side. We think it's better to keep the main server code as ``lean and clean'' as possible and instead develop libraries to deal with the complexity on the client side. This is part of the strategy mentioned previously of not sacrificing speed or reliability in the server.
Entry-level SQL92. ODBC levels 0-3.51.
We are aiming toward supporting the full ANSI SQL99 standard, but without concessions to speed and quality of the code.
If you start mysqld with the --ansi option, the
following behavior of MySQL Server changes:
|| is string concatenation instead of OR.
REAL will be a synonym for FLOAT instead of a
synonym for DOUBLE.
SERIALIZABLE. See
section 6.7.3
SET TRANSACTION Syntax. This is the same as using
--sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,
IGNORE_SPACE,SERIALIZE,ONLY_FULL_GROUP_BY.
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 (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.
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 6.4.1
SELECT Syntax.
SQL_SMALL_RESULT option in a SELECT
statement.
EXPLAIN SELECT to get a description on how tables are joined.
INDEX or KEY in a CREATE TABLE
statement. See section 6.5.3
CREATE TABLE Syntax.
TEMPORARY or IF NOT EXISTS with
CREATE TABLE.
COUNT(DISTINCT list) where list is more
than one element.
CHANGE col_name, DROP col_name, or
DROP INDEX, IGNORE or RENAME in an
ALTER TABLE statement. See section 6.5.4
ALTER TABLE Syntax.
RENAME TABLE. See section 6.5.5
RENAME TABLE Syntax.
ADD, ALTER, DROP,
or CHANGE clauses in an ALTER TABLE statement.
DROP TABLE with the keywords IF EXISTS.
DROP TABLE
statement.
LIMIT clause of the DELETE statement.
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 6.4.9
LOAD DATA INFILE Syntax.
ANALYZE TABLE, CHECK TABLE, OPTIMIZE
TABLE, and REPAIR TABLE statements.
SHOW statement. See section 4.5.6
SHOW Syntax.
SET OPTION statement. See section 5.5.6
SET Syntax.
GROUP BY
part. This gives better performance for some very specific, but quite normal
queries. See section 6.3.7
Functions 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 ANSI SQL || operator for string
concatenation; use CONCAT() instead. Because
CONCAT() takes any number of arguments, it's easy to convert use
of the || operator to MySQL Server.
CREATE DATABASE or DROP DATABASE. See section 6.5.1
CREATE DATABASE Syntax.
% 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 8.4.3.126
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. ANSI SQL only supports
removal of single characters.
GROUP BY functions STD(),
BIT_OR(), and BIT_AND().
REPLACE instead of DELETE +
INSERT. See section 6.4.8
REPLACE Syntax.
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 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 1.7.5
Known Errors and Design Deficiencies in MySQL.
CHAR columns are silently changed to
VARCHAR columns. See section 6.5.3.1
Silent Column Specification Changes.
REVOKE to revoke privileges
for a table. See section 4.3.1
GRANT and REVOKE Syntax.
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/documentation/manual.php?section=TODO. That is the latest version of the TODO list in this manual. See section 1.8 MySQL and The Future (The TODO).
SELECTsMySQL Server currently only supports nested queries of the form INSERT
... SELECT ... and REPLACE ... SELECT .... You can, however,
use the function IN() in other contexts. Sub-selects are scheduled
for implementation in Version 4.x.
Meanwhile, you can often rewrite the query without a sub-select:
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;
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
sub-selects). For this situation there are two options available until
subqueries are supported by MySQL Server.
The first option is to use a procedural programming language (such as Perl or
PHP) to submit a 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,
...)).
The second option is to use interactive SQL to construct a set of
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 deletes 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 TABLEMySQL Server doesn't yet support the Oracle SQL extension: SELECT ...
INTO TABLE .... MySQL Server supports instead the ANSI SQL syntax
INSERT INTO ... SELECT ..., which is basically the same thing. See
section 6.4.3.1
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 supports transactions with the InnoDB and
BDB Transactional table handlers. See section 7
MySQL Table Types. InnoDB provides ACID
compliancy.
However, the non-transactional table types in MySQL Server such as
MyISAM follow another paradigm for data integrity called
``Atomic Operations.'' Atomic operations often offer equal or even
better integrity with much better performance. With MySQL Server supporting both
paradigms, the user is able to decide if he needs the speed of atomic operations
or if he need to use transactional features in his applications. This choice can
be made on a per-table basis.
How does one use the features of MySQL Server to maintain rigorous integrity and how do these features compare with the transactional paradigm?
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 database, which is a common problem
with transactional databases.
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 or better 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 6.4.4
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. ROLLBACKs, 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.
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+'relative change';
UPDATE customer
SET
customer_date='current_date',
address='new address',
phone='new phone',
money_he_owes_us=money_he_owes_us+'new_money'
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 8.4.3.126
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;
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 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.
A trigger is a stored procedure 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 transaction table and that automatically deletes the corresponding customer from a customer table when all his transactions are deleted.
The planned update language will be able to handle stored procedures. Our aim is to have stored procedures implemented in MySQL Server around version 4.1. We are also looking at triggers.
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 6.4.1.1
JOIN Syntax. See section 3.5.6
Using Foreign Keys.
In MySQL Server 3.23.44 and up, InnoDB tables support checking
of foreign key constraints. See section 7.5
InnoDB Tables. For other table types, MySQL Server does parse the
FOREIGN KEY syntax in CREATE TABLE commands, but
without further action being taken.
The FOREIGN KEY syntax without ON DELETE ... is
mostly used for documentation purposes. Some ODBC applications may use this to
produce automatic WHERE clauses, but this is usually easy to
override. FOREIGN KEY is sometimes used as a constraint check, but
this check is unnecessary in practice if rows are inserted into the tables in
the right order.
In MySQL Server, you can work around the problem of ON DELETE
... not being implemented 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 6.4.6
DELETE Syntax.
In the near future we will extend the FOREIGN KEY implementation
so that the information will be saved in the table specification file and may be
retrieved by mysqldump and ODBC. At a later stage we will implement
the foreign key constraints for applications that can't easily be coded to avoid
them.
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 does make things easier in some cases.
Some advantages of foreign key enforcement:
Disadvantages:
It is planned to implement views in MySQL Server around version 4.1.
Views are mostly useful for letting users access a set of relations as one table (in read-only mode). Many SQL databases don't allow one to update any rows in a view, but you have to do the updates in the separate tables.
As MySQL Server is mostly used in applications and on web systems where the application writer has full control on the database usage, most of our users haven't regarded views to be very important. (At least no one has been interested enough in this to be prepared to finance the implementation of views.)
One doesn't need views in MySQL Server to restrict access to columns, as MySQL Server has a very sophisticated privilege system. See section 4.2 General Security Issues and the MySQL Access Privilege System.
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 6.1.5
Comment Syntax.
MySQL Server Version 3.23.3 and above support the `--' comment
style, provided the comment is followed by a space. 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 a 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
The following problems are known and have a very high priority to get fixed:
ANALYZE TABLE on a BDB table may in some case 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
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.
LOAD DATA
INFILE and line terminator characters of more than 1 character.
The following problems are known and will be fixed in due time:
SET CHARACTER SET, one can't use translated
characters in database, table, and column names.
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
BLOBs 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 ANSI SQL92. The bug is that in MySQL Server, VARCHAR
columns are treated the same way.
ENUM and SET columns
in one table.
safe_mysqld 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
safe_mysqld 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 ANSI SQL.
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 a 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 behavior can, however, be changed with
the -DDONT_USE_DEFAULT_FIELDS compile option.)
DATE
and DATETIME columns (like 2000-02-31 or 2000-02-00). If the
date is totally wrong, MySQL Server will store the special 0000-00-00 date
value 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 appendix lists the features that we plan to implement in MySQL Server.
Everything in this list is approximately in the order it will be done. If you want to affect the priority order, please register a license or support us and tell us what you want to have done more quickly. See section 1.4 MySQL Support and Licensing.
The plan is that we in the future will support the full ANSI SQL99 standard, but with a lot of useful extensions. The challenge is to do this without sacrifying the speed or compromising the code.
We are now in the final stages of the development of the MySQL Server 4.0. server. The target is to quickly implement the rest of the following features and then shift development to MySQL Server 4.1. See section 1.5 MySQL 4.0 In A Nutshell.
The news section for 4.0 includes a list of the features we have already implemented in the 4.0 tree. See section D.1 Changes in release 4.0.x (Development; Alpha).
This section lists features not yet implemented in the current version of MySQL Server 4.0, which will, however, be implemented in later versions of MySQL 4.0. This being very volatile information, please consider this list valid only if you are reading it from the MySQL web site (http://www.mysql.com/).
FOREIGN KEY definitions.
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.
SET SQL_DEFAULT_TABLE_TYPE=[MyISAM | INNODB | BDB | HEAP].
The following features are planned for inclusion into MySQL 4.1. 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.0. Some of the work on MySQL 4.1 is already in progress.
SELECT id FROM t WHERE grp IN (SELECT grp FROM g WHERE u
> 100)
RAND() and user variables
@var.
SELECT a.col1, b.col2
FROM (SELECT MAX(col1) AS col1 FROM root_table) a,
other_table b
WHERE a.col1=b.col1;
This could be done by automatically creating temporary tables for the
derived tables for the duration of the query.
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.
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.
record_in_range() method to MERGE tables to
be able to choose the right index when there are many to choose from. We
should also extend the info interface to get the key distribution for each
index, if analyze is run on all subtables.
RENAME TABLE on a table used in an active MERGE
table may corrupt the table.
UNICODE.
RENAME DATABASE. To make this safe for all table
handlers, it should work as follows:
RENAME command.
VARCHAR support (there is already support for this
in MyISAM).
BIT type to take 1 bit (now BIT takes 1
char).
HEAP) tables:
update items,month set
items.price=month.price where items.id=month.id;;
INSERT ... SELECT to optionally use concurrent
inserts.
SELECT MIN(column) ...
GROUP BY.
long_query_time with a
granularity in microseconds.
mysql command-line client,
with options like database in use, time and date...
myisampack code into 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.
INSERT SQL_CONCURRENT and mysqld
--concurrent-insert to do a concurrent insert at the end of the file if
the file is read-locked.
lockd works with modern Linux kernels; if not, we
have to fix lockd! To test this, start mysqld with
--enable-locking and run the different fork* test suits. They
shouldn't give any errors if lockd works.
LIMIT, like in LIMIT
@a,@b.
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.
DEFAULT values to columns. Give an error
when using an INSERT that doesn't contain a column that doesn't
have a DEFAULT.
mysql_query() commands
in a row without reading results or give a nice error message when one does
this.
ctime() doesn't work on some FreeBSD
systems.
IMAGE option to LOAD DATA INFILE to not
update TIMESTAMP and AUTO_INCREMENT fields.
LOAD DATE 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.
LOAD DATA INFILE 'file_name' INTO TABLE 'table_name' ERRORS TO
err_table_name. This would cause any errors and warnings to be logged
into the err_table_name table. That table would have a structure
like: line_number - line number in datafile error_message - the error/warning message and maybe data_line - the line from the datafile
mysql to Netscape.
LOCK DATABASES (with various options.)
DECIMAL and NUMERIC types can't read exponential
numbers; Field_decimal::store(const char *from,uint len) must be
recoded to fix this.
t1 JOIN t2 ON ... and t1 JOIN t2 USING
... Currently, you can only use this syntax with LEFT
JOIN.
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.
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.
NATURAL JOIN.
SELECT a FROM crash_me LEFT JOIN crash_me2 USING (a);
in this case a is assumed to come from the crash_me
table.
ON and USING works with the
JOIN join type.
CONNECT BY PRIOR ... to search hierarchy
structures.
mysqladmin copy database new-database; requires
COPY command to be added to mysqld.
SHOW HOSTS for printing information about the hostname cache.
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.
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.
pread()/pwrite() on Windows to
enable concurrent inserts.
SUM(DISTINCT).
ANY(), EVERY(), and SOME()
group functions. In ANSI 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;
UPDATE
the row if it exists and INSERT a new row if the row didn't exist
(like REPLACE works with INSERT /
DELETE). get_changed_tables(timeout,table1,table2,...).
Show_priv for SHOW commands.
SET TIMESTAMP=#;.
MINUS, INTERSECT, and FULL OUTER
JOIN. (Currently UNION [in 4.0] and LEFT OUTER
JOIN are supported.)
SQL_OPTION MAX_SELECT_TIME=# to put a time limit on a query.
LIMIT to retrieve data from the end.
safe_mysqld: 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.
Our users have successfully run their own benchmarks against a number of
Open Source and traditional database servers. We are aware of tests
against Oracle server, DB/2 server, Microsoft
SQL Server, and other commercial products. Due to legal reasons we are
restricted from publishing some of those benchmarks in our reference manual.
This section includes a comparison with mSQL for historical
reasons and with PostgreSQL as it is also an Open
Source database. If you have benchmark results that we can publish,
please contact us at benchmarks@mysql.com.
For comparative lists of all supported functions and types as well as
measured operational limits of many different database systems, see the
crash-me web page at http://www.mysql.com/information/crash-me.php.
mSQLmSQL should be
quicker at:
INSERT operations into very simple tables with few columns
and keys.
CREATE TABLE and DROP TABLE.
SELECT on something that isn't an index. (A table scan is
very easy.) mSQL (and most other SQL
implementations) on the following:
SELECT operations.
VARCHAR columns.
SELECT with many expressions.
SELECT on large tables.
mSQL, once one connection is
established, all others must wait until the first has finished, regardless
of whether the connection is running a query that is short or long. When the
first connection terminates, the next can be served, while all the others
wait again, etc.
mSQL can become pathologically slow if you change
the order of tables in a SELECT. In the benchmark suite, a time
more than 15,000 times slower than MySQL Server was seen. This is due to
mSQL's lack of a join optimiser to order tables in the optimal
order. However, if you put the tables in exactly the right order in
mSQL2 and the WHERE is simple and uses index
columns, the join will be relatively fast! See section 5.1.4
The MySQL Benchmark Suite.
ORDER BY and GROUP BY.
DISTINCT.
TEXT or BLOB columns. GROUP BY and HAVING. mSQL does
not support GROUP BY at all. MySQL Server supports a full
GROUP BY with both HAVING and the following
functions: COUNT(), AVG(), MIN(),
MAX(), SUM(), and STD().
COUNT(*) is optimised to return very quickly if the
SELECT retrieves from one table, no other columns are
retrieved, and there is no WHERE clause. MIN() and
MAX() may take string arguments.
INSERT and UPDATE with calculations. MySQL
Server can do calculations in an INSERT or UPDATE.
For example: mysql> UPDATE SET x=x*10+y WHERE x<20;
SELECT with functions. MySQL Server has many functions (too
many to list here; see section 6.3
Functions for Use in SELECT and WHERE
Clauses). MEDIUMINT that is 3 bytes long. If
you have 100 million records, saving even 1 byte per record is very important.
mSQL2 has a more limited set of column types, so it is more
difficult to get small tables.
mSQL
stability, so we cannot say anything about that.
mSQL, and is also less expensive than
mSQL. Whichever product you choose to use, remember to at least
consider paying for a license or e-mail support.
mSQL with some added features.
mSQL has a
JDBC driver, but we have too little experience with it to compare.
GROUP
BY, and so on are still not implemented in mSQL, it has a
lot of catching up to do. To get some perspective on this, you can view the
mSQL `HISTORY' file for the last year and compare it
with the News section of the MySQL Reference Manual (see section D MySQL
Change History). It should be pretty obvious which one has developed most
rapidly.
mSQL and MySQL Server have many interesting third-party
tools. Because it is very easy to port upward (from mSQL to MySQL
Server), almost all the interesting applications that are available for
mSQL are also available for MySQL Server. MySQL Server comes with
a simple msql2mysql program that fixes differences in spelling
between mSQL and MySQL Server for the most-used C API functions.
For example, it changes instances of msqlConnect() to
mysql_connect(). Converting a client program from
mSQL to MySQL Server usually requires only minor effort. mSQL Tools for
MySQLAccording to our experience, it doesn't take long to convert tools such as
msql-tcl and msqljava that use the mSQL C
API so that they work with the MySQL C API.
The conversion procedure is:
msql2mysql on the source. This requires
the replace program, which is distributed with MySQL Server.
Differences between the mSQL C API and the MySQL C API are:
MYSQL structure as a connection type
(mSQL uses an int).
mysql_connect() takes a pointer to a MYSQL
structure as a parameter. It is easy to define one globally or to use
malloc() to get one. mysql_connect() also takes two
parameters for specifying the user and password. You may set these to
NULL, NULL for default use.
mysql_error() takes the MYSQL structure as a
parameter. Just add the parameter to your old msql_error() code
if you are porting old code.
mSQL returns only a text error message.
mSQL and MySQL Client/Server
Communications Protocols DifferThere are enough differences that it is impossible (or at least not easy) to support both.
The most significant ways in which the MySQL protocol differs from the
mSQL protocol are listed here:
mSQL 2.0 SQL Syntax Differs
from MySQLColumn types
MySQL Server
CREATE TABLE Syntax):
ENUM type for one of a set of strings.
SET type for many of a set of strings.
BIGINT type for 64-bit integers. UNSIGNED option for integer and floating-point columns.
ZEROFILL option for integer columns.
AUTO_INCREMENT option for integer columns that are a
PRIMARY KEY. See section 8.4.3.126
mysql_insert_id().
DEFAULT value for all columns. mSQL2
mSQL column types correspond to the MySQL types shown in the
following table:
mSQL type |
Corresponding MySQL type |
CHAR(len) |
CHAR(len) |
TEXT(len) |
TEXT(len). len is the maximal length. And
LIKE works. |
INT |
INT. With many more options! |
REAL |
REAL. Or FLOAT. Both 4- and 8-byte
versions are available. |
UINT |
INT UNSIGNED |
DATE |
DATE. Uses ANSI SQL format rather than
mSQL's own format. |
TIME |
TIME |
MONEY |
DECIMAL(12,2). A fixed-point value with two decimals.
|
Index Creation
MySQL Server
CREATE
TABLE statement.
mSQL
CREATE INDEX statements. To Insert a Unique Identifier into a Table
MySQL Server
AUTO_INCREMENT as a column type specifier. See section 8.4.3.126
mysql_insert_id().
mSQL
SEQUENCE on a table and select the _seq
column. To Obtain a Unique Identifier for a Row
MySQL Server
PRIMARY KEY or UNIQUE key to the table and
use this. New in Version 3.23.11: If the PRIMARY or
UNIQUE key consists of only one column and this is of type
integer, one can also refer to it as _rowid.
mSQL
_rowid column. Observe that _rowid may
change over time depending on many factors. To Get the Time a Column Was Last Modified
MySQL Server
TIMESTAMP column to the table. This column is
automatically set to the current date and time for INSERT or
UPDATE statements if you don't give the column a value or if you
give it a NULL value.
mSQL
_timestamp column. NULL Value Comparisons
MySQL Server
NULL is
always NULL.
mSQL
mSQL, NULL = NULL is TRUE. You must change
=NULL to IS NULL and <>NULL to
IS NOT NULL when porting old code from mSQL to MySQL
Server. String Comparisons
MySQL Server
BINARY attribute, which causes comparisons to be done according
to the ASCII order used on the MySQL server host.
mSQL
Case-insensitive Searching
MySQL Server
LIKE is a case-insensitive or case-sensitive operator,
depending on the columns involved. If possible, MySQL uses indexes if the
LIKE argument doesn't start with a wildcard character.
mSQL
CLIKE. Handling of Trailing Spaces
MySQL Server
CHAR and VARCHAR
columns. Use a TEXT column if this behavior is not desired.
mSQL
WHERE Clauses
MySQL Server
AND is evaluated
before OR). To get mSQL behavior in MySQL Server,
use parentheses (as shown in an example later in this section).
mSQL
mSQL query: mysql> SELECT * FROM table WHERE a=1 AND b=2 OR a=3 AND b=4;To make MySQL Server evaluate this the way that
mSQL would,
you must add parentheses: mysql> SELECT * FROM table WHERE (a=1 AND (b=2 OR (a=3 AND (b=4))));
Access Control
MySQL Server
mSQL
PostgreSQLWhen reading the following, please note that both products are continually evolving. We at MySQL AB and the PostgreSQL developers are both working on making our respective databases as good as possible, so we are both a serious alternative to any commercial database.
The following comparison is made by us at MySQL AB. We have tried to be as accurate and fair as possible, but although we know MySQL Server thoroughly, we don't have a full knowledge of all PostgreSQL features, so we may have got some things wrong. We will, however, correct these when they come to our attention.
We would first like to note that PostgreSQL and MySQL Server are both widely
used products, but with different design goals, even if we are both striving
toward ANSI SQL compliancy. This means that for some applications MySQL Server
is more suited, while for others PostgreSQL is more suited. When choosing which
database to use, you should first check if the database's feature set satisfies
your application. If you need raw speed, MySQL Server is probably your best
choice. If you need some of the extra features that only PostgreSQL can offer,
you should use PostgreSQL.
When adding things to MySQL Server we take pride to do an optimal, definite solution. The code should be so good that we shouldn't have any need to change it in the foreseeable future. We also do not like to sacrifice speed for features but instead will do our utmost to find a solution that will give maximal throughput. This means that development will take a little longer, but the end result will be well worth this. This kind of development is only possible because all server code are checked by one of a few (currently two) persons before it's included in the MySQL server.
We at MySQL AB believe in frequent releases to be able to push out new features quickly to our users. Because of this we do a new small release about every three weeks, and a major branch every year. All releases are thoroughly tested with our testing tools on a lot of different platforms.
PostgreSQL is based on a kernel with lots of contributors. In this setup it makes sense to prioritise adding a lot of new features, instead of implementing them optimally, because one can always optimise things later if there arises a need for this.
Another big difference between MySQL Server and PostgreSQL is that nearly all of the code in the MySQL server is coded by developers that are employed by MySQL AB and are still working on the server code. The exceptions are the transaction engines and the regexp library.
This is in sharp contrast to the PostgreSQL code, the majority of which is coded by a big group of people with different backgrounds. It was only recently that the PostgreSQL developers announced that their current developer group had finally had time to take a look at all the code in the current PostgreSQL release.
Both of the aforementioned development methods have their own merits and drawbacks. We here at MySQL AB think, of course, that our model is better because our model gives better code consistency, more optimal and reusable code, and in our opinion, fewer bugs. Because we are the authors of the MySQL server code, we are better able to coordinate new features and releases.
On the crash-me page (http://www.mysql.com/information/crash-me.php) you can find a list of those database constructs and limits that one can detect automatically with a program. Note, however, that a lot of the numerical limits may be changed with startup options for their respective databases. This web page is, however, extremely useful when you want to ensure that your applications work with many different databases or when you want to convert your application from one database to another.
MySQL Server offers the following advantages over PostgreSQL:
MySQL Server is generally much faster than PostgreSQL. MySQL
4.0.1 also has a query cache that can boost up the query speed for
mostly-read-only sites many times.
Cygwin emulation. We have heard that
PostgreSQL is not yet that stable on Windows but we haven't been able to
verify this ourselves.
VACUUM once in a while to
reclaim space from UPDATE and DELETE commands and to
perform statistics analyses that are critical to get good performance with
PostgreSQL. VACUUM is also needed after adding a lot of new rows
to a table. On a busy system with lots of changes, VACUUM must be
run very frequently, in the worst cases even many times a day. During the
VACUUM run, which may take hours if the database is big, the
database is, from a production standpoint, practically dead. Please note: in
PostgreSQL version 7.2, basic vacuuming no longer locks tables, thus allowing
normal user access during the vacuum. A new VACUUM FULL command
does old-style vacuum by locking the table and shrinking the on-disk copy of
the table.
PostgreSQL.
ALTER TABLE.
HEAP tables or disk based MyISAM. See section 7
MySQL Table Types.
InnoDB, and BerkeleyDB. Because every
transaction engine performs differently under different conditions, this gives
the application writer more options to find an optimal solution for his or her
setup, if need be per individual table. See section 7
MySQL Table Types.
MERGE tables gives you a unique way to instantly make a view
over a set of identical tables and use these as one. This is perfect for
systems where you have log files that you order, for example, by month. See
section 7.2
MERGE Tables.
myisampack, The MySQL Compressed Read-only Table Generator.
INSERT,
SELECT, and UPDATE/DELETE grants per user on a
database or a table, MySQL Server allows you to define a full set of different
privileges on the database, table, and column level. MySQL Server also allows
you to specify the privilege on host and user combinations. See section 4.3.1
GRANT and REVOKE Syntax.
InnoDB) are implemented as
files (one table per file), which makes it really easy to back up, move,
delete, and even symlink databases and tables, even when the server is down.
MyISAM tables (the most common
MySQL table type). A repair tool is only needed when a physical corruption of
a datafile happens, usually from a hardware failure. It allows a majority of
the data to be recovered.
Drawbacks with MySQL Server compared to PostgreSQL:
MyISAM
tables, is in many cases faster than page locks, row locks, or versioning. The
drawback, however, is that if one doesn't take into account how table locks
work, a single long-running query can block a table for updates for a long
time. This can usually be avoided when designing the application. If not, one
can always switch the trouble table to use one of the transactional table
types. See section 5.3.2
Table Locking Issues.
UPDATE and in MySQL Server 4.1 with subselects. In MySQL Server
4.0 one can use multi-table deletes to delete from many tables at the same
time. See section 6.4.6
DELETE Syntax. PostgreSQL currently offers the following advantages over MySQL Server:
Note that because we know the MySQL road map, we have included in the following table the version when MySQL Server should support this feature. Unfortunately we couldn't do this for previous comparisons, because we don't know the PostgreSQL roadmap.
| Feature | MySQL version |
| Subselects | 4.1 |
| Foreign keys | 4.1 |
| Views | 5.0 |
| Stored procedures | 5.0 |
| Triggers | 5.0 |
| Unions | 4.0 |
| Full join | 4.1 |
| Constraints | 4.1 or 5.0 |
| Cursors | 4.1 or 5.0 |
| R-trees | 4.1 (for MyISAM tables) |
| Inherited tables | Not planned |
| Extensible type system | Not planned |
Other reasons someone may consider using PostgreSQL:
Drawbacks with PostgreSQL compared to MySQL Server:
VACUUM makes PostgreSQL hard to use in a 24/7 environment.
INSERT, DELETE, and
UPDATE. For a complete list of drawbacks, you should also examine the first table in this section.
The only Open Source benchmark that we know of that can be used
to benchmark MySQL Server and PostgreSQL (and other databases) is our own. It
can be found at http://www.mysql.com/information/benchmarks.html.
We have many times asked the PostgreSQL developers and some PostgreSQL users to help us extend this benchmark to make it the definitive benchmark for databases, but unfortunately we haven't gotten any feedback for this.
We, the MySQL developers, have, because of this, spent a lot of hours to get maximum performance from PostgreSQL for the benchmarks, but because we don't know PostgreSQL intimately, we are sure that there are things that we have missed. We have on the benchmark page documented exactly how we did run the benchmark so that it should be easy for anyone to repeat and verify our results.
The benchmarks are usually run with and without the --fast
option. When run with --fast we are trying to use every trick the
server can do to get the code to execute as fast as possible. The idea is that
the normal run should show how the server would work in a default setup and the
--fast run shows how the server would do if the application
developer would use extensions in the server to make his application run faster.
When running with PostgreSQL and --fast we do a
VACUUM after every major table UPDATE and DROP
TABLE to make the database in perfect shape for the following
SELECTs. The time for VACUUM is measured separately.
When running with PostgreSQL 7.1.1 we could, however, not run with
--fast because during the INSERT test, the postmaster
(the PostgreSQL deamon) died and the database was so corrupted that it was
impossible to restart postmaster. After this happened twice, we decided to
postpone the --fast test until the next PostgreSQL release. The
details about the machine we run the benchmark on can be found on the benchmark
page.
Before going to the other benchmarks we know of, we would like to give some background on benchmarks.
It's very easy to write a test that shows any database to be the best database in the world, by just restricting the test to something the database is very good at and not testing anything that the database is not good at. If one, after doing this, summarises the result as a single figure, things are even easier.
This would be like us measuring the speed of MySQL Server compared to PostgreSQL by looking at the summary time of the MySQL benchmarks on our web page. Based on this MySQL Server would be more than 40 times faster than PostgreSQL, something that is, of course, not true. We could make things even worse by just taking the test where PostgreSQL performs worst and claim that MySQL Server is more than 2000 times faster than PostgreSQL.
The case is that MySQL does a lot of optimisations that PostgreSQL doesn't do. This is, of course, also true the other way around. An SQL optimiser is a very complex thing, and a company could spend years just making the optimiser faster and faster.
When looking at the benchmark results you should look for things that you do in your application and just use these results to decide which database would be best suited for your application. The benchmark results also show things a particular database is not good at and should give you a notion about things to avoid and what you may have to do in other ways.
We know of two benchmark tests that claim that PostgreSQL performs better than MySQL Server. These both where multi-user tests, a test that we here at MySQL AB haven't had time to write and include in the benchmark suite, mainly because it's a big task to do this in a manner that is fair to all databases.
One is the benchmark paid for by Great Bridge, the company that for 16 months attempted to build a business based on PostgreSQL but now has ceased operations. This is probably the worst benchmark we have ever seen anyone conduct. This was not only tuned to only test what PostgreSQL is absolutely best at, but it was also totally unfair to every other database involved in the test.
Note: We know that even some of the main PostgreSQL developers did not like the way Great Bridge conducted the benchmark, so we don't blame the PostgreSQL team for the way the benchmark was done.
This benchmark has been condemned in a lot of postings and newsgroups, so here we will just briefly repeat some things that were wrong with it.
Open Source company like us to verify the
benchmarks, or even check how the benchmarks were really done. The tool is not
even a true benchmark tool, but an application/setup testing tool. To refer to
this as a ``standard'' benchmark tool is to stretch the truth a long way.
VACUUM before the test) and tuned the startup for the
tests, something they hadn't done for any of the other databases involved.
They say ``This process optimises indexes and frees up disk space a bit. The
optimised indexes boost performance by some margin.'' Our benchmarks clearly
indicate that the difference in running a lot of selects on a database with
and without VACUUM can easily differ by a factor of 10.
SELECTs and JOINs (especially after a
VACUUM), but doesn't perform as well on INSERTs or
UPDATEs. The benchmarks seem to indicate that only
SELECTs were done (or very few updates). This could easily
explain the good results for PostgreSQL in this test. The bad results for
MySQL will be obvious a bit down in this document.
Tim Perdue, a long-time PostgreSQL fan and a reluctant MySQL user, published a comparison on PHPbuilder (http://www.phpbuilder.com/columns/tim20001112.php3).
When we became aware of the comparison, we phoned Tim Perdue about this because there were a lot of strange things in his results. For example, he claimed that MySQL Server had a problem with five users in his tests, when we know that there are users with similar machines as his that are using MySQL Server with 2000 simultaneous connections doing 400 queries per second. (In this case the limit was the web bandwidth, not the database.)
It sounded like he was using a Linux kernel that either had some problems with many threads, such as kernels before 2.4, which had a problem with many threads on multi-CPU machines. We have documented in this manual how to fix this and Tim should be aware of this problem.
The other possible problem could have been an old glibc library and that Tim didn't use a MySQL binary from our site, which is linked with a corrected glibc library, but had compiled a version of his own. In any of these cases, the symptom would have been exactly what Tim had measured.
We asked Tim if we could get access to his data so that we could repeat the benchmark and if he could check the MySQL version on the machine to find out what was wrong and he promised to come back to us about this. He has not done that yet.
Because of this we can't put any trust in this benchmark either. :(
Over time things also change and the preceding benchmarks are not that relevant anymore. MySQL Server now has a couple of different table handlers with different speed/concurrency tradeoffs. See section 7 MySQL Table Types. It would be interesting to see how the above tests would run with the different transactional table types in MySQL Server. PostgreSQL has, of course, also got new features since the test was made. As these tests are not publicly available there is no way for us to know how the database would perform in the same tests today.
Conclusion:
The only benchmarks that exist today that anyone can download and run against
MySQL Server and PostgreSQL are the MySQL benchmarks. We here at MySQL AB
believe that Open Source databases should be tested with Open
Source tools! This is the only way to ensure that no one does tests that
nobody can reproduce and use this to claim that one database is better than
another. Without knowing all the facts it's impossible to answer the claims of
the tester.
The thing we find strange is that every test we have seen about PostgreSQL, that is impossible to reproduce, claims that PostgreSQL is better in most cases while our tests, which anyone can reproduce, clearly show otherwise. With this we don't want to say that PostgreSQL isn't good at many things (it is!) or that it isn't faster than MySQL Server under certain conditions. We would just like to see a fair test where PostgreSQL performs very well, so that we could get some friendly competition going!
For more information about our benchmark suite, see section 5.1.4 The MySQL Benchmark Suite.
We are working on an even better benchmark suite, including multi-user tests, and a better documentation of what the individual tests really do and how to add more tests to the suite.
This chapter describes how to obtain and install MySQL:
The recommended way to install MySQL on Linux is by using an RPM file. The
MySQL RPMs are currently being built on a RedHat Version 6.2 system but should
work on other versions of Linux that support rpm and use
glibc.
If you have problems with an RPM file, for example, if you receive the error
``Sorry, the host 'xxxx' could not be looked up''@-see section 2.6.1.1
Linux Notes for Binary Distributions.
The RPM files you may want to use are:
MySQL-VERSION.i386.rpm The MySQL server. You will need this
unless you only want to connect to a MySQL server running on another machine.
MySQL-client-VERSION.i386.rpm The standard MySQL client
programs. You probably always want to install this package.
MySQL-bench-VERSION.i386.rpm Tests and benchmarks. Requires
Perl and msql-mysql-modules RPMs.
MySQL-devel-VERSION.i386.rpm Libraries and include files
needed if you want to compile other MySQL clients, such as the Perl modules.
MySQL-VERSION.src.rpm This contains the source code for all
of the previous packages. It can also be used to try to build RPMs for other
architectures (for example, Alpha or SPARC). To see all files in an RPM package, run:
shell> rpm -qpl MySQL-VERSION.i386.rpm
To perform a standard minimal installation, run:
shell> rpm -i MySQL-VERSION.i386.rpm MySQL-client-VERSION.i386.rpm
To install just the client package, run:
shell> rpm -i MySQL-client-VERSION.i386.rpm
The RPM places data in `/var/lib/mysql'. The RPM also creates the appropriate entries in `/etc/rc.d/' to start the server automatically at boot time. (This means that if you have performed a previous installation, you may want to make a copy of your previously installed MySQL startup file if you made any changes to it, so you don't lose your changes.)
After installing the RPM file(s), the mysqld daemon should be
running and you should now be able to start using MySQL. See section 2.4
Post-installation Setup and Testing.
If something goes wrong, you can find more information in the binary installation chapter. See section 2.2.7 Installing a MySQL Binary Distribution.
The MySQL server for Windows is available in two distribution types:
Generally speaking, you should use the binary distribution.
You will need the following:
MAX_ROWS and AVG_ROW_LENGTH when you create
the table. See section 6.5.3
CREATE TABLE Syntax.
ZIP program to unpack the distribution file.
ODBC, you will
also need the MyODBC driver. See section 8.3
MySQL ODBC Support. C:\> NET STOP MySQLOtherwise, use:
C:\mysql\bin> mysqladmin -u root shutdown
C:\mysql\bin> mysqld-max-nt --remove
Browse button to specify your
preferred directory.
Starting with MySQL 3.23.38, the Windows distribution includes both the normal and the MySQL-Max server binaries. Here is a list of the different MySQL servers you can use:
| Binary | Description |
mysqld |
Compiled with full debugging and automatic memory allocation checking, symbolic links, InnoDB, and BDB tables. |
mysqld-opt |
Optimised binary with no support for transactional tables. |
mysqld-nt |
Optimised binary for NT/2000/XP with support for named pipes. You can run this version on Windows 9x/Me, but in this case no named pipes are created and you must have TCP/IP installed. |
mysqld-max |
Optimised binary with support for symbolic links, InnoDB and BDB tables. |
mysqld-max-nt |
Like mysqld-max, but compiled with support for named
pipes. |
Starting from 3.23.50, named pipes are only enabled if one starts mysqld with
--enable-named-pipe.
All of the preceding binaries are optimised for the Pentium Pro processor but should work on any Intel processor >= i386.
You will need to use an option file to specify your MySQL configuration under the following circumstances:
Normally you can use the WinMySQLAdmin tool to edit the option
file my.ini. In this case you don't have to worry about the
following section.
There are two option files with the same function: `my.cnf' and
`my.ini'. However, to avoid confusion, it's best if you use only of one
them. Both files are plain text. The `my.cnf' file, if used, should be
created in the root directory of the C drive. The `my.ini' file, if
used, should be created in the Windows system directory. (This directory is
typically something like `C:\WINDOWS' or `C:\WINNT'. You can
determine its exact location from the value of the windir
environment variable.) MySQL looks first for the my.ini file, then
for the `my.cnf' file.
If your PC uses a boot loader where the C drive isn't the boot drive, your
only option is to use the `my.ini' file. Also note that if you use the
WinMySQLAdmin tool, it uses only the `my.ini' file. The
`\mysql\bin' directory contains a help file with instructions for using
this tool.
Using notepad.exe, create the option file and edit the
[mysqld] section to specify values for the basedir and
datadir parameters:
[mysqld] # set basedir to installation path, e.g., c:/mysql basedir=the_install_path # set datadir to location of data directory, # e.g., c:/mysql/data or d:/mydata/data datadir=the_data_path
Note that Windows pathnames should be specified in option files using forward slashes rather than backslashes. If you do use backslashes, you must double them.
If you would like to use a data directory different from the default of `c:\mysql\data', you must copy the entire contents of the `c:\mysql\data' directory to the new location.
If you want to use the InnoDB transactional tables, you need to
manually create two new directories to hold the InnoDB data and log files@-e.g.,
`c:\ibdata' and `c:\iblogs'. You will also need to add some
extra lines to the option file. See section 7.5.2
InnoDB Startup Options.
If you don't want to use InnoDB tables, add the
skip-innodb option to the option file.
Now you are ready to test starting the server.
Testing from a DOS command prompt is the best thing to do because the server displays status messages that appear in the DOS window. If something is wrong with your configuration, these messages will make it easier for you to identify and fix any problems.
Make sure you are in the directory where the server is located, then enter this command:
C:\mysql\bin> mysqld-max --standalone
You should see the following messages as the server starts up:
InnoDB: The first specified datafile c:\ibdata\ibdata1 did not exist: InnoDB: a new database to be created! InnoDB: Setting file c:\ibdata\ibdata1 size to 209715200 InnoDB: Database physically writes the file full: wait... InnoDB: Log file c:\iblogs\ib_logfile0 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile0 size to 31457280 InnoDB: Log file c:\iblogs\ib_logfile1 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile1 size to 31457280 InnoDB: Log file c:\iblogs\ib_logfile2 did not exist: new to be created InnoDB: Setting log file c:\iblogs\ib_logfile2 size to 31457280 InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: creating foreign key constraint system tables InnoDB: foreign key constraint system tables created 011024 10:58:25 InnoDB: Started
For further information about running MySQL on Windows, see section 2.6.2 Windows Notes.
Check the MySQL homepage (http://www.mysql.com/) for information about the current version and for downloading instructions.
Our main download mirror is located at:
http://mirrors.sunsite.dk/mysql/
If you are interested in becoming a MySQL mirror site, you may anonymously
rsync with: rsync://sunsite.dk/ftp/mirrors/mysql/. Please send
e-mail to webmaster@mysql.com notifying
us of your mirror to be added to the following list.
If you have problems downloading from our main site, try using one of the following mirrors.
Please report bad or out-of-date mirrors to webmaster@mysql.com.
Europe:
Armenia
[AbideWeb Technologies] @ WWW (http://mysql.abideweb.com/) FTP (ftp://mysql.abideweb.com/mirrors/MySQL/)
Austria
[Univ. of Technology/Vienna] @ WWW (http://gd.tuwien.ac.at/db/mysql/)
FTP (ftp://gd.tuwien.ac.at/db/mysql/)
Belgium
[BELNET] @ WWW (http://mysql.belnet.be/)
FTP (ftp://ftp.belnet.be/mirror/ftp.mysql.com/pub/mysql/)
Bulgaria
[online.bg/Sofia] @ WWW (http://mysql.online.bg/) FTP (ftp://mysql.online.bg/)
Czech Republic [Masaryk University in Brno] @ WWW (http://mysql.linux.cz/) FTP (ftp://ftp.fi.muni.cz/pub/mysql/)
Czech Republic [www.gin.cz] @ WWW (http://mysql.gin.cz/) FTP (ftp://ftp.gin.cz/pub/MIRRORS/www.mysql.com/)
Czech Republic [www.sopik.cz] @ WWW (http://www.mysql.cz/)
Denmark
[Borsen] @ WWW (http://mysql.borsen.dk/)
Denmark
[SunSITE] @ WWW (http://mirrors.sunsite.dk/mysql/)
FTP (ftp://sunsite.dk/mirrors/mysql/)
Estonia
[OK Interactive] @ WWW (http://mysql.mirror.ok.ee/)
Finland
[KPNQwest] @ WWW (http://mysql.kpnqwest.fi/)
Finland
[tonnikala.net] @ WWW (http://mysql.tonnikala.org/)
France
[free.fr] @ WWW (http://mysql-mirror.free.fr/) FTP (ftp://ftp.free.fr/pub/MySQL/)
France
[mir2.ovh.net/] @ WWW (http://mir2.ovh.net/ftp.mysql.com/)
FTP (ftp://mir1.ovh.net/ftp.mysql.com/)
France
[Netsample] @ WWW (http://www.mysql.netsample.com/)
France
[Universite Paris 10] @ WWW (http://ftp.u-paris10.fr/mysql.com)
FTP (ftp://ftp.u-paris10.fr/mysql.com)
Germany
[GWDG] @ WWW (http://ftp.gwdg.de/pub/misc/mysql/)
FTP (ftp://ftp.gwdg.de/pub/misc/mysql/)
Germany
[SunSITE Central Europe] @ WWW (http://sunsite.informatik.rwth-aachen.de/mysql/)
FTP (ftp://sunsite.informatik.rwth-aachen.de/pub/mirror/www.mysql.com/)
Germany
[Tiscali] @ WWW (http://filepile.tiscali.de/mirror/mysql/)
FTP (ftp://filepile.tiscali.de/mirror/mysql/)
Germany
[Wolfenbuettel] @ WWW (http://www.fh-wolfenbuettel.de/ftp/pub/database/mysql/)
FTP (ftp://ftp.fh-wolfenbuettel.de/pub/database/mysql/)
Greece
[NTUA, Athens] @ WWW (http://www.ntua.gr/mysql/) FTP (ftp://ftp.ntua.gr/pub/databases/mysql/)
Hungary
[stop.hu] @ WWW (http://mysql.mirror.stop.hu/)
Hungary
[TiszaneT] @ WWW (http://mysql.tiszanet.hu/) FTP (ftp://mysql.tiszanet.hu/pub/mirrors/mysql/)
Hungary
[Xenia] @ WWW (http://mysql.sote.hu/) FTP
(ftp://xenia.sote.hu/pub/mirrors/www.mysql.com/)
Iceland
[Tvíund] @ WWW (http://mysql.tviund.is/)
Ireland
[Esat Net] @ WWW (http://ftp.esat.net/mirrors/download.sourceforge.net/pub/mirrors/mysql/)
FTP (ftp://ftp.esat.net/mirrors/download.sourceforge.net/pub/mirrors/mysql/)
Ireland
[MD NMTB Media] @ WWW (http://mirrors.nmtbmedia.com/mysql/)
Israel
[fresh.co.il] @ WWW (http://mysql.fresh.co.il/)
Italy
[feelinglinux.com] @ WWW (http://mysql.feelinglinux.com/)
Italy [Teta
Srl] @ WWW (http://www.teta.it/mysql/)
Italy
[tzone.it] @ WWW (http://mysql.tzone.it/)
Latvia
[linux.lv] @ FTP (ftp://ftp.linux.lv/pub/software/mysql/)
Netherlands [OMS-Net] @ WWW (http://mysql.oms-net.nl/)
Netherlands [ProServe] @ WWW (http://mysql.proserve.nl/)
Netherlands [WideXS BV] @ WWW (http://mysql.mirror.widexs.nl/) FTP
(ftp://mirror.widexs.nl/pub/mysql/)
Norway
[Brainpeddlers AS] @ WWW (http://mysql.brainpeddlers.com/)
Poland
[ncservice.com/Gdansk] @ WWW (http://mysql.service.net.pl/)
Poland
[SunSITE] @ WWW (http://sunsite.icm.edu.pl/mysql/)
FTP (ftp://sunsite.icm.edu.pl/pub/unix/mysql/)
Portugal
[Instituto Supertior Técnico] @ WWW (http://darkstar.ist.utl.pt/mysql/)
FTP (ftp://darkstar.ist.utl.pt/pub/mysql/)
Portugal
[Netvisão] @ WWW (http://mysql.netvisao.pt/) FTP (ftp://mirrors2.netvisao.pt/pub/mysql/)
Portugal
[VIZZAVI] @ WWW (http://ftp.vizzavi.pt/pub/mysql/)
FTP (ftp://ftp.vizzavi.pt/pub/mysql/)
Romania
[roedu.net/Bucharest] @ FTP (ftp://ftp.roedu.net/pub/mirrors/ftp.mysql.com/)
Russia
[DirectNet] @ WWW (http://mysql.directnet.ru/) FTP (ftp://ftp.dn.ru/pub/MySQL/)
Russia
[Scientific Center/Chernogolovka] @ FTP (ftp://ftp.chg.ru/pub/databases/mysql/)
Slovenia
[ARNES] @ WWW (http://ftp.arnes.si/mysql/) FTP (ftp://ftp.arnes.si/packages/mysql/)
Sweden
[Sunet] @ WWW (http://ftp.sunet.se/pub/unix/databases/relational/mysql/)
FTP (ftp://ftp.sunet.se/pub/unix/databases/relational/mysql/)
Switzerland [SunSITE] @ WWW (http://sunsite.cnlab-switch.ch/ftp/mirror/mysql/)
FTP (ftp://sunsite.cnlab-switch.ch/mirror/mysql/)
Turkey
[proGEN] @ WWW (http://mysql.progen.com.tr/)
UK
[PLiG/UK] @ WWW (http://ftp.plig.org/pub/mysql/) FTP
(ftp://ftp.plig.org/pub/mysql/)
Ukraine
[ISP Alkar Teleport/Dnepropetrovsk] @ WWW (http://mysql.dp.ua/) FTP (ftp://ftp.tlk-l.net/pub/mirrors/mysql.com/)
Ukraine
[PACO] @ WWW (http://mysql.paco.net.ua/) FTP (ftp://mysql.paco.net.ua/)
Yugoslavia [Open Source Network of Yugoslavia] @ WWW (http://mysql.boa.org.yu/) FTP (ftp://ftp.linux.org.yu/pub/MySQL/)
North America:
Canada
[Tryc] @ WWW (http://web.tryc.on.ca/mysql/)
Mexico
[UAM] @ WWW (http://mysql.azc.uam.mx/)
FTP (ftp://mysql.azc.uam.mx/mirrors/mysql/)
Mexico
[UNAM] @ WWW (http://mysql.unam.mx/) FTP
(ftp://mysql.unam.mx/pub/mysql/)
USA
[adgrafix.com / Boston, MA] @ WWW (http://mysql.adgrafix.com/)
USA [Hurricane
Electric / San Jose, CA] @ WWW (http://mysql.he.net/)
USA [netNumina
/ Cambridge, MA] @ WWW (http://mysql.mirrors.netnumina.com/)
USA [NIXC /
Vienna, VA] @ WWW (http://mysql.nixc.net/) FTP (ftp://mysql.nixc.net/pub/mysql/)
USA [Oregon
State University / Corvallis, OR] @ WWW (http://mysql.orst.edu/) FTP (ftp://ftp.orst.edu/pub/mysql/)
USA
[University of Wisconsin / Wisconsin] @ WWW (http://mirror.sit.wisc.edu/mysql/)
FTP (ftp://mirror.sit.wisc.edu/mirrors/mysql/)
USA [UUNet] @
WWW (http://mysql.secsup.org/) FTP (ftp://mysql.secsup.org/pub/software/mysql/)
South America:
Argentina [bannerlandia.com] @ WWW (http://mysql.bannerlandia.com.ar/)
FTP (ftp://mysql.bannerlandia.com.ar/mirrors/mysql/)
Chile
[PSINet] @ WWW (http://mysql.psinet.cl/)
FTP (ftp://ftp.psinet.cl/pub/database/mysql/)
Chile
[Tecnoera] @ WWW (http://mysql.tecnoera.com/)
Chile
[Vision] @ WWW (http://mysql.vision.cl/)
Costa
Rica [Ogmios Communications] @ WWW (http://mysql.ogmios.co.cr/) FTP (ftp://mysql.ogmios.co.cr/pub/mysql/)
Asia:
China
[HKLPG/Hong Kong] @ WWW (http://mysql.hklpg.org/)
China
[linuxforum.net] @ FTP (http://www2.linuxforum.net/mirror/mysql/)
China
[shellhung.org/Hong Kong] @ WWW (http://mysql.shellhung.org/) FTP (ftp://ftp.shellhung.org/pub/Mirror/mysql/)
Indonesia [CBN] @ WWW (http://mysql.cbn.net.id/)
Indonesia [incaf.net] @ WWW (http://mysql.incaf.net/) FTP (ftp://mysql.incaf.net/)
Indonesia [M-Web] @ WWW (http://mysql.mweb.net.id/) FTP (ftp://mysql.mweb.net.id/pub/database/mysql/)
Indonesia [web.id] @ WWW (http://mysql.itb.web.id/) FTP (ftp://mysql.itb.web.id/pub/MySQL/)
Japan [Soft
Agency] @ WWW (http://www.softagency.co.jp/MySQL/)
Japan
[u-aizu.ac.jp/Aizu] @ FTP (ftp://ftp.u-aizu.ac.jp/ftp/pub/dbms/mysql/mysql.com/)
Philippines [Ateneo de Zamboanga University] @ WWW (http://mysql.adzu.edu.ph/)
Singapore [HJC] @ WWW (http://mysql.hjc.edu.sg/) FTP (ftp://ftp.hjc.edu.sg/mysql/)
South
Korea [HolyNet] @ WWW (http://mysql.holywar.net/)
South
Korea [Webiiz] @ WWW (http://mysql.webiiz.com/)
Taiwan
[nctu.edu/HsinChu] @ WWW (http://mysql.nctu.edu.tw/)
Taiwan
[TTN] @ WWW (http://mysql.ttn.net/)
Australia:
Australia [planetmirror.com] @ WWW (http://mysql.planetmirror.com/) FTP
(ftp://planetmirror.com/pub/mysql/)
New
Zealand [Cubalan] @ WWW (http://mysql.soa.co.nz/) Africa:
South
African Republic [Mweb] @ WWW (http://www.mysql.mweb.co.za/)
South
African Republic [The Internet Solution/Johannesburg] @ FTP (ftp://ftp.is.co.za/linux/mysql/)
We use GNU Autoconf, so it is possible to port MySQL to all modern systems with working Posix threads and a C++ compiler. (To compile only the client code, a C++ compiler is required but not threads.) We use and develop the software ourselves primarily on Sun Solaris (Versions 2.5 - 2.7) and SuSE Linux Version 7.x.
Note that for many operating systems, the native thread support works only in the latest versions. MySQL has been reported to compile successfully on the following operating system/thread package combinations:
glibc 2.0.7+. See
section 2.6.1
Linux Notes (All Linux Versions).
Note that not all platforms are suited equally well for running MySQL. How well a certain platform is suited for a high-load mission-critical MySQL server is determined by the following factors:
pthread_mutex_lock() is too anxious to yield CPU time, this will
hurt MySQL tremendously. If this issue is not taken care of, adding extra CPUs
will actually make MySQL slower.
Based on the preceding criteria, the best platforms for running MySQL at this point are x86 with SuSE Linux 7.1, 2.4 kernel, and ReiserFS (or any similar Linux distribution) and SPARC with Solaris 2.7 or 2.8. FreeBSD comes third, but we really hope it will join the top club once the thread library is improved. We also hope that at some point we will be able to include all other platforms on which MySQL compiles, runs okay, but not quite with the same level of stability and performance, into the top category. This will require some effort on our part in cooperation with the developers of the OS/library components MySQL depends upon. If you are interested in making one of those components better, are in a position to influence their development, and need more detailed instructions on what MySQL needs to run better, send an e-mail to internals@lists.mysql.com.
Please note that the preceding comparison is not to say that one OS is better or worse than the other in general. We are talking about choosing a particular OS for a dedicated purpose@-running MySQL, and compare platforms in that regard only. With this in mind, the result of this comparison would be different if we included more issues into it. And in some cases, the reason one OS is better than the other could simply be that we have put forth more effort into testing on and optimising for that particular platform. We are just stating our observations to help you decide on which platform to use MySQL on in your setup.
The first decision to make is whether you want to use the latest development release or the last stable release:
The second decision to make is whether you want to use a source distribution or a binary distribution. In most cases you should probably use a binary distribution, if one exists for your platform, as this generally will be easier to install than a source distribution.
In the following cases you probably will be better off with a source installation:
MySQL clients can
connect to both MySQL versions. The extended MySQL binary distribution is
marked with the -max suffix and is configured with the same
options as mysqld-max. See section 4.7.5
mysqld-max, An Extended mysqld Server. If you
want to use the MySQL-Max RPM, you must first install the
standard MySQL RPM.
mysqld with some extra features that
are not in the standard binary distributions. Here is a list of the most
common extra options that you may want to use:
--with-innodb
--with-berkeley-db
--with-raid
--with-libwrap
--with-named-z-lib (This is done for some of the binaries)
--with-debug[=full] pgcc), or use compiler options that are better optimised
for your processor.
The MySQL naming scheme uses release numbers that consist of three numbers
and a suffix. For example, a release name like mysql-3.21.17-beta
is interpreted like this:
3) describes the file format. All Version 3
releases have the same file format.
21) is the release level. Normally there
are two to choose from. One is the release/stable branch (currently
23) and the other is the development branch (currently
4.0). Normally both are stable, but the development version may
have quirks, may be missing documentation on new features, or may fail to
compile on some systems.
17) is the version number within the
release level. This is incremented for each new distribution. Usually you want
the latest version for the release level you have chosen.
beta) indicates the stability level of the
release. The possible suffixes are:
alpha indicates that the release contains some large
section of new code that hasn't been 100% tested. Known bugs (usually there
are none) should be documented in the News section. See section D
MySQL Change History. There are also new commands and extensions in most
alpha releases. Active development that may involve major code changes can
occur on an alpha release, but everything will be tested before doing a
release. There should be no known bugs in any MySQL release.
beta means that all new code has been tested. No major new
features that could cause corruption on old code are added. There should be
no known bugs. A version changes from alpha to beta when there haven't been
any reported fatal bugs within an alpha version for at least a month and we
don't plan to add any features that could make any old command more
unreliable.
gamma is a beta that has been around a while and seems to
work fine. Only minor fixes are added. This is what many other companies
call a release.
All versions of MySQL are run through our standard tests and benchmarks to ensure that they are relatively safe to use. Because the standard tests are extended over time to check for all previously found bugs, the test suite keeps getting better.
Note that all releases have been tested at least with:
crash-me test
Another test is that we use the newest MySQL version in our internal production environment, on at least one machine. We have more than 100 gigabytes of data to work with.
This section describes the default layout of the directories created by installing binary and source distributions.
A binary distribution is installed by unpacking it at the installation location you choose (typically `/usr/local/mysql') and creates the following directories in that location:
| Directory | Contents of directory |
| `bin' | Client programs and the mysqld server |
| `data' | Log files, databases |
| `include' | Include (header) files |
| `lib' | Libraries |
| `scripts' | mysql_install_db |
| `share/mysql' | Error message files |
| `sql-bench' | Benchmarks |
A source distribution is installed after you configure and compile it. By default, the installation step installs files under `/usr/local', in the following subdirectories:
| Directory | Contents of directory |
| `bin' | Client programs and scripts |
| `include/mysql' | Include (header) files |
| `info' | Documentation in Info format |
| `lib/mysql' | Libraries |
| `libexec' | The mysqld server |
| `share/mysql' | Error message files |
| `sql-bench' | Benchmarks and crash-me test |
| `var' | Databases and log files |
Within an installation directory, the layout of a source installation differs from that of a binary installation in the following ways:
mysqld server is installed in the `libexec'
directory rather than in the `bin' directory.
mysql_install_db is installed in the
`/usr/local/bin' directory rather than in
`/usr/local/mysql/scripts'.
You can create your own binary installation from a compiled source distribution by executing the script `scripts/make_binary_distribution'.
MySQL is evolving quite rapidly here at MySQL AB and we want to share this with other MySQL users. We try to make a release when we have very useful features that others seem to have a need for.
We also try to help out users who request features that are easy to implement. We take note of what our licensed users want to have, and we especially take note of what our extended e-mail supported customers want and try to help them out.
No one has to download a new release. The News section will tell you if the new release has something you really want. See section D MySQL Change History.
We use the following policy when updating MySQL:
The current stable release is Version 3.23; we have already moved active development to Version 4.0. Bugs will still be fixed in the stable version. We don't believe in a complete freeze, as this also leaves out bug fixes and things that ``must be done.'' ``Somewhat frozen'' means that we may add small things that ``almost surely will not affect anything that's already working.''
MySQL uses a slightly different naming scheme from most other products. In general it's relatively safe to use any version that has been out for a couple of weeks without being replaced with a new version. See section 2.2.3 Which MySQL Version to Use.
As a service, we at MySQL AB provide a set of binary distributions of MySQL that are compiled at our site or at sites where customers kindly have given us access to their machines.
These distributions are generated with
scripts/make_binary_distribution and are configured with the
following compilers and options:
gcc 2.7.2.1
CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors" ./configure
--prefix=/usr/local/mysql --disable-shared --with-extra-charsets=complex
--enable-assembler
egcs 1.0.3a or 2.90.27 or
gcc 2.95.2 and newer
CC=gcc CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors
-fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql
--with-low-memory --with-extra-charsets=complex --enable-assembler
gcc 2.8.1
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
--with-low-memory --with-extra-charsets=complex
gcc 2.95.3
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3
-fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql "--with-comment=Official MySQL binary"
--with-extra-charsets=complex "--with-server-suffix="
--enable-thread-safe-client --enable-local-infile --enable-assembler
--disable-shared
pgcc 2.90.29 (egcs
1.0.3a)
CFLAGS="-O3 -mpentium -mstack-align-double" CXX=gcc CXXFLAGS="-O3
-mpentium -mstack-align-double -felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql --enable-assembler
--with-mysqld-ldflags=-all-static --with-extra-charsets=complex
gcc 2.95.2
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro
-felide-constructors -fno-exceptions -fno-rtti" ./configure
--prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static
--disable-shared --with-extra-charset=complex
gcc 2.7-95q4
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex
gcc 2.7.2.2
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex
gcc 2.8.1
CC=gcc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex
gcc 2.8.0
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex
gcc 2.7.2.1
CC=gcc CXX=gcc CXXFLAGS=-O ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex
gcc 2.7.2
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex
gcc 2.95.3
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3
-fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti"
./configure --prefix=/usr/local/mysql "--with-comment=Official MySQL binary"
--with-extra-charsets=complex "--with-server-suffix="
--enable-thread-safe-client --enable-local-infile --enable-assembler
--with-named-z-libs=not-used --disable-shared Anyone who has more optimal options for any of the preceding configurations listed can always mail them to the developer's mailing list at internals@lists.mysql.com.
RPM distributions prior to MySQL Version 3.22 are user-contributed. Beginning with Version 3.22, the RPMs are generated by us at MySQL AB.
If you want to compile a debug version of MySQL, you should add
--with-debug or --with-debug=full to the preceding
configure lines and remove any -fomit-frame-pointer options.
For the Windows distribution, please see section 2.1.2 Installing MySQL on Windows.
See also section 2.1.2.1 Installing the Binaries, section 2.1.1 Installing MySQL on Linux, and section 8.4.7 Building Client Programs.
You need the following tools to install a MySQL binary distribution:
gunzip to uncompress the distribution.
tar to unpack the distribution. GNU
tar is known to work. Sun tar is known to have
problems. An alternative installation method under Linux is to use RPM (RedHat Package Manager) distributions. See section 2.1.1 Installing MySQL on Linux.
If you run into problems, please always use
mysqlbug when posting questions to mysql@lists.mysql.com. Even if the
problem isn't a bug, mysqlbug gathers system information that will
help others solve your problem. By not using mysqlbug, you lessen
the likelihood of getting a solution to your problem! You will find
mysqlbug in the `bin' directory after you unpack the
distribution. See section 1.6.2.3
How to Report Bugs or Problems.
The basic commands you must execute to install and use a MySQL binary distribution are:
shell> groupadd mysql shell> useradd -g mysql mysql shell> cd /usr/local shell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf - shell> ln -s full-path-to-mysql-VERSION-OS mysql shell> cd mysql shell> scripts/mysql_install_db shell> chown -R root . shell> chown -R mysql data shell> chgrp -R mysql . shell> bin/safe_mysqld --user=mysql & or shell> bin/mysqld_safe --user=mysql & if you are running MySQL 4.x
You can add new users using the bin/mysql_setpermission script
if you install the DBI and Msql-Mysql-modules Perl
modules.
A more detailed description follows.
To install a binary distribution, follow these steps, then proceed to section 2.4 Post-installation Setup and Testing, for post-installation setup and testing:
root.)
tar archives and have names like
`mysql-VERSION-OS.tar.gz', where VERSION is a number
(for example, 3.21.15), and OS indicates the type of
operating system for which the distribution is intended (for example,
pc-linux-gnu-i586).
-max prefix,
this means that the binary has support for transaction-safe tables and other
features. See section 4.7.5
mysqld-max, An Extended mysqld Server. Note that
all binaries are built from the same MySQL source distribution.
mysqld to run as: shell> groupadd mysql shell> useradd -g mysql mysqlThese commands add the
mysql group and the
mysql user. The syntax for useradd and
groupadd may differ slightly on different versions of Unix. They
may also be called adduser and addgroup. You may
wish to call the user and group something else instead of mysql.
shell> cd /usr/local
shell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf - shell> ln -s full-path-to-mysql-VERSION-OS mysqlThe first command creates a directory named `mysql-VERSION-OS'. The second command makes a symbolic link to that directory. This lets you refer more easily to the installation directory as `/usr/local/mysql'.
shell> cd mysqlYou will find several files and subdirectories in the
mysql
directory. The most important for installation purposes are the `bin'
and `scripts' subdirectories.
PATH environment variable so that your shell finds the
MySQL programs properly. See section F
Environment Variables.
mysql_install_db script used to
initialise the mysql database containing the grant tables that
store the server access permissions. mysqlaccess and have the MySQL
distribution in some non-standard place, you must change the location where
mysqlaccess expects to find the mysql client. Edit
the `bin/mysqlaccess' script at approximately line 18. Search for a
line that looks like this: $MYSQL = '/usr/local/bin/mysql'; # path to mysql executableChange the path to reflect the location where
mysql
actually is stored on your system. If you do not do this, you will get a
Broken pipe error when you run mysqlaccess.
shell> scripts/mysql_install_dbNote that MySQL versions older than Version 3.22.10 started the MySQL server when you run
mysql_install_db. This is no longer true!
root and ownership of the
data directory to the user that you will run mysqld as: shell> chown -R root /usr/local/mysql/. shell> chown -R mysql /usr/local/mysql/data shell> chgrp -R mysql /usr/local/mysql/.The first command changes the
owner attribute of the files
to the root user, the second one changes the owner
attribute of the data directory to the mysql user, and the third
one changes the group attribute to the mysql group.
DBI/DBD interface, see section 2.7
Perl Installation Comments.
support-files/mysql.server to the location where
your system has its startup files. More information can be found in the
support-files/mysql.server script itself and in section 2.4.3
Starting and Stopping MySQL Automatically. After everything has been unpacked and installed, you should initialise and test your distribution.
You can start the MySQL server with the following command:
shell> bin/safe_mysqld --user=mysql &
Now proceed to section 4.7.2
safe_mysqld, The Wrapper Around mysqld, and See
section 2.4
Post-installation Setup and Testing.
Before you proceed with the source installation, check first to see if our binary is available for your platform and if it will work for you. We put a lot of effort into making sure that our binaries are built with the best possible options.
You need the following tools to build and install MySQL from source:
gunzip to uncompress the distribution.
tar to unpack the distribution. GNU
tar is known to work. Sun tar is known to have
problems.
gcc >= 2.95.2,
egcs >= 1.0.2 or egcs 2.91.66, SGI C++, and
SunPro C++ are some of the compilers that are known to work.
libg++ is not needed when using gcc.
gcc 2.7.x has a bug that makes it impossible to compile some
perfectly legal C++ files, such as `sql/sql_base.cc'. If you only
have gcc 2.7.x, you must upgrade your gcc to be able
to compile MySQL. gcc 2.8.1 is also known to have problems on
some platforms, so it should be avoided if a new compiler exists for the
platform. gcc >= 2.95.2 is recommended when compiling MySQL
Version 3.23.x.
make program. GNU make is always
recommended and is sometimes required. If you have problems, we recommend
trying GNU make 3.75 or newer. If you are using a recent version of gcc, recent enough to
understand the -fno-exceptions option, it is very
important that you use it. Otherwise, you may compile a binary that
crashes randomly. We also recommend that you use
-felide-constructors and -fno-rtti along with
-fno-exceptions. When in doubt, do the following:
CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions \
-fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler \
--with-mysqld-ldflags=-all-static
On most systems this will give you a fast and stable binary.
If you run into problems, please always use
mysqlbug when posting questions to mysql@lists.mysql.com. Even if the
problem isn't a bug, mysqlbug gathers system information that will
help others solve your problem. By not using mysqlbug, you lessen
the likelihood of getting a solution to your problem! You will find
mysqlbug in the `scripts' directory after you unpack the
distribution. See section 1.6.2.3
How to Report Bugs or Problems.
The basic commands you must execute to install a MySQL source distribution are:
shell> groupadd mysql shell> useradd -g mysql mysql shell> gunzip < mysql-VERSION.tar.gz | tar -xvf - shell> cd mysql-VERSION shell> ./configure --prefix=/usr/local/mysql shell> make shell> make install shell> scripts/mysql_install_db shell> chown -R root /usr/local/mysql shell> chown -R mysql /usr/local/mysql/var shell> chgrp -R mysql /usr/local/mysql shell> cp support-files/my-medium.cnf /etc/my.cnf shell> /usr/local/mysql/bin/safe_mysqld --user=mysql & or shell> /usr/local/mysql/bin/mysqld_safe --user=mysql & if you are running MySQL 4.x.
If you want to have support for InnoDB tables, you should edit the
/etc/my.cnf file and remove the # character before the
parameter that starts with innodb_.... See section 4.1.2
`my.cnf' Option Files, and section 7.5.2
InnoDB Startup Options.
If you start from a source RPM, do the following:
shell> rpm --rebuild MySQL-VERSION.src.rpm
This will make a binary RPM that you can install.
You can add new users using the bin/mysql_setpermission script
if you install the DBI and Msql-Mysql-modules Perl
modules.
A more detailed description follows.
To install a source distribution, follow these steps, then proceed to section 2.4 Post-installation Setup and Testing, for post-installation initialisation and testing:
tar archives and have names like
`mysql-VERSION.tar.gz', where VERSION is a number like
4.0.2-alpha.
mysqld to run as: shell> groupadd mysql shell> useradd -g mysql mysqlThese commands add the
mysql group and the
mysql user. The syntax for useradd and
groupadd may differ slightly on different versions of Unix. They
may also be called adduser and addgroup. You may
wish to call the user and group something else instead of mysql.
shell> gunzip < /path/to/mysql-VERSION.tar.gz | tar xvf -This command creates a directory named `mysql-VERSION'.
shell> cd mysql-VERSIONNote that currently you must configure and build MySQL from this top-level directory. You cannot build it in a different directory.
shell> ./configure --prefix=/usr/local/mysql shell> makeWhen you run
configure, you might want to specify some
options. Run ./configure --help for a list of options. section 2.3.3
Typical configure Options, discusses some of the more useful
options. If configure fails, and you are going to send mail to mysql@lists.mysql.com to ask for
assistance, please include any lines from `config.log' that you think
can help solve the problem. Also include the last couple of lines of output
from configure if configure aborts. Post the bug
report using the mysqlbug script. See section 1.6.2.3
How to Report Bugs or Problems. If the compile fails, see section 2.3.5
Problems Compiling?, for help with a number of common problems.
shell> make installYou might need to run this command as
root.
shell> scripts/mysql_install_dbNote that MySQL versions older than Version 3.22.10 started the MySQL server when you run
mysql_install_db. This is no longer true!
root and ownership of the
data directory to the user that you will run mysqld as: shell> chown -R root /usr/local/mysql shell> chown -R mysql /usr/local/mysql/var shell> chgrp -R mysql /usr/local/mysqlThe first command changes the
owner attribute of the files
to the root user, the second one changes the owner
attribute of the data directory to the mysql user, and the third
one changes the group attribute to the mysql group.
DBI/DBD interface, see section 2.7
Perl Installation Comments.
support-files/mysql.server to the location where
your system has its startup files. More information can be found in the
support-files/mysql.server script itself and in section 2.4.3
Starting and Stopping MySQL Automatically. After everything has been installed, you should initialise and test your distribution:
shell> /usr/local/mysql/bin/safe_mysqld --user=mysql &
If that command fails immediately with mysqld daemon ended, you
can find some information in the file
`mysql-data-directory/'hostname'.err'. The likely reason is that you
already have another mysqld server running. See section 4.1.4
Running Multiple MySQL Servers on the Same Machine.
Now proceed to section 2.4 Post-installation Setup and Testing.
Sometimes patches appear on the mailing list or are placed in the patches area of the MySQL web site (http://www.mysql.com/Downloads/Patches/).
To apply a patch from the mailing list, save the message in which the patch appears in a file, change into the top-level directory of your MySQL source tree, and run these commands:
shell> patch -p1 < patch-file-name shell> rm config.cache shell> make clean
Patches from the FTP site are distributed as plain text files or as files
compressed with gzip. Apply a plain patch as shown previously for
mailing list patches. To apply a compressed patch, change into the top-level
directory of your MySQL source tree and run these commands:
shell> gunzip < patch-file-name.gz | patch -p1 shell> rm config.cache shell> make clean
After applying a patch, follow the instructions for a normal source install,
beginning with the ./configure step. After running the make
install step, restart your MySQL server.
You may need to bring down any currently running server before you run
make install. (Use mysqladmin shutdown to do this.)
Some systems do not allow you to install a new version of a program if it
replaces the version that is currently executing.
configure OptionsThe configure script gives you a great deal of control over how
you configure your MySQL distribution. Typically you do this using options on
the configure command-line. You can also affect
configure using certain environment variables. See section F
Environment Variables. For a list of options supported by
configure, run this command:
shell> ./configure --help
Some of the more commonly-used configure options are described
here:
--without-server option: shell> ./configure --without-serverIf you don't have a C++ compiler,
mysql will not compile
(it is the one client program that requires C++). In this case, you can remove
the code in configure that tests for the C++ compiler and then
run ./configure with the --without-server option.
The compile step will still try to build mysql, but you can
ignore any warnings about `mysql.cc'. (If make stops,
try make -k to tell it to continue with the rest of the build
even if errors occur.)
libmysqld.a)
you should use the --with-embedded-server option.
configure command, something
like one of these: shell> ./configure --prefix=/usr/local/mysql
shell> ./configure --prefix=/usr/local \
--localstatedir=/usr/local/mysql/data
The first command changes the installation prefix so that everything is
installed under `/usr/local/mysql' rather than the default of
`/usr/local'. The second command preserves the default installation
prefix, but overrides the default location for database directories (normally
`/usr/local/var') and changes it to
/usr/local/mysql/data. After you have compiled MySQL, you can
change these options with option files. See section 4.1.2
`my.cnf' Option Files.
configure command like this: shell> ./configure --with-unix-socket-path=/usr/local/mysql/tmp/mysql.sockNote that the given file must be an absolute pathname! You can also later change the location `mysql.sock' by using the MySQL option files. See section A.4.5 How to Protect or Change the MySQL Socket File `/tmp/mysql.sock'.
configure like this: shell> ./configure --with-client-ldflags=-all-static \
--with-mysqld-ldflags=-all-static
gcc and don't have libg++ or
libstdc++ installed, you can tell configure to use
gcc as your C++ compiler: shell> CC=gcc CXX=gcc ./configureWhen you use
gcc as your C++ compiler, it will not attempt
to link in libg++ or libstdc++. This may be a good
idea to do even if you have the above libraries installed, as some versions of
these libraries have caused strange problems for MySQL users in the past. Here
are some common environment variables to set depending on the compiler you are
using:
| Compiler | Recommended options |
| gcc 2.7.2.1 | CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors" |
| egcs 1.0.3a | CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" |
| gcc 2.95.2 | CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro \ -felide-constructors -fno-exceptions -fno-rtti" |
| pgcc 2.90.29 or newer | CFLAGS="-O3 -mpentiumpro -mstack-align-double" CXX=gcc \ CXXFLAGS="-O3 -mpentiumpro -mstack-align-double -felide-constructors \ -fno-exceptions -fno-rtti" |
--prefix=/usr/local/mysql --enable-assembler \ --with-mysqld-ldflags=-all-staticThe full configure line would, in other words, be something like the following for all recent gcc versions:
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro \ -felide-constructors -fno-exceptions -fno-rtti" ./configure \ --prefix=/usr/local/mysql --enable-assembler \ --with-mysqld-ldflags=-all-staticThe binaries we provide on the MySQL web site at http://www.mysql.com/ are all compiled with full optimisation and should be perfect for most users. See section 2.2.6 MySQL Binaries Compiled by MySQL AB. There are some things you can tweak to make an even faster binary, but this is only for advanced users. See section 5.5.3 How Compiling and Linking Affects the Speed of MySQL. If the build fails and produces errors about your compiler or linker not being able to create the shared library `libmysqlclient.so.#' (`#' is a version number), you can work around this problem by giving the
--disable-shared option to configure. In this case,
configure will not build a shared
libmysqlclient.so.# library.
DEFAULT column values for
non-NULL columns (that is, columns that are not allowed to be
NULL). This causes INSERT statements to generate an
error unless you explicitly specify values for all columns that require a
non-NULL value. To suppress use of default values, run
configure like this: shell> CXXFLAGS=-DDONT_USE_DEFAULT_FIELDS ./configure
--with-charset option: shell> ./configure --with-charset=CHARSET
CHARSET may be one of big5,
cp1251, cp1257, czech,
danish, dec8, dos, euc_kr,
gb2312, gbk, german1,
hebrew, hp8, hungarian,
koi8_ru, koi8_ukr, latin1,
latin2, sjis, swe7,
tis620, ujis, usa7, or
win1251ukr. See section 4.6.1
The Character Set Used for Data and Sorting. If you want to convert
characters between the server and the client, you should take a look at the
SET OPTION CHARACTER SET command. See section 5.5.6
SET Syntax. Warning: If
you change character sets after having created any tables, you will have to
run myisamchk -r -q on every table. Your indexes may be sorted
incorrectly otherwise. (This can happen if you install MySQL, create some
tables, then reconfigure MySQL to use a different character set and reinstall
it.) With the option --with-extra-charset=LIST you can define
which additional character sets should be compiled into the server. Here
LIST is either a list of character sets separated with spaces,
complex to include all characters that can't be dynamically
loaded, or all to include all character sets into the binaries.
--with-debug
option: shell> ./configure --with-debugThis causes a safe memory allocator to be included that can find some errors and that provides output about what is happening. See section E.1 Debugging a MySQL server.
--enable-thread-safe-client configure options. This will create a
libmysqlclient_r library with which you should link your threaded
applications. See section 8.4.8
How to Make a Threaded Client.
Caution: You should read this section only if you are interested in helping us test our new code. If you just want to get MySQL up and running on your system, you should use a standard release distribution (either a source or binary distribution will do).
To obtain our most recent development source tree, use these instructions:
BitKeeper from http://www.bitmover.com/cgi-bin/download.cgi.
You will need Bitkeeper 2.0 or newer to access our repository.
BitKeeper is installed, first go to the directory you
want to work from, and then use this command if you want to clone the MySQL
3.23 branch: shell> bk clone bk://work.mysql.com:7000 mysqlTo clone the 4.0 branch, use this command instead:
shell> bk clone bk://work.mysql.com:7001 mysql-4.0In the preceding examples the source tree will be set up in the `mysql/' or `mysql-4.0/' subdirectory of your current directory. The initial download of the source tree may take a while, depending on the speed of your connection; be patient.
autoconf 2.52, automake 1.4,
libtool, and m4 to run the next set of commands.
automake (1.5) doesn't yet work. If you get some strange error
during this stage, check that you really have libtool installed! shell> cd mysql shell> bk -r edit shell> aclocal; autoheader; autoconf; automake; shell> ./configure # Add your favorite options here shell> makeA collection of our standard configure scripts is located in the `BUILD/' subdirectory. If you are lazy, you can use `BUILD/compile-pentium-debug'. To compile on a different architecture, modify the script by removing flags that are Pentium-specific.
make install. Be careful with
this on a production machine; the command may overwrite your live release
installation. If you have another installation of MySQL, we recommand that you
run ./configure with different values for the
prefix, with-tcp-port, and
unix-socket-path options than those used for your production
server.
make test. See section 9.1.2
MySQL Test Suite.
make stage and the distribution
does not compile, please report it to bugs@lists.mysql.com. If you have
installed the latest versions of the required GNU tools, and they crash trying
to process our configuration files, please report that also. However, if you
execute aclocal and get a command not found error or
a similar problem, do not report it. Instead, make sure all the necessary
tools are installed and that your PATH variable is set correctly
so that your shell can find them.
bk clone operation to get the source tree,
you should run bk pull periodically to get the updates.
bk sccstool. If you see some funny diffs or code that you
have a question about, do not hesitate to send e-mail to internals@lists.mysql.com. Also,
if you think you have a better idea on how to do something, send an e-mail to
the same address with a patch. bk diffs will produce a patch for
you after you have made changes to the source. If you do not have the time to
code your idea, just send a description.
BitKeeper has a nice help utility that you can access via
bk helptool. All MySQL programs compile cleanly for us with no warnings on Solaris using
gcc. On other systems, warnings may occur due to differences in
system include files. See section 2.3.6
MIT-pthreads Notes for warnings that may occur when using MIT-pthreads. For
other problems, check the following list.
The solution to many problems involves reconfiguring. If you do need to reconfigure, take note of the following:
configure is run after it already has been run, it may use
information that was gathered during its previous invocation. This information
is stored in `config.cache'. When configure starts up,
it looks for that file and reads its contents if it exists, on the assumption
that the information is still correct. That assumption is invalid when you
reconfigure.
configure, you must run make
again to recompile. However, you may want to remove old object files from
previous builds first because they were compiled using different configuration
options. To prevent old configuration information or object files from being used, run
these commands before rerunning configure:
shell> rm config.cache shell> make clean
Alternatively, you can run make distclean.
The following list describes some of the problems when compiling MySQL that have been found to occur most often:
Internal compiler error: program cc1plus got fatal signal 11 or Out of virtual memory or Virtual memory exhaustedThe problem is that
gcc requires huge amounts of memory to
compile `sql_yacc.cc' with inline functions. Try running
configure with the --with-low-memory option: shell> ./configure --with-low-memoryThis option causes
-fno-inline to be added to the compile
line if you are using gcc and -O0 if you are using
something else. You should try the --with-low-memory option even
if you have so much memory and swap space that you think you can't possibly
have run out. This problem has been observed to occur even on systems with
generous hardware configurations, and the --with-low-memory
option usually fixes it.
configure picks c++ as the compiler
name and GNU c++ links with -lg++. If you are using
gcc, that behavior can cause problems during configuration such
as this: configure: error: installation or configuration problem: C++ compiler cannot create executables.You might also observe problems during compilation related to
g++, libg++, or
libstdc++. One cause of these problems is that you may not have
g++, or you may have g++ but not
libg++, or libstdc++. Take a look at the
`config.log' file. It should contain the exact reason why your c++
compiler didn't work! To work around these problems, you can use
gcc as your C++ compiler. Try setting the environment variable
CXX to "gcc -O3". For example: shell> CXX="gcc -O3" ./configureThis works because
gcc compiles C++ sources as well as
g++ does, but does not link in libg++ or
libstdc++ by default. Another way to fix these problems, of
course, is to install g++, libg++, and
libstdc++. We would however like to recommend you to not use
libg++ or libstdc++ with MySQL as this will only
increase the binary size of mysqld without giving you any benefits. Some
versions of these libraries have also caused strange problems for MySQL users
in the past.
make to GNU make: making all in mit-pthreads make: Fatal error in reader: Makefile, line 18: Badly formed macro assignment or make: file `Makefile' line 18: Must be a separator (: or pthread.h: No such file or directorySolaris and FreeBSD are known to have troublesome
make programs. GNU make Version 3.75 is known to
work.
CFLAGS and CXXFLAGS
environment variables. You can also specify the compiler names this way using
CC and CXX. For example: shell> CC=gcc shell> CFLAGS=-O3 shell> CXX=gcc shell> CXXFLAGS=-O3 shell> export CC CFLAGS CXX CXXFLAGSSee section 2.2.6 MySQL Binaries Compiled by MySQL AB, for a list of flag definitions that have been found to be useful on various systems.
gcc compiler: client/libmysql.c:273: parse error before `__attribute__'
gcc 2.8.1 is known to work, but we recommend using
gcc 2.95.2 or egcs 1.0.3a instead.
mysqld, configure didn't correctly detect the type
of the last argument to accept(), getsockname(), or
getpeername(): cxx: Error: mysqld.cc, line 645: In this statement, the referenced
type of the pointer value "&length" is "unsigned long", which
is not compatible with "int".
new_sock = accept(sock, (struct sockaddr *)&cAddr, &length);
To fix this, edit the `config.h' file (which is generated by
configure). Look for these lines: /* Define as the base type of the last arg to accept */ #define SOCKET_SIZE_TYPE XXXChange
XXX to size_t or int,
depending on your operating system. (Note that you will have to do this each
time you run configure because configure regenerates
`config.h'.)
"sql_yacc.yy", line xxx fatal: default action causes potential...This is a sign that your version of
yacc is deficient. You
probably need to install bison (the GNU version of
yacc) and use that instead.
mysqld or a MySQL client, run
configure with the --with-debug option, then
recompile and link your clients with the new client library. See section E.2
Debugging a MySQL client. This section describes some of the issues involved in using MIT-pthreads.
Note that on Linux you should not use MIT-pthreads but install LinuxThreads! See section 2.6.1 Linux Notes (All Linux Versions).
If your system does not provide native thread support, you will need to build MySQL using the MIT-pthreads package. This includes older FreeBSD systems, SunOS 4.x, Solaris 2.4 and earlier, and some others. See section 2.2.2 Operating Systems Supported by MySQL.
configure with the --with-mit-threads option: shell> ./configure --with-mit-threadsBuilding in a non-source directory is not supported when using MIT-pthreads because we want to minimise our changes to this code.
--without-server to build
only the client code, clients will not know whether MIT-pthreads is being used
and will use Unix socket connections by default. Because Unix sockets do not
work under MIT-pthreads, this means you will need to use -h or
--host when you run client programs.
--use-locking option.
bind() command fails to bind to a
socket without any error message (at least on Solaris). The result is that all
connections to the server fail. For example: shell> mysqladmin version mysqladmin: connect to server at '' failed; error: 'Can't connect to mysql server on localhost (146)'The solution to this is to kill the
mysqld server and
restart it. This has only happened to us when we have forced the server down
and done a restart immediately.
sleep() system call isn't
interruptible with SIGINT (break). This is only noticeable when
you run mysqladmin --sleep. You must wait for the
sleep() call to terminate before the interrupt is served and the
process stops.
ld: warning: symbol `_iob' has differing sizes:
(file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4;
file /usr/lib/libc.so value=0x140);
/my/local/pthreads/lib/libpthread.a(findfp.o) definition taken
ld: warning: symbol `__iob' has differing sizes:
(file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4;
file /usr/lib/libc.so value=0x140);
/my/local/pthreads/lib/libpthread.a(findfp.o) definition taken
implicit declaration of function `int strtoll(...)' implicit declaration of function `int strtoul(...)'
readline to work with MIT-pthreads. (This
isn't needed, but may be interesting for someone.) You will need the following:
Building MySQL
File menu, select Open Workspace.
Build menu, select the Set Active
Configuration menu.
mysqld - Win32 Debug and
click OK.
F7 to begin the build of the debug server, libs, and
some client applications.
Set up and start the server in the same way as for the binary Windows distribution. See section 2.1.2.2 Preparing the Windows MySQL Environment.
Once you've installed MySQL (from either a binary or source distribution), you need to initialise the grant tables, start the server, and make sure that the server works okay. You may also wish to arrange for the server to be started and stopped automatically when your system starts up and shuts down.
Normally you install the grant tables and start the server like this for installation from a source distribution:
shell> ./scripts/mysql_install_db shell> cd mysql_installation_directory shell> ./bin/safe_mysqld --user=mysql &
For a binary distribution (not RPM or pkg packages), do this:
shell> cd mysql_installation_directory shell> ./bin/mysql_install_db shell> ./bin/safe_mysqld --user=mysql &
This creates the mysql database which will hold all database
privileges, the test database which you can use to test MySQL, and
also privilege entries for the user that run mysql_install_db and a
root user (without any passwords). This also starts the
mysqld server.
mysql_install_db will not overwrite any old privilege tables, so
it should be safe to run in any circumstances. If you don't want to have the
test database you can remove it with mysqladmin -u root drop
test.
Testing is most easily done from the top-level directory of the MySQL distribution. For a binary distribution, this is your installation directory (typically something like `/usr/local/mysql'). For a source distribution, this is the main directory of your MySQL source tree.
In the commands shown in this section and in the following subsections,
BINDIR is the path to the location in which programs like
mysqladmin and safe_mysqld are installed. For a binary
distribution, this is the `bin' directory within the distribution. For
a source distribution, BINDIR is probably
`/usr/local/bin', unless you specified an installation directory other
than `/usr/local' when you ran configure.
EXECDIR is the location in which the mysqld server is
installed. For a binary distribution, this is the same as BINDIR.
For a source distribution, EXECDIR is probably
`/usr/local/libexec'.
Testing is described in detail:
mysqld server and set up the initial
MySQL grant tables containing the privileges that determine how users are
allowed to connect to the server. This is normally done with the
mysql_install_db script: shell> scripts/mysql_install_dbTypically,
mysql_install_db needs to be run only the first
time you install MySQL. Therefore, if you are upgrading an existing
installation, you can skip this step. (However, mysql_install_db
is quite safe to use and will not update any tables that already exist, so if
you are unsure of what to do, you can always run
mysql_install_db.) mysql_install_db creates six
tables (user, db, host,
tables_priv, columns_priv, and func) in
the mysql database. A description of the initial privileges is
given in section 4.3.4
Setting Up the Initial MySQL Privileges. Briefly, these privileges allow
the MySQL root user to do anything, and allow anybody to create
or use databases with a name of test or starting with
test_. If you don't set up the grant tables, the following error
will appear in the log file when you start the server: mysqld: Can't find file: 'host.frm'This may also happen with a binary MySQL distribution if you don't start MySQL by executing exactly
./bin/safe_mysqld! See section 4.7.2
safe_mysqld, The Wrapper Around mysqld. You
might need to run mysql_install_db as root. However,
if you prefer, you can run the MySQL server as an unprivileged
(non-root) user, provided that the user can read and write files
in the database directory. Instructions for running MySQL as an unprivileged
user are given in section A.3.2
How to Run MySQL As a Normal User. If you have problems with
mysql_install_db, see section 2.4.1
Problems Running mysql_install_db. There are some
alternatives to running the mysql_install_db script as it is
provided in the MySQL distribution:
mysql_install_db before running it, to
change the initial privileges that are installed into the grant tables. This
is useful if you want to install MySQL on a lot of machines with the same
privileges. In this case you probably should need only to add a few extra
INSERT statements to the mysql.user and
mysql.db tables!
mysql_install_db, then use mysql -u root
mysql to connect to the grant tables as the MySQL root
user and issue SQL statements to modify the grant tables directly.
mysql_install_db. shell> cd mysql_installation_directory shell> bin/safe_mysqld &If you have problems starting the server, see section 2.4.2 Problems Starting the MySQL Server.
mysqladmin to verify that the server is running. The
following commands provide a simple test to check that the server is up and
responding to connections: shell> BINDIR/mysqladmin version shell> BINDIR/mysqladmin variablesThe output from
mysqladmin version varies slightly
depending on your platform and version of MySQL, but should be similar to that
shown here: shell> BINDIR/mysqladmin version mysqladmin Ver 8.14 Distrib 3.23.32, for linux on i586 Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL license. Server version 3.23.32-debug Protocol version 10 Connection Localhost via Unix socket TCP port 3306 UNIX socket /tmp/mysql.sock Uptime: 16 sec Threads: 1 Questions: 9 Slow queries: 0 Opens: 7 Flush tables: 2 Open tables: 0 Queries per second avg: 0.000 Memory in use: 132K Max memory used: 16773KTo get a feeling for what else you can do with
BINDIR/mysqladmin, invoke it with the --help option.
shell> BINDIR/mysqladmin -u root shutdown
safe_mysqld or by invoking mysqld directly. For
example: shell> BINDIR/safe_mysqld --log &If
safe_mysqld fails, try running it from the MySQL
installation directory (if you are not already there). If that doesn't work,
see section 2.4.2
Problems Starting the MySQL Server.
shell> BINDIR/mysqlshow +-----------+ | Databases | +-----------+ | mysql | +-----------+ shell> BINDIR/mysqlshow mysql Database: mysql +--------------+ | Tables | +--------------+ | columns_priv | | db | | func | | host | | tables_priv | | user | +--------------+ shell> BINDIR/mysql -e "SELECT host,db,user FROM db" mysql +------+--------+------+ | host | db | user | +------+--------+------+ | % | test | | | % | test_% | | +------+--------+------+There is also a benchmark suite in the `sql-bench' directory (under the MySQL installation directory) that you can use to compare how MySQL performs on different platforms. The `sql-bench/Results' directory contains the results from many runs against different databases and platforms. To run all tests, execute these commands:
shell> cd sql-bench shell> run-all-testsIf you don't have the `sql-bench' directory, you are probably using an RPM for a binary distribution. (Source distribution RPMs include the benchmark directory.) In this case, you must first install the benchmark suite before you can use it. Beginning with MySQL Version 3.22, there are benchmark RPM files named `mysql-bench-VERSION-i386.rpm' that contain benchmark code and data. If you have a source distribution, you can also run the tests in the `tests' subdirectory. For example, to run `auto_increment.tst', do this:
shell> BINDIR/mysql -vvf test < ./tests/auto_increment.tstThe expected results are shown in the `./tests/auto_increment.res' file.
mysql_install_dbThe purpose of the mysql_install_db script is to generate new
MySQL privilege tables. It will not affect any other data! It will also not do
anything if you already have MySQL privilege tables installed!
If you want to re-create your privilege tables, you should take down the
mysqld server, if it's running, and then do something like:
mv mysql-data-directory/mysql mysql-data-directory/mysql-old mysql_install_db
This section lists problems you might encounter when you run
mysql_install_db:
mysql_install_db doesn't install the grant
tables
mysql_install_db fails to install the grant
tables and terminates after displaying the following messages: starting mysqld daemon with databases from XXXXXX mysql daemon endedIn this case, you should examine the log file very carefully! The log should be located in the directory `XXXXXX' named by the error message, and should indicate why
mysqld didn't start. If you
don't understand what happened, include the log when you post a bug report
using mysqlbug! See section 1.6.2.3
How to Report Bugs or Problems.
mysqld daemon running
mysql_install_db
at all. You have to run mysql_install_db only once, when you
install MySQL the first time.
mysqld daemon doesn't work when
one daemon is running
Can't start server: Bind on TCP/IP port:
Address already in use or Can't start server: Bind on unix
socket.... See section 4.1.3
Installing Many Servers on the Same Machine.
mysql_install_db or when starting or using
mysqld. You can specify a different socket and temporary
directory as follows: shell> TMPDIR=/some_tmp_dir/ shell> MYSQL_UNIX_PORT=/some_tmp_dir/mysqld.sock shell> export TMPDIR MYSQL_UNIX_PORTSee section A.4.5 How to Protect or Change the MySQL Socket File `/tmp/mysql.sock'. `some_tmp_dir' should be the path to some directory for which you have write permission. See section F Environment Variables. After this you should be able to run
mysql_install_db and start the server with these commands: shell> scripts/mysql_install_db shell> BINDIR/safe_mysqld &
mysqld crashes immediately
glibc
older than 2.0.7-5, you should make sure you have installed all
glibc patches! There is a lot of information about this in the
MySQL mail archives. Links to the mail archives are available online at http://lists.mysql.com/. Also, see section
2.6.1
Linux Notes (All Linux Versions). You can also start mysqld
manually using the --skip-grant-tables option and add the
privilege information yourself using mysql: shell> BINDIR/safe_mysqld --skip-grant-tables & shell> BINDIR/mysql -u root mysqlFrom
mysql, manually execute the SQL commands in
mysql_install_db. Make sure you run mysqladmin
flush-privileges or mysqladmin reload afterward to tell
the server to reload the grant tables. If you are going to use tables that support transactions (InnoDB, BDB), you should first create a my.cnf file and set startup options for the table types you plan to use. See section 7 MySQL Table Types.
Generally, you start the mysqld server in one of these ways:
mysql.server. This script is used primarily at
system startup and shutdown, and is described more fully in section 2.4.3
Starting and Stopping MySQL Automatically.
safe_mysqld, which tries to determine the proper
options for mysqld and then runs it with those options. See
section 4.7.2
safe_mysqld, The Wrapper Around mysqld.
mysqld directly. When the mysqld daemon starts up, it changes the directory to
the data directory. This is where it expects to write log files and the pid
(process ID) file, and where it expects to find databases.
The data directory location is hardwired in when the distribution is
compiled. However, if mysqld expects to find the data directory
somewhere other than where it really is on your system, it will not work
properly. If you have problems with incorrect paths, you can find out what
options mysqld allows and what the default path settings are by
invoking mysqld with the --help option. You can
override the defaults by specifying the correct pathnames as command-line
arguments to mysqld. (These options can be used with
safe_mysqld as well.)
Normally you should need to tell mysqld only the base directory
under which MySQL is installed. You can do this with the --basedir
option. You can also use --help to check the effect of changing
path options (note that --help must be the final
option of the mysqld command). For example:
shell> EXECDIR/mysqld --basedir=/usr/local --help
Once you determine the path settings you want, start the server without the
--help option.
Whichever method you use to start the server, if it fails to start up
correctly, check the log file to see if you can find out why. Log files are
located in the data directory (typically `/usr/local/mysql/data' for a
binary distribution, `/usr/local/var' for a source distribution, and
`\mysql\data\mysql.err' on Windows). Look in the data directory for
files with names of the form `host_name.err' and
`host_name.log' where host_name is the name of your server
host. Then check the last few lines of these files:
shell> tail host_name.err shell> tail host_name.log
Look for something like the following in the log file:
000729 14:50:10 bdb: Recovery function for LSN 1 27595 failed 000729 14:50:10 bdb: warning: ./test/t1.db: No such file or directory 000729 14:50:10 Can't init databases
This means that you didn't start mysqld with
--bdb-no-recover and Berkeley DB found something wrong with its log
files when it tried to recover your databases. To be able to continue, you
should move away the old Berkeley DB log file from the database directory to
some other place, where you can later examine it. The log files are named
`log.0000000001', where the number will increase over time.
If you are running mysqld with BDB table support and
mysqld core dumps at start this could be because of some problems
with the BDB recover log. In this case you can try starting mysqld
with --bdb-no-recover. If this helps, then you should remove all
`log.*' files from the data directory and try starting
mysqld again.
If you get the following error, it means that some other program (or another
mysqld server) is already using the TCP/IP port or socket
mysqld is trying to use:
Can't start server: Bind on TCP/IP port: Address already in use or Can't start server : Bind on unix socket...
Use ps to make sure that you don't have another
mysqld server running. If you can't find another server running,
you can try to execute the command telnet your-host-name
tcp-ip-port-number and press Enter a couple of times. If you don't get an
error message like telnet: Unable to connect to remote host: Connection
refused, something is using the TCP/IP port mysqld is trying
to use. See section 2.4.1
Problems Running mysql_install_db and section 4.1.4
Running Multiple MySQL Servers on the Same Machine.
If mysqld is currently running, you can find out what path
settings it is using by executing this command:
shell> mysqladmin variables
or
shell> mysqladmin -h 'your-host-name' variables
If you get Errcode 13, which means Permission
denied, when starting mysqld this means that you didn't have
the right to read/create files in the MySQL database or log directory. In this
case you should either start mysqld as the root user or change the
permissions for the involved files and directories so that you have the right to
use them.
If safe_mysqld starts the server but you can't connect to it,
you should make sure you have an entry in `/etc/hosts' that looks like
this:
127.0.0.1 localhost
This problem occurs only on systems that don't have a working thread library and for which MySQL must be configured to use MIT-pthreads.
If you can't get mysqld to start you can try to make a trace
file to find the problem. See section E.1.2
Creating Trace Files.
If you are using InnoDB tables, refer to the InnoDB-specific startup options. See section 7.5.2 InnoDB Startup Options.
If you are using BDB (Berkeley DB) tables, you should familiarise yourself with the different BDB specific startup options. See section 7.6.3 BDB startup options.
The mysql.server and safe_mysqld scripts can be
used to start the server automatically at system startup time.
mysql.server can also be used to stop the server.
The mysql.server script can be used to start or stop the server
by invoking it with start or stop arguments:
shell> mysql.server start shell> mysql.server stop
mysql.server can be found in the `share/mysql'
directory under the MySQL installation directory or in the
`support-files' directory of the MySQL source tree.
Before mysql.server starts the server, it changes the directory
to the MySQL installation directory, then invokes safe_mysqld. You
might need to edit mysql.server if you have a binary distribution
that you've installed in a non-standard location. Modify it to cd
into the proper directory before it runs safe_mysqld. If you want
the server to run as some specific user, add an appropriate user
line to the `/etc/my.cnf' file, as shown later in this section.
mysql.server stop brings down the server by sending a signal to
it. You can take down the server manually by executing mysqladmin
shutdown.
You might want to add these start and stop commands to the appropriate places
in your `/etc/rc*' files when you start using MySQL for production
applications. Note that if you modify mysql.server, and then
upgrade MySQL sometime, your modified version will be overwritten, so you should
make a copy of your edited version that you can reinstall.
If your system uses `/etc/rc.local' to start external scripts, you should append the following to it:
/bin/sh -c 'cd /usr/local/mysql ; ./bin/safe_mysqld --user=mysql &'
You can also add options for mysql.server in
a global `/etc/my.cnf' file. A typical `/etc/my.cnf' file
might look like this:
[mysqld] datadir=/usr/local/mysql/var socket=/var/tmp/mysql.sock port=3306 user=mysql [mysql.server] basedir=/usr/local/mysql
The mysql.server script understands the following options:
datadir, basedir, and pid-file.
The following table shows which option groups each of the startup scripts read from option files:
| Script | Option groups |
mysqld |
mysqld and server |
mysql.server |
mysql.server, mysqld, and
server |
safe_mysqld |
mysql.server, mysqld, and
server |
See section 4.1.2 `my.cnf' Option Files.
You can always move the MySQL form and datafiles between different versions
on the same architecture as long as you have the same base version of MySQL. The
current base version is 3. If you change the character set when running MySQL
(which may also change the sort order), you must run myisamchk -r
-q on all tables. Otherwise, your indexes may not be ordered correctly.
If you are afraid of new versions, you can always rename your old
mysqld to something like mysqld-old-version-number. If
your new mysqld then does something unexpected, you can simply shut
it down and restart with your old mysqld!
When you do an upgrade you should also back up your old databases, of course.
If after an upgrade, you experience problems with recompiled client programs,
like Commands out of sync or unexpected core dumps, you probably
have used an old header or library file when compiling your programs. In this
case you should check the date for your `mysql.h' file and
`libmysqlclient.a' library to verify that they are from the new MySQL
distribution. If not, please recompile your programs!
If you get some problems that the new mysqld server doesn't want
to start or that you can't connect without a password, check that you don't have
some old `my.cnf' file from your old installation! You can check this
with: program-name --print-defaults. If this outputs anything other
than the program name, you have an active `my.cnf' file that will
affect things!
It is a good idea to rebuild and reinstall the
Msql-Mysql-modules distribution whenever you install a new release
of MySQL, particularly if you notice symptoms such as all your DBI
scripts dumping core after you upgrade MySQL.
You can use your old datafiles without any modification with Version 4.0. If
you want to move your data from a MySQL 4.0 server to an older server, you have
to use mysqldump.
Old clients should work with a Version 4.0 server without any problems.
The following lists tell what you have to watch out for when upgrading to version 4.0;
DOUBLE and FLOAT columns are now honoring the
UNSIGNED flag on storage (before, UNSIGNED was
ignored for these columns).
ORDER BY column DESC now always sorts NULL
values first; in 3.23 this was not always consistent.
SHOW INDEX has 2 columns more (Null and
Index_type) than it had in 3.23.
SIGNED is a reserved word.
|, &,
<<, >>, and ~ is now
unsigned. This may cause problems if you are using them in a context where you
want a signed result. See section 6.3.5
Cast Functions.
UNSIGNED, the result will be unsigned! In
other words, before upgrading to MySQL 4.0, you should check your application
for cases where you are subtracting a value from an unsigned entity and want a
negative answer or subtracting an unsigned value from an integer column. You
can disable this behaviour by using the
--sql-mode=NO_UNSIGNED_SUBTRACTION option when starting
mysqld. See section 6.3.5
Cast Functions.
MATCH ... AGAINST (... IN BOOLEAN MODE) with your
tables, you need to rebuild them with ALTER TABLE table_name
TYPE=MyISAM, even if they are of MyISAM
type.
LOCATE() and INSTR() are case-sensitive if one
of the arguments is a binary string.
STRCMP() now uses the current character set when doing
comparisons, which means that the default comparison behavior now is
case-insensitive.
HEX(string) now returns the characters in string converted to
hexadecimal. If you want to convert a number to hexadecimal, you should ensure
that you call HEX() with a numeric argument.
INSERT INTO ... SELECT always had
IGNORE enabled. In 4.0.1, MySQL will stop (and possibly roll
back) in case of an error if you don't specify IGNORE.
mysql_drop_db,
mysql_create_db, and mysql_connect are not supported
anymore, unless you compile MySQL with
CFLAGS=-DUSE_OLD_FUNCTIONS. Instead of doing this, it is
preferable to change the client to use the new 4.0 API.
MYSQL_FIELD structure, length and
max_length have changed from unsigned int to
unsigned long. This should not cause any problems, except that
they may generate warning messages when used as arguments in the
printf() class of functions.
TRUNCATE TABLE when you want to delete all
rows from a table and you don't care how many rows were deleted. (Because
TRUNCATE TABLE is faster than DELETE FROM
table_name).
LOCK TABLES or
transaction when trying to execute TRUNCATE TABLE or DROP
DATABASE.
SHOW OPEN TABLE has changed.
mysql_thread_init() and
mysql_thread_end(). See section 8.4.8
How to Make a Threaded Client.
drop_db() call.
RAND(seed) returns a different random number series in 4.0
than in 3.23; this was done to further differentiate RAND(seed)
and RAND(seed+1). MySQL Version 3.23 supports tables of the new MyISAM type and
the old ISAM type. You don't have to convert your old tables to use
these with Version 3.23. By default, all new tables will be created with type
MyISAM (unless you start mysqld with the
--default-table-type=isam option). You can change an
ISAM table to a MyISAM table with ALTER TABLE
table_name TYPE=MyISAM or the Perl script
mysql_convert_table_format.
Version 3.22 and 3.21 clients will work without any problems with a Version 3.23 server.
The following list tells what you have to watch out for when upgrading to Version 3.23:
tis620 character set must be fixed
with myisamchk -r or REPAIR TABLE.
DROP DATABASE on a symbolic linked database, both
the link and the original database are deleted. (This didn't happen in 3.22
because configure didn't detect the readlink system call.)
OPTIMIZE TABLE now only works for MyISAM tables.
For other table types, you can use ALTER TABLE to optimise the
table. During OPTIMIZE TABLE the table is now locked from other
threads.
mysql is now by default started with the
option --no-named-commands (-g). This option can be disabled with
--enable-named-commands (-G). This may cause incompatibility
problems in some cases@-for example, in SQL scripts that use named commands
without a semicolon! Long format commands still work from the first line.
MONTH())
will now return 0 for 0000-00-00 dates. (MySQL 3.22 returned
NULL.)
german character sort order, you must
repair all your tables with isamchk -r, as we have made some
changes in the sort order!
IF will now depend on both
arguments and not only the first argument.
AUTO_INCREMENT will not work with negative numbers. The
reason for this is that negative numbers caused problems when wrapping from -1
to 0. AUTO_INCREMENT for MyISAM tables is no handled at a lower
level and is much faster than before. For MyISAM tables old numbers are also
not reused anymore, even if you delete some rows from the table.
CASE, DELAYED, ELSE,
END, FULLTEXT, INNER,
RIGHT, THEN, and WHEN are now reserved
words.
FLOAT(X) is now a true floating-point type and not a value
with a fixed number of decimals.
DECIMAL(length,dec) the length argument no
longer includes a place for the sign or the decimal point.
TIME string must now be of one of the following formats:
[[[DAYS] [H]H:]MM:]SS[.fraction] or
[[[[[H]H]H]H]MM]SS[.fraction].
LIKE now compares strings using the same character comparison
rules as =. If you require the old behavior, you can compile
MySQL with the CXXFLAGS=-DLIKE_CMP_TOUPPER flag.
REGEXP is now case-insensitive for normal (not binary)
strings.
CHECK TABLE or
myisamchk for MyISAM tables (`.MYI') and
isamchk for ISAM (`.ISM') tables.
mysqldump files to be compatible between
MySQL Version 3.22 and Version 3.23, you should not use the --opt
or --full option to mysqldump.
DATE_FORMAT() to make sure there is a
`%' before each format character. (MySQL Version 3.22 and later
already allowed this syntax.)
mysql_fetch_fields_direct is now a function (it was a macro)
and it returns a pointer to a MYSQL_FIELD instead of a
MYSQL_FIELD.
mysql_num_fields() can no longer be used on a
MYSQL* object (it's now a function that takes
MYSQL_RES* as an argument, so you should use
mysql_field_count() instead).
SELECT DISTINCT ... was
almost always sorted. In Version 3.23, you must use GROUP BY or
ORDER BY to obtain sorted output.
SUM() now returns NULL, instead of 0, if there
are no matching rows. This is according to ANSI SQL.
AND or OR with NULL values will
now return NULL instead of 0. This mostly affects queries that
use NOT on an AND/OR expression as NOT
NULL = NULL. LPAD() and RPAD()
will shorten the result string if it's longer than the length argument.
Nothing that affects compatibility has changed between versions 3.21 and
3.22. The only pitfall is that new tables that are created with
DATE type columns will use the new way to store the date. You can't
access these new fields from an old version of mysqld.
After installing MySQL Version 3.22, you should start the new server and then
run the mysql_fix_privilege_tables script. This will add the new
privileges that you need to use the GRANT command. If you forget
this, you will get Access denied when you try to use ALTER
TABLE, CREATE INDEX, or DROP INDEX. If your
MySQL root user requires a password, you should give this as an argument to
mysql_fix_privilege_tables.
The C API interface to mysql_real_connect() has changed. If you
have an old client program that calls this function, you must place a
0 for the new db argument (or recode the client to
send the db element for faster connections). You must also call
mysql_init() before calling mysql_real_connect()! This
change was done to allow the new mysql_options() function to save
options in the MYSQL handler structure.
The mysqld variable key_buffer has changed names to
key_buffer_size, but you can still use the old name in your startup
files.
If you are running a version older than Version 3.20.28 and want to switch to Version 3.21, you need to do the following:
You can start the mysqld Version 3.21 server with
safe_mysqld --old-protocol to use it with clients from a Version
3.20 distribution. In this case, the new client function
mysql_errno() will not return any server error, only
CR_UNKNOWN_ERROR (but it works for client errors), and the server
uses the old password() checking rather than the new one.
If you are not using the --old-protocol option
to mysqld, you will need to make the following changes:
MyODBC 2.x driver.
scripts/add_long_password must be run to convert
the Password field in the mysql.user table to
CHAR(16).
mysql.user table (to
get 62-bit rather than 31-bit passwords).
MySQL Version 3.20.28 and above can handle the new user table
format without affecting clients. If you have a MySQL version earlier than
Version 3.20.28, passwords will no longer work with it if you convert the
user table. So to be safe, you should first upgrade to at least
Version 3.20.28 and then upgrade to Version 3.21.
The new client code works with a 3.20.x
mysqld server, so if you experience problems with 3.21.x, you can
use the old 3.20.x server without having to recompile the clients again.
If you are not using the --old-protocol option to
mysqld, old clients will issue the error message:
ERROR: Protocol mismatch. Server Version = 10 Client Version = 9
The new Perl DBI/DBD interface also supports the
old mysqlperl interface. The only change you have to make if you
use mysqlperl is to change the arguments to the
connect() function. The new arguments are: host,
database, user, and password (the
user and password arguments have changed places). See
section 8.2.2
The DBI Interface.
The following changes may affect queries in old applications:
HAVING must now be specified before any ORDER BY
clause.
LOCATE() have been swapped.
DATE,
TIME, and TIMESTAMP. If you are using MySQL Version 3.23, you can copy the `.frm', `.MYI', and `.MYD' files between different architectures that support the same floating-point format. (MySQL takes care of any byte-swapping issues.)
The MySQL ISAM data and index files (`.ISD' and
`*.ISM', respectively) are architecture-dependent and in some cases
OS-dependent. If you want to move your applications to another machine that has
a different architecture or OS than your current machine, you should not try to
move a database by simply copying the files to the other machine. Use
mysqldump instead.
By default, mysqldump will create a file full of SQL statements.
You can then transfer the file to the other machine and feed it as input to the
mysql client.
Try mysqldump --help to see what options are available. If you
are moving the data to a newer version of MySQL, you should use mysqldump
--opt with the newer version to get a fast, compact dump.
The easiest (although not the fastest) way to move a database between two machines is to run the following commands on the machine on which the database is located:
shell> mysqladmin -h 'other hostname' create db_name
shell> mysqldump --opt db_name \
| mysql -h 'other hostname' db_name
If you want to copy a database from a remote machine over a slow network, you can use:
shell> mysqladmin create db_name
shell> mysqldump -h 'other hostname' --opt --compress db_name \
| mysql db_name
You can also store the result in a file, then transfer the file to the target machine and load the file into the database there. For example, you can dump a database to a file on the source machine like this:
shell> mysqldump --quick db_name | gzip > db_name.contents.gz
(The file created in this example is compressed.) Transfer the file containing the database contents to the target machine and run these commands there:
shell> mysqladmin create db_name shell> gunzip < db_name.contents.gz | mysql db_name
You can also use mysqldump
and mysqlimport to accomplish the database transfer. For big
tables, this is much faster than simply using mysqldump. In the
following commands, DUMPDIR represents the full pathname of the
directory you use to store the output from mysqldump.
First, create the directory for the output files and dump the database:
shell> mkdir DUMPDIR shell> mysqldump --tab=DUMPDIR db_name
Then transfer the files in the DUMPDIR directory to some
corresponding directory on the target machine and load the files into MySQL
there:
shell> mysqladmin create db_name # create database shell> cat DUMPDIR/*.sql | mysql db_name # create tables in database shell> mysqlimport db_name DUMPDIR/*.txt # load data into tables
Also, don't forget to copy the mysql database because that's
where the grant tables (user, db, host)
are stored. You may have to run commands as the MySQL root user on
the new machine until you have the mysql database in place.
After you import the mysql database on the new machine, execute
mysqladmin flush-privileges so that the server reloads the grant
table information.
The following notes regarding glibc apply only to the situation
when you build MySQL yourself. If you are running Linux on an x86 machine, in
most cases it is much better for you to just use our binary. We link our
binaries against the best patched version of glibc we can come up
with and with the best compiler options, in an attempt to make it suitable for a
high-load server. So if you read the following text, and are in doubt about what
you should do, try our binary first to see if it meets your needs, and worry
about your own build only after you have discovered that our binary is not good
enough. In that case, we would appreciate a note about it, so we can build a
better binary next time. For a typical user, even for setups with a lot of
concurrent connections and/or tables exceeding 2GB limit, our binary in most
cases is the best choice.
MySQL uses LinuxThreads on Linux. If you are using an old Linux version that
doesn't have glibc2, you must install LinuxThreads before trying to
compile MySQL. You can get LinuxThreads at http://www.mysql.com/Downloads/Linux/.
Note: we have seen some strange problems with Linux 2.2.14 and MySQL on SMP systems. If you have a SMP system, we recommend you upgrade to Linux 2.4 as soon as possible! Your system will be faster and more stable by doing this!
Note that glibc versions before and including Version 2.1.1 have
a fatal bug in pthread_mutex_timedwait handling, which is used when
you do INSERT DELAYED. We recommend that you not use INSERT
DELAYED before upgrading glibc.
If you plan to have 1000+ concurrent connections, you will need to make some
changes to LinuxThreads, recompile it, and relink MySQL against the new
`libpthread.a'. Increase PTHREAD_THREADS_MAX in
`sysdeps/unix/sysv/linux/bits/local_lim.h' to 4096 and decrease
STACK_SIZE in `linuxthreads/internals.h' to 256 KB. The
paths are relative to the root of glibc Note that MySQL will not be
stable with around 600-1000 connections if STACK_SIZE is the
default of 2 MB.
If MySQL can't open enough files, or connections, it may be that you haven't configured Linux to handle enough files.
In Linux 2.2 and onward, you can check the number of allocated file handlers by doing:
cat /proc/sys/fs/file-max cat /proc/sys/fs/dquot-max cat /proc/sys/fs/super-max
If you have more than 16 MB of memory, you should add something like the following in your boot script (`/etc/rc/boot.local' on SuSE):
echo 65536 > /proc/sys/fs/file-max echo 8192 > /proc/sys/fs/dquot-max echo 1024 > /proc/sys/fs/super-max
You can also run the preceding commands from the command-line as root, but in this case your old limits will be used the next time your computer reboots.
You should also add /etc/my.cnf:
[safe_mysqld] open-files-limit=8192
This should allow MySQL to create up to 8192 connections + files.
The STACK_SIZE constant in LinuxThreads controls the spacing of
thread stacks in the address space. It needs to be large enough so that there
will be plenty of room for the stack of each individual thread, but small enough
to keep the stack of some threads from running into the global
mysqld data. Unfortunately, the Linux implementation of
mmap(), as we have experimentally discovered, will successfully
unmap an already mapped region if you ask it to map out an address already in
use, zeroing out the data on the entire page, instead of returning an error. So,
the safety of mysqld or any other threaded application depends on
the "gentleman" behavior of the code that creates threads. The user must take
measures to make sure the number of running threads at any time is sufficiently
low for thread stacks to stay away from the global heap. With
mysqld, you should enforce this "gentleman" behavior by setting a
reasonable value for the max_connections variable.
If you build MySQL yourself and do not want to mess with patching
LinuxThreads, you should set max_connections to a value no higher
than 500. It should be even less if you have a large key buffer, large heap
tables, or some other things that make mysqld allocate a lot of
memory, or if you are running a 2.2 kernel with a 2GB patch. If you are using
our binary or RPM version 3.23.25 or later, you can safely set
max_connections at 1500, assuming no large key buffer or heap
tables with lots of data. The more you reduce STACK_SIZE in
LinuxThreads the more threads you can safely create. We recommend the values
between 128K and 256K.
If you use a lot of concurrent connections, you may suffer from a "feature"
in the 2.2 kernel that penalises a process for forking or cloning a child in an
attempt to prevent a fork bomb attack. This will cause MySQL not to scale well
as you increase the number of concurrent clients. On single-CPU systems, we have
seen this manifested in a very slow thread creation, which means it may take a
long time to connect to MySQL (as long as 1 minute), and it may take just as
long to shut it down. On multiple-CPU systems, we have observed a gradual drop
in query speed as the number of clients increases. In the process of trying to
find a solution, we have received a kernel patch from one of our users, who
claimed it made a lot of difference for his site. The patch is available at http://www.mysql.com/Downloads/Patches/linux-fork.patch.
We have now done rather extensive testing of this patch on both development and
production systems. It has significantly improved MySQL performance
without causing any problems and we now recommend it to our users who are still
running high-load servers on 2.2 kernels. This issue has been fixed in the 2.4
kernel, so if you are not satisfied with the current performance of your system,
rather than patching your 2.2 kernel, it might be easier to just upgrade to 2.4,
which will also give you a nice SMP boost in addition to fixing this fairness
bug.
We have tested MySQL on the 2.4 kernel on a 2-CPU machine and found MySQL
scales much better@-there was virtually no slowdown on queries
throughput all the way up to 1000 clients, and the MySQL scaling factor
(computed as the ratio of maximum throughput to the throughput with one client)
was 180%. We have observed similar results on a 4-CPU system@-virtually no
slowdown as the number of clients was increased up to 1000, and 300% scaling
factor. So for a high-load SMP server we would definitely recommend the 2.4
kernel at this point. We have discovered that it is essential to run
mysqld process with the highest possible priority on the 2.4 kernel
to achieve maximum performance. This can be done by adding renice -20
$$ command to safe_mysqld. In our testing on a 4-CPU
machine, increasing the priority gave 60% increase in throughput with 400
clients.
We are currently also trying to collect more info on how well
MySQL performs on 2.4 kernel on 4-way and 8-way systems. If you
have access such a system and have done some benchmarks, please send a mail to
docs@mysql.com with the results - we will
include them in the manual.
There is another issue that greatly hurts MySQL performance, especially on
SMP systems. The implementation of mutex in LinuxThreads in
glibc-2.1 is very bad for programs with many threads that only hold
the mutex for a short time. On an SMP system, ironic as it is, if you link MySQL
against unmodified LinuxThreads, removing processors from the
machine improves MySQL performance in many cases. We have made a patch available
for glibc 2.1.3 to correct this behavior (http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch).
With glibc-2.2.2 MySQL version 3.23.36 will use the adaptive
mutex, which is much better than even the patched one in
glibc-2.1.3. Be warned, however, that under some conditions, the
current mutex code in glibc-2.2.2 overspins, which hurts MySQL
performance. The chance of this condition can be reduced by renicing
mysqld process to the highest priority. We have also been able to
correct the overspin behavior with a patch, available at http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch.
It combines the correction of overspin, maximum number of threads, and stack
spacing all in one. You will need to apply it in the linuxthreads
directory with patch -p0 </tmp/linuxthreads-2.2.2.patch. We hope
it will be included in some form in to the future releases of
glibc-2.2. In any case, if you link against
glibc-2.2.2 you still need to correct STACK_SIZE and
PTHREAD_THREADS_MAX. We hope that the defaults will be corrected to
some more acceptable values for high-load MySQL setup in the future, so that
your own build can be reduced to ./configure; make; make install.
We recommend that you use the above patches to build a special static version
of libpthread.a and use it only for statically linking against
MySQL. We know that the patches are safe for MySQL and
significantly improve its performance, but we cannot say anything about other
applications. If you link other applications against the patched version of the
library, or build a patched shared version and install it on your system, you
are doing it at your own risk with regard to other applications that depend on
LinuxThreads.
If you experience any strange problems during the installation of MySQL, or with some common utilties hanging, it is very likely that they are either library or compiler related. If this is the case, using our binary will resolve them.
One known problem with the binary distribution is that with older Linux
systems that use libc (like RedHat 4.x or Slackware), you will get
some non-fatal problems with hostname resolution. See section 2.6.1.1
Linux Notes for Binary Distributions.
When using LinuxThreads you will see a minimum of three processes running. These are in fact threads. There will be one thread for the LinuxThreads manager, one thread to handle connections, and one thread to handle alarms and signals.
Note that the Linux kernel and the LinuxThread library can by default only have 1024 threads. This means that you can only have up to 1021 connections to MySQL on an unpatched system. The page http://www.volano.com/linuxnotes.html contains information how to go around this limit.
If you see a dead mysqld daemon process with ps,
this usually means that you have found a bug in MySQL or you have a corrupted
table. See section A.4.1
What To Do If MySQL Keeps Crashing.
To get a core dump on Linux if mysqld dies with a
SIGSEGV signal, you can start mysqld with the
--core-file option. Note that you also probably need to raise the
core file size by adding ulimit -c 1000000 to
safe_mysqld or starting safe_mysqld with
--core-file-sizes=1000000. See section 4.7.2
safe_mysqld, The Wrapper Around mysqld.
If you are linking your own MySQL client and get the error:
ld.so.1: ./my: fatal: libmysqlclient.so.4: open failed: No such file or directory
When executing them, the problem can be avoided by one of the following methods:
-Lpath):
-Wl,r/path-libmysqlclient.so.
libmysqclient.so to `/usr/lib'.
libmysqlclient.so is
located to the LD_RUN_PATH environment variable before running
your client. If you are using the Fujitsu compiler (fcc / FCC) you will have
some problems compiling MySQL because the Linux header files are very
gcc oriented.
The following configure line should work with
fcc/FCC:
CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE \ -DCONST=const -DNO_STRTOLL_PROTO" CXX=FCC CXXFLAGS="-O -K fast -K lib \ -K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE -DCONST=const \ -Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO \ '-D_EXTERN_INLINE=static __inline'" ./configure --prefix=/usr/local/mysql \ --enable-assembler --with-mysqld-ldflags=-all-static --disable-shared \ --with-low-memory
MySQL needs at least Linux Version 2.0.
Warning: We have reports from some MySQL users that they have got serious stability problems with MySQL with Linux kernel 2.2.14. If you are using this kernel you should upgrade to 2.2.19 (or newer) or to a 2.4 kernel. If you have a multi-cpu box, then you should seriously consider using 2.4 as this will give you a significant speed boost.
The binary release is linked with -static, which means you do
not normally need to worry about which version of the system libraries you have.
You need not install LinuxThreads, either. A program linked with
-static is slightly bigger than a dynamically linked program but
also slightly faster (3-5%). One problem, however, is that you can't use
user-definable functions (UDFs) with a statically linked program. If you are
going to write or use UDF functions (this is something only for C or C++
programmers), you must compile MySQL yourself, using dynamic linking.
If you are using a libc-based system (instead of a
glibc2 system), you will probably get some problems with hostname
resolving and getpwnam() with the binary release. (This is because
glibc unfortunately depends on some external libraries to resolve
hostnames and getpwent(), even when compiled with
-static). In this case you probably get the following error message
when you run mysql_install_db:
Sorry, the host 'xxxx' could not be looked up
or the following error when you try to run mysqld with the
--user option:
getpwnam: No such file or directory
You can solve this problem in one of the following ways:
tar.gz
distribution) and install this instead.
mysql_install_db --force; this will not execute the
resolveip test in mysql_install_db. The downside is
that you can't use host names in the grant tables; you must use IP numbers
instead (except for localhost). If you are using an old MySQL
release that doesn't support --force, you have to remove the
resolveip test in mysql_install with an editor.
mysqld with su instead of using
--user. The Linux-Intel binary and RPM releases of MySQL are configured for the highest possible speed. We are always trying to use the fastest stable compiler available.
MySQL Perl support requires Version Perl 5.004_03 or newer.
On some Linux 2.2 versions, you may get the error Resource temporarily
unavailable when you do a lot of new connections to a mysqld
server over TCP/IP.
The problem is that Linux has a delay between when you close a TCP/IP socket and until this is actually freed by the system. As there is only room for a finite number of TCP/IP slots, you will get the above error if you try to do too many new TCP/IP connections during a small time, like when you run the MySQL `test-connect' benchmark over TCP/IP.
We have mailed about this problem a couple of times to different Linux mailing lists but have never been able to resolve this properly.
The only known 'fix' to this problem is to use persistent connections in your
clients or use sockets, if you are running the database server and clients on
the same machine. We hope that the Linux 2.4 kernel will fix this
problem in the future.
MySQL requires libc Version 5.4.12 or newer. It's known to work
with libc 5.4.46. glibc Version 2.0.6 and later should
also work. There have been some problems with the glibc RPMs from
RedHat, so if you have problems, check whether there are any updates! The
glibc 2.0.7-19 and 2.0.7-29 RPMs are known to work.
If you are using gcc 3.0 and above to compile MySQL, you must install the
libstdc++v3 library before compiling MySQL; if you don't do this
you will get an error about a missing __cxa_pure_virtual symbol
during linking!
On some older Linux distributions, configure may produce an
error like this:
Syntax error in sched.h. Change _P to __P in the /usr/include/sched.h file. See the Installation chapter in the Reference Manual.
Just do what the error message says and add an extra underscore to the
_P macro that has only one underscore, then try again.
You may get some warnings when compiling; those shown here can be ignored:
mysqld.cc -o objs-thread/mysqld.o mysqld.cc: In function `void init_signals()': mysqld.cc:315: warning: assignment of negative value `-1' to `long unsigned int' mysqld.cc: In function `void * signal_hand(void *)': mysqld.cc:346: warning: assignment of negative value `-1' to `long unsigned int'
In Debian GNU/Linux, if you want MySQL to start automatically when the system boots, do the following:
shell> cp support-files/mysql.server /etc/init.d/mysql.server shell> /usr/sbin/update-rc.d mysql.server defaults 99
mysql.server can be found in the `share/mysql'
directory under the MySQL installation directory or in the
`support-files' directory of the MySQL source tree.
If mysqld always core dumps when it starts up, the problem may
be that you have an old `/lib/libc.a'. Try renaming it, then remove
`sql/mysqld' and do a new make install and try again. This
problem has been reported on some Slackware installations.
If you get the following error when linking mysqld, it means
that your `libg++.a' is not installed correctly:
/usr/lib/libc.a(putc.o): In function `_IO_putc': putc.o(.text+0x0): multiple definition of `_IO_putc'
You can avoid using `libg++.a' by running configure
like this:
shell> CXX=gcc ./configure
In some implementations, readdir_r() is broken. The symptom is
that SHOW DATABASES always returns an empty set. This can be fixed
by removing HAVE_READDIR_R from `config.h' after
configuring and before compiling.
Some problems will require patching your Linux installation. The patch can be
found at http://www.mysql.com/Downloads/patches/Linux-sparc-2.0.30.diff.
This patch is against the Linux distribution `sparclinux-2.0.30.tar.gz'
that is available at vger.rutgers.edu (a version of Linux that was
never merged with the official 2.0.30). You must also install LinuxThreads
Version 0.6 or newer.
MySQL Version 3.23.12 is the first MySQL version that is tested on Linux-Alpha. If you plan to use MySQL on Linux-Alpha, you should ensure that you have this version or newer.
We have tested MySQL on Alpha with our benchmarks and test suite, and it appears to work nicely. The main thing we haven't yet had time to test is how things works with many concurrent users.
When we compiled the standard MySQL binary we are using SuSE 6.4, kernel 2.2.13-SMP, Compaq C compiler (V6.2-504) and Compaq C++ compiler (V6.3-005) on a Comaq DS20 machine with an Alpha EV6 processor.
You can find the above compilers at http://www.support.compaq.com/alpha-tools/). By using these compilers, instead of gcc, we get about 9-14 % better performance with MySQL.
Note that the configure line optimised the binary for the current CPU; this means you can only use our binary if you have an Alpha EV6 processor. We also compile statically to avoid library problems.
CC=ccc CFLAGS="-fast" CXX=cxx CXXFLAGS="-fast -noexceptions -nortti" \ ./configure --prefix=/usr/local/mysql --disable-shared \ --with-extra-charsets=complex --enable-thread-safe-client \ --with-mysqld-ldflags=-non_shared --with-client-ldflags=-non_shared
If you want to use egcs the following configure line worked for us:
CFLAGS="-O3 -fomit-frame-pointer" CXX=gcc \ CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors \ -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \ --disable-shared
Some known problems when running MySQL on Linux-Alpha:
gdb
4.18. You should download and use gdb 5.1 instead!
mysqld statically when using
gcc, the resulting image will core dump at start. In other words,
don't use --with-mysqld-ldflags=-all-static with
gcc. MySQL should work on MkLinux with the newest glibc package
(tested with glibc 2.0.7).
To get MySQL to work on Qube2, (Linux Mips), you need the newest
glibc libraries (glibc-2.0.7-29C2 is known to work).
You must also use the egcs C++ compiler (egcs-1.0.2-9,
gcc 2.95.2 or newer).
To get MySQL to compile on Linux IA64, we use the following compile line:
Using gcc-2.96:
CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc \ CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \ -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \ "--with-comment=Official MySQL binary" --with-extra-charsets=complex
On IA64 the MySQL client binaries are using shared libraries. This means that
if you install our binary distribution in some other place than
`/usr/local/mysql' you need to either modify `/etc/ld.so.conf'
or add the path to the directory where you have `libmysqlclient.so' to
the LD_LIBRARY_PATH environment variable.
See section A.3.1 Problems When Linking with the MySQL Client Library.
This section describes using MySQL on Windows. This information is also provided in the `README' file that comes with the MySQL Windows distribution. See section 2.1.2 Installing MySQL on Windows.
MySQL uses TCP/IP to connect a client to a server. (This will allow any machine on your network to connect to your MySQL server.) Because of this, you must install TCP/IP on your machine before starting MySQL. You can find TCP/IP on your Windows CD-ROM.
Note that if you are using an old Windows 95 release (for example OSR2), it's likely that you have an old Winsock package; MySQL requires Winsock 2! You can get the newest Winsock from http://www.microsoft.com/. Windows 98 has the new Winsock 2 library, so the above doesn't apply there.
To start the mysqld server, you should start an MS-DOS window
and type:
C:\> C:\mysql\bin\mysqld
This will start mysqld in the background without a window.
You can kill the MySQL server by executing:
C:\> C:\mysql\bin\mysqladmin -u root shutdown
This calls the MySQL administation utility as user `root', which is the default Administrator in the MySQL grant system. Please note that the MySQL grant system is wholly independent from any login users under Windows.
Note that Windows 95/98/Me don't support creation of named pipes. So on those
platforms, you can only use named pipes to connect to a remote MySQL server
running on a Windows NT/2000/XP server host. (The MySQL server must also support
named pipes, of course. For example, using mysqld-opt under
NT/2000/XP will not allow named pipe connections. You should use either
mysqld-nt or mysqld-max-nt.)
If mysqld doesn't start, please check the
`\mysql\data\mysql.err' file to see if the server wrote any message
there to indicate the cause of the problem. You can also try to start the server
with mysqld --standalone; in this case, you may get some useful
information on the screen that may help solve the problem.
The last option is to start mysqld with --standalone
--debug. In this case mysqld will write a log file
`C:\mysqld.trace' that should contain the reason why
mysqld doesn't start. See section E.1.2
Creating Trace Files.
Use mysqld --help to display all the options that
mysqld understands!
To get MySQL to work with TCP/IP on Windows NT 4, you must install service pack 3 (or newer)!
Normally you should install MySQL as a service on Windows NT/2000/XP. In case the server was already running, first stop it using the following command:
C:\mysql\bin> mysqladmin -u root shutdown
This calls the MySQL administation utility as user `root', which
is the default Administrator in the MySQL grant system. Please note
that the MySQL grant system is wholly independent from any login users under
Windows.
Now install the server service:
C:\mysql\bin> mysqld-max-nt --install
If any options are required, they must be specified as ``Start
parameters'' in the Windows Services utility before you
start the MySQL service.
The Services utility (Windows Service Control
Manager) can be found in the Windows Control Panel (under
Administrative Tools on Windows 2000). It is advisable to close the
Services utility while performing the --install or
--remove operations, this prevents some odd errors.
For information about which server binary to run, see section 2.1.2.2 Preparing the Windows MySQL Environment.
Please note that from MySQL version 3.23.44, you have the choice of set up
the service as Manual instead (if you don't wish the service to be
started automatically during the boot process):
C:\mysql\bin> mysqld-max-nt --install-manual
The service is installed with the name MySQL. Once installed, it
can be immediately started from the Services utility, or by using
the command NET START MySQL.
Once running, mysqld-max-nt can be stopped using
mysqladmin, from the Services utility or by using the command
NET STOP MySQL.
When running as a service, the operating system will automatically stop the
MySQL service on computer shutdown. In MySQL versions < 3.23.47, Windows only
waited for a few seconds for the shutdown to complete, and killed the database
server process if the time limit was exceeded (potentially causing problems).
For instance, at the next startup the InnoDB table handler had to
do crash recovery. Starting from MySQL version 3.23.48, the Windows will wait
longer for the MySQL server shutdown to complete. If you notice this is not
enough for your intallation, it is safest to run the MySQL server not as a
service, but from the Command prompt, and shut it down with mysqladmin
shutdown.
There is a problem that Windows NT (but not Windows 2000/XP) by default only
waits 20 seconds for a service to shut down, and after that kills the service
process. You can increase this default by opening the Registry Editor
`\winnt\system32\regedt32.exe' and editing the value of
WaitToKillServiceTimeout at
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control' in the Registry
tree. Specify the new larger value in milliseconds, for example 120000 to have
Windows NT wait upto 120 seconds.
Please note that when run as a service, mysqld-max-nt has no
access to a console and so no messages can be seen. Errors can be checked in
`c:\mysql\data\mysql.err'.
If you have problems installing mysqld-max-nt as a service, try
starting it with the full path:
C:\> C:\mysql\bin\mysqld-max-nt --install
If this doesn't work, you can get mysqld-max-nt to start
properly by fixing the path in the registry!
If you don't want to start mysqld-max-nt as a service, you can
start it as follows:
C:\> C:\mysql\bin\mysqld-max-nt --standalone
or
C:\> C:\mysql\bin\mysqld --standalone --debug
The last method gives you a debug trace in `C:\mysqld.trace'. See section E.1.2 Creating Trace Files.
MySQL supports TCP/IP on all Windows platforms and named pipes on NT/2000/XP. The default is to use named pipes for local connections on NT/2000/XP and TCP/IP for all other cases if the client has TCP/IP installed. The host name specifies which protocol is used:
| Host name | Protocol |
| NULL (none) | On NT/2000/XP, try named pipes first; if that doesn't work, use TCP/IP. On 9x/Me, TCP/IP is used. |
| . | Named pipes |
| localhost | TCP/IP to current host |
| hostname | TCP/IP |
You can force a MySQL client to use named pipes by specifying the
--pipe option or by specifying . as the host name. Use
the --socket option to specify the name of the pipe.
Note that starting from 3.23.50, named pipes are only enabled if mysqld is
started with --enable-named-pipe. This is because some users have
experienced problems shutting down the MySQL server when one uses named pipes.
You can test whether MySQL is working by executing the following commands:
C:\> C:\mysql\bin\mysqlshow C:\> C:\mysql\bin\mysqlshow -u root mysql C:\> C:\mysql\bin\mysqladmin version status proc C:\> C:\mysql\bin\mysql test
If mysqld is slow to answer to connections on Windows 9x/Me,
there is probably a problem with your DNS. In this case, start
mysqld with --skip-name-resolve and use only
localhost and IP numbers in the MySQL grant tables. You can also
avoid DNS when connecting to a mysqld-nt MySQL server running on
NT/2000/XP by using the --pipe argument to specify use of named
pipes. This works for most MySQL clients.
There are two versions of the MySQL command-line tool:
| Binary | Description |
mysql |
Compiled on native Windows, which offers very limited text editing capabilities. |
mysqlc |
Compiled with the Cygnus GNU compiler and libraries, which offers
readline editing. |
If you want to use mysqlc.exe, you must copy
`C:\mysql\lib\cygwinb19.dll' to your Windows system directory
(`\windows\system' or similar place).
The default privileges on Windows give all local users full privileges to all
databases without specifying a password. To make MySQL more secure, you should
set a password for all users and remove the row in the mysql.user
table that has Host='localhost' and User=''.
You should also add a password for the root user. The following
example starts by removing the anonymous user that can be used by anyone to
access the test database, then sets a root user
password:
C:\> C:\mysql\bin\mysql mysql mysql> DELETE FROM user WHERE Host='localhost' AND User=''; mysql> QUIT C:\> C:\mysql\bin\mysqladmin reload C:\> C:\mysql\bin\mysqladmin -u root password your_password
After you've set the password, if you want to take down the
mysqld server, you can do so using this command:
C:\> mysqladmin --user=root --password=your_password shutdown
If you are using the old shareware version of MySQL Version 3.21 under
Windows, the above command will fail with an error: parse error near 'SET
OPTION password'. The solution for this is to download and upgrade to the
latest MySQL version, which is now freely available.
With the current MySQL versions you can easily add new users and change
privileges with GRANT and REVOKE commands. See section
4.3.1
GRANT and REVOKE Syntax.
Here is a note about how to connect to get a secure connection to remote MySQL server with SSH (by David Carlson dcarlson@mplcomm.com):
SecureCRT from http://www.vandyke.com/. Another option is
f-secure from http://www.f-secure.com/. You can also
find some free ones on Google at http://directory.google.com/Top/Computers/Security/Products_and_Tools/Cryptography/SSH/Clients/Windows/.
Host_Name =
yourmysqlserver_URL_or_IP. Set userid=your_userid to log
in to your server (probably not the same as your MySQL login/password.
local_port:
3306, remote_host: yourmysqlservername_or_ip,
remote_port: 3306 ) or a local forward (Set port:
3306, host: localhost, remote port: 3306).
localhost for the MySQL
host server@-not yourmysqlservername. You should now have an ODBC connection to MySQL, encrypted using SSH.
Beginning with MySQL Version 3.23.16, the mysqld-max and
mysql-max-nt servers in the MySQL distribution are compiled with
the -DUSE_SYMDIR option. This allows you to put a database on
different disk by adding a symbolic link to it (in a manner similar to the way
that symbolic links work on Unix).
On Windows, you make a symbolic link to a database by creating a file that contains the path to the destination directory and saving this in the `mysql_data' directory under the filename `database.sym'. Note that the symbolic link will be used only if the directory `mysql_data_dir\database' doesn't exist.
For example, if the MySQL data directory is `C:\mysql\data' and you
want to have database foo located at `D:\data\foo', you
should create the file `C:\mysql\data\foo.sym' that contains the text
D:\data\foo\. After that, all tables created in the database
foo will be created in `D:\data\foo'.
Note that because of the speed penalty you get when opening every table, we have not enabled this by default even if you have compiled MySQL with support for this. To enable symlinks you should put in your `my.cnf' or `my.ini' file the following entry:
[mysqld] use-symbolic-links
In MySQL 4.0 we will enable symlinks by default. Then you should instead use
the skip-symlink option if you want to disable this.
In your source files, you should include `windows.h' before you include `mysql.h':
#if defined(_WIN32) || defined(_WIN64) #include <windows.h> #endif #include <mysql.h>
You can either link your code with the dynamic `libmysql.lib' library, which is just a wrapper to load in `libmysql.dll' on demand, or link with the static `mysqlclient.lib' library.
Note that as the mysqlclient libraries are compiled as threaded libraries, you should also compile your code to be multi-threaded!
MySQL-Windows has by now proven itself to be very stable. This version of MySQL has the same features as the corresponding Unix version with the following exceptions:
mysqld for an extended time on Windows 95 if your server handles
many connections! Other versions of Windows don't suffer from this bug.
pread() and pwrite() calls
to be able to mix INSERT and SELECT. Currently we
use mutexes to emulate pread()/pwrite(). We will, in
the long run, replace the file level interface with a virtual interface so
that we can use the readfile()/writefile() interface
on NT/2000/XP to get more speed. The current implementation limits the number
of open files MySQL can use to 1024, which means that you will not be able to
run as many concurrent threads on NT/2000/XP as on Unix.
mysqladmin kill will not work on a sleeping connection.
mysqladmin shutdown can't abort as long as there are
sleeping connections. DROP DATABASE
mysqladmin shutdown.
LOAD DATA INFILE or SELECT ... INTO OUTFILE, you
must double the `\' character: mysql> LOAD DATA INFILE "C:\\tmp\\skr.txt" INTO TABLE skr; mysql> SELECT * INTO OUTFILE 'C:\\tmp\\skr.txt' FROM skr;Alternatively, use Unix style filenames with `/' characters:
mysql> LOAD DATA INFILE "C:/tmp/skr.txt" INTO TABLE skr; mysql> SELECT * INTO OUTFILE 'C:/tmp/skr.txt' FROM skr;
Can't open named pipe error
error 2017: can't open named pipe to host: . pipe...This is because the release version of MySQL uses named pipes on NT by default. You can avoid this error by using the
--host=localhost option to the new MySQL clients or create an
option file `C:\my.cnf' that contains the following information: [client] host = localhostStarting from 3.23.50, named pipes are only enabled if mysqld is started with
--enable-named-pipe.
Access denied for user error
Access denied for user: 'some-user@unknown' to
database 'mysql' when accessing a MySQL server on the same machine,
this means that MySQL can't resolve your host name properly. To fix this, you
should create a file `\windows\hosts' with the following information:
127.0.0.1 localhost
ALTER TABLE
ALTER TABLE statement, the table
is locked from usage by other threads. This has to do with the fact that on
Windows, you can't delete a file that is in use by another threads. (In the
future, we may find some way to work around this problem.)
DROP TABLE on a table that is in use by a MERGE
table will not work on Windows because MERGE handler does the
table mapping hidden from the upper layer of MySQL. Because Windows doesn't
allow you to drop files that are open, you first must flush all
MERGE tables (with FLUSH TABLES) or drop the
MERGE table before dropping the table. We will fix this at the
same time we introduce VIEWs.
DATA DIRECTORY and INDEX DIRECTORY directives in
CREATE TABLE is ignored on Windows, because Windows doesn't
support symbolic links. Here are some open issues for anyone who might want to help us with the Windows release:
MYSQL.DLL server. This should include
everything in a standard MySQL server, except thread creation. This will make
MySQL much easier to use in applications that don't need a true client/server
and don't need to access the server from other hosts.
mysqld as a service with
--install (on NT) it would be nice if you could also add default
options on the command-line. For the moment, the workaround is to list the
parameters in the `C:\my.cnf' file instead.
mysqld from the task
manager. For the moment, you must use mysqladmin shutdown.
readline to Windows for use in the mysql
command-line tool.
mysql,
mysqlshow, mysqladmin, and mysqldump)
would be nice.
mysqladmin kill on Windows.
mysqld always starts in the "C" locale and not in the default
locale. We would like to have mysqld use the current locale for
the sort order.
Other Windows-specific issues are described in the `README' file that comes with the MySQL-Windows distribution.
On Solaris, you may run into trouble even before you get the MySQL
distribution unpacked! Solaris tar can't handle long file names, so
you may see an error like this when you unpack MySQL:
x mysql-3.22.12-beta/bench/Results/ATIS-mysql_odbc-NT_4.0-cmp-db2,\ informix,ms-sql,mysql,oracle,solid,sybase, 0 bytes, 0 tape blocks tar: directory checksum error
In this case, you must use GNU tar (gtar) to unpack
the distribution. You can find a precompiled copy for Solaris at http://www.mysql.com/Downloads/.
Sun native threads work only on Solaris 2.5 and higher. For Version 2.4 and earlier, MySQL will automatically use MIT-pthreads. See section 2.3.6 MIT-pthreads Notes.
If you get the following error from configure:
checking for restartable system calls... configure: error can not run test programs while cross compiling
This means that you have something wrong with your compiler installation! In this case you should upgrade your compiler to a newer version. You may also be able to solve this problem by inserting the following row into the `config.cache' file:
ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls='no'}
If you are using Solaris on a SPARC, the recommended compiler is
gcc 2.95.2. You can find this at http://gcc.gnu.org/. Note that egcs
1.1.1 and gcc 2.8.1 don't work reliably on SPARC!
The recommended configure line when using gcc
2.95.2 is:
CC=gcc CFLAGS="-O3" \ CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory --enable-assembler
If you have an UltraSPARC, you can get 4 % more performance by adding "-mcpu=v8 -Wa,-xarch=v8plusa" to CFLAGS and CXXFLAGS.
If you have Sun Workshop (Fortre) 5.3 (or newer) compiler, you can run
configure like this:
CC=cc CFLAGS="-Xa -fast -xO4 -native -xstrconst -mt" \ CXX=CC CXXFLAGS="-noex -xO4 -mt" \ ./configure --prefix=/usr/local/mysql --enable-assembler
In the MySQL benchmarks, we got a 6 % speedup on an UltraSPARC when using Sun Workshop 5.3 compared to using gcc with -mcpu flags.
If you get a problem with fdatasync or sched_yield,
you can fix this by adding LIBS=-lrt to the configure line
The following paragraph is only relevant for older compilers than WorkShop 5.3:
You may also have to edit the configure script to change this
line:
#if !defined(__STDC__) || __STDC__ != 1
to this:
#if !defined(__STDC__)
If you turn on __STDC__ with the -Xc option, the
Sun compiler can't compile with the Solaris `pthread.h' header file.
This is a Sun bug (broken compiler or broken include file).
If mysqld issues the error message shown here when you run it,
you have tried to compile MySQL with the Sun compiler without enabling the
multi-thread option (-mt):
libc internal error: _rmutex_unlock: rmutex not held
Add -mt to CFLAGS and CXXFLAGS and try
again.
If you are using the SFW version of gcc (which comes with Solaris 8), you
must add `/opt/sfw/lib' to the environment variable
LD_LIBRARY_PATH before running configure.
If you are using the gcc available from sunfreeware.com, you may
have many problems. You should recompile gcc and GNU binutils on the machine you
will be running them from to avoid any problems.
If you get the following error when compiling MySQL with gcc, it
means that your gcc is not configured for your version of Solaris:
shell> gcc -O3 -g -O2 -DDBUG_OFF -o thr_alarm ... ./thr_alarm.c: In function `signal_hand': ./thr_alarm.c:556: too many arguments to function `sigwait'
The proper thing to do in this case is to get the newest version of
gcc and compile it with your current gcc compiler! At
least for Solaris 2.5, almost all binary versions of gcc have old,
unusable include files that will break all programs that use threads (and
possibly other programs)!
Solaris doesn't provide static versions of all system libraries
(libpthreads and libdl), so you can't compile MySQL
with --static. If you try to do so, you will get the error:
ld: fatal: library -ldl: not found or undefined reference to `dlopen' or cannot find -lrt
If too many processes try to connect very rapidly to mysqld, you
will see this error in the MySQL log:
Error in accept: Protocol error
You might try starting the server with the --set-variable
back_log=50 option as a workaround for this. See section 4.1.1
mysqld Command-line Options.
If you are linking your own MySQL client, you might get the following error when you try to execute it:
ld.so.1: ./my: fatal: libmysqlclient.so.#: open failed: No such file or directory
The problem can be avoided by one of the following methods:
-Lpath):
-Wl,r/full-path-to-libmysqlclient.so.
LD_RUN_PATH environment variable before running
your client. If you have problems with configure trying to link with -lz and
you don't have zlib installed, you have two options:
--with-named-z-libs=no. If you are using gcc and have problems with loading UDF
functions into MySQL, try adding -lgcc to the link line for the
UDF function.
If you would like MySQL to start automatically, you can copy `support-files/mysql.server' to `/etc/init.d' and create a symbolic link to it named `/etc/rc3.d/S99mysql.server'.
As Solaris doesn't support core files for setuid() applications,
you can't get a core file from mysqld if you are using the
--user option.
You can normally use a Solaris 2.6 binary on Solaris 2.7 and 2.8. Most of the Solaris 2.6 issues also apply for Solaris 2.7 and 2.8.
Note that MySQL Version 3.23.4 and above should be able to autodetect new versions of Solaris and enable workarounds for the following problems!
Solaris 2.7 / 2.8 has some bugs in the include files. You may see the
following error when you use gcc:
/usr/include/widec.h:42: warning: `getwc' redefined /usr/include/wchar.h:326: warning: this is the location of the previous definition
If this occurs, you can do the following to fix the problem:
Copy /usr/include/widec.h to
.../lib/gcc-lib/os/gcc-version/include and change line 41 from:
#if !defined(lint) && !defined(__lint) to #if !defined(lint) && !defined(__lint) && !defined(getwc)
Alternatively, you can edit `/usr/include/widec.h' directly. Either
way, after you make the fix, you should remove `config.cache' and run
configure again!
If you get errors like this when you run make, it's because
configure didn't detect the `curses.h' file (probably
because of the error in `/usr/include/widec.h'):
In file included from mysql.cc:50: /usr/include/term.h:1060: syntax error before `,' /usr/include/term.h:1081: syntax error before `;'
The solution to this is to do one of the following:
CFLAGS=-DHAVE_CURSES_H CXXFLAGS=-DHAVE_CURSES_H
./configure.
#define HAVE_TERM line from `config.h'
file and run make again. If you get a problem that your linker can't find -lz when
linking your client program, the problem is probably that your
`libz.so' file is installed in `/usr/local/lib'. You can fix
this by one of the following methods:
LD_LIBRARY_PATH.
--with-named-z-libs=no option.
On Solaris 2.8 on x86, mysqld will core dump if you run 'strip'
in.
If you are using gcc or egcs on Solaris x86 and you
experience problems with core dumps under load, you should use the following
configure command:
CC=gcc CFLAGS="-O3 -fomit-frame-pointer -DHAVE_CURSES_H" \ CXX=gcc \ CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors -fno-exceptions \ -fno-rtti -DHAVE_CURSES_H" \ ./configure --prefix=/usr/local/mysql
This will avoid problems with the libstdc++ library and with C++
exceptions.
If this doesn't help, you should compile a debug version and run it with a
trace file or under gdb. See section E.1.3
Debugging mysqld under gdb.
This section provides information for the various BSD flavours, as well as specific versions within those.
FreeBSD 3.x is recommended for running MySQL since the thread package is much more integrated.
The easiest and therefor the preferred way to install is to use the mysql-server and mysql-client ports available on http://www.freebsd.org/.
Using these gives you:
It is recommended you use MIT-pthreads on FreeBSD 2.x and native threads on
Versions 3 and up. It is possible to run with native threads on some late 2.2.x
versions but you may encounter problems shutting down mysqld.
The MySQL `Makefile's require GNU make (gmake) to work.
If you want to compile MySQL you need to install GNU make first.
Be sure to have your name resolver setup correct. Otherwise, you may
experience resolver delays or failures when connecting to mysqld.
Make sure that the localhost entry in the `/etc/hosts'
file is correct (otherwise, you will have problems connecting to the database).
The `/etc/hosts' file should start with a line:
127.0.0.1 localhost localhost.your.domain
The recommended way to compile and install MySQL on FreeBSD with gcc (2.95.2 and up) is:
CC=gcc CFLAGS="-O2 -fno-strength-reduce" \ CXX=gcc CXXFLAGS="-O2 -fno-rtti -fno-exceptions -felide-constructors \ -fno-strength-reduce" \ ./configure --prefix=/usr/local/mysql --enable-assembler gmake gmake install ./scripts/mysql_install_db cd /usr/local/mysql ./bin/mysqld_safe &
If you notice that configure will use MIT-pthreads, you should
read the MIT-pthreads notes. See section 2.3.6
MIT-pthreads Notes.
If you get an error from make install that it can't find
`/usr/include/pthreads', configure didn't detect that you
need MIT-pthreads. This is fixed by executing these commands:
shell> rm config.cache shell> ./configure --with-mit-threads
FreeBSD is also known to have a very low default file handle limit. See
section A.2.16
File Not Found. Uncomment the ulimit -n section in safe_mysqld or raise the
limits for the mysqld user in /etc/login.conf (and rebuild it with
cap_mkdb /etc/login.conf). Also be sure you set the appropriate class for this
user in the password file if you are not using the default (use: chpass
mysqld-user-name). See section 4.7.2
safe_mysqld, The Wrapper Around mysqld.
If you have a lot of memory you should consider rebuilding the kernel to
allow MySQL to take more than 512M of RAM. Take a look at option
MAXDSIZ in the LINT config file for more info.
If you get problems with the current date in MySQL, setting the
TZ variable will probably help. See section F
Environment Variables.
To get a secure and stable system you should only use FreeBSD kernels that
are marked -RELEASE.
To compile on NetBSD you need GNU make. Otherwise, the compile
will crash when make tries to run lint on C++ files.
On OpenBSD Version 2.5, you can compile MySQL with native threads with the following options:
CFLAGS=-pthread CXXFLAGS=-pthread ./configure --with-mit-threads=no
Our users have reported that OpenBSD 2.8 has a threading bug which causes problems with MySQL. The OpenBSD Developers have fixed the problem, but as of January 25th, 2001, it's only available in the ``-current'' branch. The symptoms of this threading bug are: slow response, high load, high CPU usage, and crashes.
If you get an error like Error in accept:: Bad file descriptor
or error 9 when trying to open tables or directories, the problem is probably
that you haven't allocated enough file descriptors for MySQL.
In this case try starting safe_mysqld as root with the following
options:
--user=mysql --open-files-limit=2048
If you get the following error when compiling MySQL, your ulimit
value for virtual memory is too low:
item_func.h: In method `Item_func_ge::Item_func_ge(const Item_func_ge &)': item_func.h:28: virtual memory exhausted make[2]: *** [item_func.o] Error 1
Try using ulimit -v 80000 and run make again. If
this doesn't work and you are using bash, try switching to
csh or sh; some BSDI users have reported problems with
bash and ulimit.
If you are using gcc, you may also use have to use the
--with-low-memory flag for configure to be able to
compile `sql_yacc.cc'.
If you get problems with the current date in MySQL, setting the
TZ variable will probably help. See section F
Environment Variables.
Upgrade to BSD/OS Version 3.1. If that is not possible, install BSDIpatch M300-038.
Use the following command when configuring MySQL:
shell> env CXX=shlicc++ CC=shlicc2 \
./configure \
--prefix=/usr/local/mysql \
--localstatedir=/var/mysql \
--without-perl \
--with-unix-socket-path=/var/mysql/mysql.sock
The following is also known to work:
shell> env CC=gcc CXX=gcc CXXFLAGS=-O3 \
./configure \
--prefix=/usr/local/mysql \
--with-unix-socket-path=/var/mysql/mysql.sock
You can change the directory locations if you wish, or just use the defaults by not specifying any locations.
If you have problems with performance under heavy load, try using the
--skip-thread-priority option to mysqld! This will run
all threads with the same priority; on BSDI Version 3.1, this gives better
performance (at least until BSDI fixes their thread scheduler).
If you get the error virtual memory exhausted while compiling,
you should try using ulimit -v 80000 and run make
again. If this doesn't work and you are using bash, try switching
to csh or sh; some BSDI users have reported problems
with bash and ulimit.
BSDI Version 4.x has some thread-related bugs. If you want to use MySQL on this, you should install all thread-related patches. At least M400-023 should be installed.
On some BSDI Version 4.x systems, you may get problems with shared libraries.
The symptom is that you can't execute any client programs, for example,
mysqladmin. In this case you need to reconfigure not to use shared
libraries with the --disable-shared option to configure.
Some customers have had problems on BSDI 4.0.1 that the mysqld
binary after a while can't open tables. This is because some library/system
related bug causes mysqld to change current directory without
asking for this!
The fix is to either upgrade to 3.23.34 or after running
configure remove the line #define HAVE_REALPATH from
config.h before running make.
Note that the above means that you can't symbolic link a database directories to another database directory or symbolic link a table to another database on BSDI! (Making a symbolic link to another disk is okay).
MySQL should work without any problems on Mac OS X Public Beta (Darwin). You don't need the pthread patches for this OS!
Before trying to configure MySQL on Mac OS X server you must first install the pthread package from http://www.prnet.de/RegEx/mysql.html.
Our binary for Mac OS X is compiled on Rhapsody 5.5 with the following configure line:
CC=gcc CFLAGS="-O2 -fomit-frame-pointer" CXX=gcc CXXFLAGS="-O2 \ -fomit-frame-pointer" ./configure --prefix=/usr/local/mysql \ "--with-comment=Official MySQL binary" --with-extra-charsets=complex \ --disable-shared
You might want to also add aliases to your shell's resource file to access
mysql and mysqladmin from the command-line:
alias mysql '/usr/local/mysql/bin/mysql' alias mysqladmin '/usr/local/mysql/bin/mysqladmin'
Some of the binary distributions of MySQL for HP-UX is distributed as an HP depot file and as a tar file. To use the depot file you must be running at least HP-UX 10.x to have access to HP's software depot tools.
The HP version of MySQL was compiled on an HP 9000/8xx server under HP-UX 10.20, and uses MIT-pthreads. It is known to work well under this configuration. MySQL Version 3.22.26 and newer can also be built with HP's native thread package.
Other configurations that may work:
The following configurations almost definitely won't work:
To install the distribution, use one of the commands here, where
/path/to/depot is the full pathname of the depot file:
shell> /usr/sbin/swinstall -s /path/to/depot mysql.full
shell> /usr/sbin/swinstall -s /path/to/depot mysql.server
shell> /usr/sbin/swinstall -s /path/to/depot mysql.client
shell> /usr/sbin/swinstall -s /path/to/depot mysql.developer
The depot places binaries and libraries in `/opt/mysql' and data in
`/var/opt/mysql'. The depot also creates the appropriate entries in
`/etc/init.d' and `/etc/rc2.d' to start the server
automatically at boot time. Obviously, this entails being root to
install.
To install the HP-UX tar.gz distribution, you must have a copy of GNU
tar.
There are a couple of small problems when compiling MySQL on HP-UX. We
recommend that you use gcc instead of the HP-UX native compiler,
because gcc produces better code!
We recommend using gcc 2.95 on HP-UX. Don't use high optimisation flags (like -O6) as this may not be safe on HP-UX.
Note that MIT-pthreads can't be compiled with the HP-UX compiler because it
can't compile .S (assembler) files.
The following configure line should work:
CFLAGS="-DHPUX -I/opt/dce/include -fpic" \ CXXFLAGS="-DHPUX -I/opt/dce/include -felide-constructors -fno-exceptions \ -fno-rtti" CXX=gcc ./configure --with-pthread \ --with-named-thread-libs='-ldce' --prefix=/usr/local/mysql --disable-shared
If you are compiling gcc 2.95 yourself, you should NOT link it
with the DCE libraries (libdce.a or libcma.a) if you
want to compile MySQL with MIT-pthreads. If you mix the DCE and MIT-pthreads
packages you will get a mysqld to which you cannot connect. Remove
the DCE libraries while you compile gcc 2.95!
For HP-UX Version 11.x we recommend MySQL Version 3.23.15 or later.
Because of some critical bugs in the standard HP-UX libraries, you should install the following patches before trying to run MySQL on HP-UX 11.0:
PHKL_22840 Streams cumulative PHNE_22397 ARPA cumulative
This will solve the problem of getting EWOULDBLOCK from
recv() and EBADF from accept() in
threaded applications.
If you are using gcc 2.95.1 on an unpatched HP-UX 11.x system,
you will get the error:
In file included from /usr/include/unistd.h:11,
from ../include/global.h:125,
from mysql_priv.h:15,
from item.cc:19:
/usr/include/sys/unistd.h:184: declaration of C function ...
/usr/include/sys/pthread.h:440: previous declaration ...
In file included from item.h:306,
from mysql_priv.h:158,
from item.cc:19:
The problem is that HP-UX doesn't define pthreads_atfork()
consistently. It has conflicting prototypes in
`/usr/include/sys/unistd.h':184 and
`/usr/include/sys/pthread.h':440 (details below).
One solution is to copy `/usr/include/sys/unistd.h' into `mysql/include' and edit `unistd.h' and change it to match the definition in `pthread.h'. Here's the diff:
183,184c183,184 < extern int pthread_atfork(void (*prepare)(), void (*parent)(), < void (*child)()); --- > extern int pthread_atfork(void (*prepare)(void), void (*parent)(void), > void (*child)(void));
After this, the following configure line should work:
CFLAGS="-fomit-frame-pointer -O3 -fpic" CXX=gcc \ CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti -O3" \ ./configure --prefix=/usr/local/mysql --disable-shared
Here is some information that a HP-UX Version 11.x user sent us about compiling MySQL with HP-UX:x compiler:
Environment:
proper compilers.
setenv CC cc
setenv CXX aCC
flags
setenv CFLAGS -D_REENTRANT
setenv CXXFLAGS -D_REENTRANT
setenv CPPFLAGS -D_REENTRANT
% aCC -V
aCC: HP ANSI C++ B3910B X.03.14.06
% cc -V /tmp/empty.c
cpp.ansi: HP92453-01 A.11.02.00 HP C Preprocessor (ANSI)
ccom: HP92453-01 A.11.01.00 HP C Compiler
cc: "/tmp/empty.c", line 1: warning 501: Empty source file.
configuration:
./configure --with-pthread \
--prefix=/source-control/mysql \
--with-named-thread-libs=-lpthread \
--with-low-memory
added '#define _CTYPE_INCLUDED' to include/m_ctype.h. This
symbol is the one defined in HP's /usr/include/ctype.h:
/* Don't include std ctype.h when this is included */
#define _CTYPE_H
#define __CTYPE_INCLUDED
#define _CTYPE_INCLUDED
#define _CTYPE_USING /* Don't put names in global namespace. */
-D_REENTRANT to get the
compiler to recognise the prototype for localtime_r.
Alternatively I could have supplied the prototype for
localtime_r. But I wanted to catch other bugs without needing to
run into them. I wasn't sure where I needed it, so I added it to all flags.
If you get the following error from configure
checking for cc option to accept ANSI C... no configure: error: MySQL requires a ANSI C compiler (and a C++ compiler). Try gcc. See the Installation chapter in the Reference Manual.
Check that you don't have the path to the K&R compiler before the path to the HP-UX C and C++ compiler.
Automatic detection of xlC is missing from Autoconf, so a
configure command something like this is needed when compiling
MySQL (This example uses the IBM compiler):
export CC="xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 " export CXX="xlC_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192" export CFLAGS="-I /usr/local/include" export LDLFAGS="-L /usr/local/lib" export CPPFLAGS=$CFLAGS export CXXFLAGS=$CFLAGS ./configure --prefix=/usr/local \ --localstatedir=/var/mysql \ --sysconfdir=/etc/mysql \ --sbindir='/usr/local/bin' \ --libexecdir='/usr/local/bin' \ --enable-thread-safe-client \ --enable-large-files
Above are the options used to compile the MySQL distribution that can be found at http://www-frec.bull.com/.
If you change the -O3 to -O2 in the above configure
line, you must also remove the -qstrict option (this is a
limitation in the IBM C compiler).
If you are using gcc or egcs to compile MySQL, you
must use the -fno-exceptions flag, as the
exception handling in gcc/egcs is not thread-safe!
(This is tested with egcs 1.1.) There are also some known problems
with IBM's assembler, which may cause it to generate bad code when used with
gcc.
We recommend the following configure line with egcs
and gcc 2.95 on AIX:
CC="gcc -pipe -mcpu=power -Wa,-many" \ CXX="gcc -pipe -mcpu=power -Wa,-many" \ CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti" \ ./configure --prefix=/usr/local/mysql --with-low-memory
The -Wa,-many is necessary for the compile to be successful. IBM
is aware of this problem but is in to hurry to fix it because of the workaround
available. We don't know if the -fno-exceptions is required with
gcc 2.95, but as MySQL doesn't use exceptions and the above option
generates faster code, we recommend that you should always use this option with
egcs / gcc.
If you get a problem with assembler code try changing the -mcpu=xxx to match your CPU. Typically power2, power, or powerpc may need to be used, alternatively you might need to use 604 or 604e. I'm not positive but I would think using "power" would likely be safe most of the time, even on a power2 machine.
If you don't know what your CPU is then do a "uname -m", this will give you back a string that looks like "000514676700", with a format of xxyyyyyymmss where xx and ss are always 0's, yyyyyy is a unique system id and mm is the id of the CPU Planar. A chart of these values can be found at http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds5/uname.htm. This will give you a machine type and a machine model you can use to determine what type of CPU you have.
If you have problems with signals (MySQL dies unexpectedly under high load) you may have found an OS bug with threads and signals. In this case you can tell MySQL not to use signals by configuring with:
shell> CFLAGS=-DDONT_USE_THR_ALARM CXX=gcc \
CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti \
-DDONT_USE_THR_ALARM" \
./configure --prefix=/usr/local/mysql --with-debug --with-low-memory
This doesn't affect the performance of MySQL, but has the side effect that
you can't kill clients that are ``sleeping'' on a connection with
mysqladmin kill or mysqladmin shutdown. Instead, the
client will die when it issues its next command.
On some versions of AIX, linking with libbind.a makes
getservbyname core dump. This is an AIX bug and should be reported
to IBM.
For AIX 4.2.1 and gcc you have to do the following changes.
After configuring, edit `config.h' and `include/my_config.h' and change the line that says
#define HAVE_SNPRINTF 1
to
#undef HAVE_SNPRINTF
And finally, in `mysqld.cc' you need to add a prototype for initgoups.
#ifdef _AIX41 extern "C" int initgroups(const char *,int); #endif
On SunOS 4, MIT-pthreads is needed to compile MySQL, which in turn means you
will need GNU make.
Some SunOS 4 systems have problems with dynamic libraries and
libtool. You can use the following configure line to
avoid this problem:
shell> ./configure --disable-shared --with-mysqld-ldflags=-all-static
When compiling readline, you may get warnings about duplicate
defines. These may be ignored.
When compiling mysqld, there will be some implicit
declaration of function warnings. These may be ignored.
If you are using egcs 1.1.2 on Digital Unix, you should upgrade to gcc 2.95.2, as egcs on DEC has some serious bugs!
When compiling threaded programs under Digital Unix, the documentation
recommends using the -pthread option for cc and
cxx and the libraries -lmach -lexc (in addition to
-lpthread). You should run configure something like
this:
CC="cc -pthread" CXX="cxx -pthread -O" \ ./configure --with-named-thread-libs="-lpthread -lmach -lexc -lc"
When compiling mysqld, you may see a couple of warnings like
this:
mysqld.cc: In function void handle_connections()': mysqld.cc:626: passing long unsigned int *' as argument 3 of accept(int,sockadddr *, int *)'
You can safely ignore these warnings. They occur because
configure can detect only errors, not warnings.
If you start the server directly from the command-line, you may have problems
with it dying when you log out. (When you log out, your outstanding processes
receive a SIGHUP signal.) If so, try starting the server like this:
shell> nohup mysqld [options] &
nohup causes the command following it to ignore any
SIGHUP signal sent from the terminal. Alternatively, start the
server by running safe_mysqld, which invokes mysqld
using nohup for you. See section 4.7.2
safe_mysqld, The Wrapper Around mysqld.
If you get a problem when compiling mysys/get_opt.c, just remove the line #define _NO_PROTO from the start of that file!
If you are using Compac's CC compiler, the following configure line should work:
CC="cc -pthread" CFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host" CXX="cxx -pthread" CXXFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host \ -noexceptions -nortti" export CC CFLAGS CXX CXXFLAGS ./configure \ --prefix=/usr/local/mysql \ --with-low-memory \ --enable-large-files \ --enable-shared=yes \ --with-named-thread-libs="-lpthread -lmach -lexc -lc" gnumake
If you get a problem with libtool, when compiling with shared libraries as
above, when linking mysql, you should be able to get around this by
issuing:
cd mysql /bin/sh ../libtool --mode=link cxx -pthread -O3 -DDBUG_OFF \ -O4 -ansi_alias -ansi_args -fast -inline speed \ -speculate all \ -arch host -DUNDEF_HAVE_GETHOSTBYNAME_R \ -o mysql mysql.o readline.o sql_string.o completion_hash.o \ ../readline/libreadline.a -lcurses \ ../libmysql/.libs/libmysqlclient.so -lm cd .. gnumake gnumake install scripts/mysql_install_db
If you have problems compiling and have DEC CC and
gcc installed, try running configure like this:
CC=cc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql
If you get problems with the `c_asm.h' file, you can create and use a 'dummy' `c_asm.h' file with:
touch include/c_asm.h CC=gcc CFLAGS=-I./include \ CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql
Note that the following problems with the ld program can be
fixed by downloading the latest DEC (Compaq) patch kit from: http://ftp.support.compaq.com/public/unix/.
On OSF/1 V4.0D and compiler "DEC C V5.6-071 on Digital Unix V4.0 (Rev. 878)"
the compiler had some strange behavior (undefined asm symbols).
/bin/ld also appears to be broken (problems with _exit
undefined errors occuring while linking mysqld). On this
system, we have managed to compile MySQL with the following
configure line, after replacing /bin/ld with the
version from OSF 4.0C:
CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql
With the Digital compiler "C++ V6.1-029", the following should work:
CC=cc -pthread
CFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all \
-arch host
CXX=cxx -pthread
CXXFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all \
-arch host -noexceptions -nortti
export CC CFLAGS CXX CXXFLAGS
./configure --prefix=/usr/mysql/mysql --with-mysqld-ldflags=-all-static \
--disable-shared --with-named-thread-libs="-lmach -lexc -lc"
In some versions of OSF/1, the alloca() function is broken. Fix
this by removing the line in `config.h' that defines
'HAVE_ALLOCA'.
The alloca() function also may have an incorrect prototype in
/usr/include/alloca.h. This warning resulting from this can be
ignored.
configure will use the following thread libraries automatically:
--with-named-thread-libs="-lpthread -lmach -lexc -lc".
When using gcc, you can also try running configure
like this:
shell> CFLAGS=-D_PTHREAD_USE_D4 CXX=gcc CXXFLAGS=-O3 ./configure ...
If you have problems with signals (MySQL dies unexpectedly under high load), you may have found an OS bug with threads and signals. In this case you can tell MySQL not to use signals by configuring with:
shell> CFLAGS=-DDONT_USE_THR_ALARM \
CXXFLAGS=-DDONT_USE_THR_ALARM \
./configure ...
This doesn't affect the performance of MySQL, but has the side effect that
you can't kill clients that are ``sleeping'' on a connection with
mysqladmin kill or mysqladmin shutdown. Instead, the
client will die when it issues its next command.
With gcc 2.95.2, you will probably run into the following
compile error:
sql_acl.cc:1456: Internal compiler error in `scan_region', at except.c:2566 Please submit a full bug report.
To fix this you should change to the sql directory and do a
``cut and paste'' of the last gcc line, but change -O3
to -O0 (or add -O0 immediately after gcc
if you don't have any -O option on your compile line). After this
is done you can just change back to the top-level directly and run
make again.
If you are using Irix Version 6.5.3 or newer mysqld will only be
able to create threads if you run it as a user with CAP_SCHED_MGT
privileges (like root) or give the mysqld server this
privilege with the following shell command:
shell> chcap "CAP_SCHED_MGT+epi" /opt/mysql/libexec/mysqld
You may have to undefine some things in `config.h' after running
configure and before compiling.
In some Irix implementations, the alloca() function is broken.
If the mysqld server dies on some SELECT statements,
remove the lines from `config.h' that define HAVE_ALLOC
and HAVE_ALLOCA_H. If mysqladmin create doesn't work,
remove the line from `config.h' that defines
HAVE_READDIR_R. You may have to remove the HAVE_TERM_H
line as well.
SGI recommends that you install all of the patches on this page as a set: http://support.sgi.com/surfzone/patches/patchset/6.2_indigo.rps.html
At the very minimum, you should install the latest kernel rollup, the latest
rld rollup, and the latest libc rollup.
You definitely need all the POSIX patches on this page, for pthreads support:
http://support.sgi.com/surfzone/patches/patchset/6.2_posix.rps.html
If you get the something like the following error when compiling `mysql.cc':
"/usr/include/curses.h", line 82: error(1084): invalid combination of type
Type the following in the top-level directory of your MySQL source tree:
shell> extra/replace bool curses_bool < /usr/include/curses.h \ > include/curses.h shell> make
There have also been reports of scheduling problems. If only one thread is running, things go slow. Avoid this by starting another client. This may lead to a 2-to-10-fold increase in execution speed thereafter for the other thread. This is a poorly understood problem with Irix threads; you may have to improvise to find solutions until this can be fixed.
If you are compiling with gcc, you can use the following
configure command:
CC=gcc CXX=gcc CXXFLAGS=-O3 \ ./configure --prefix=/usr/local/mysql --enable-thread-safe-client \ --with-named-thread-libs=-lpthread
On Irix 6.5.11 with native Irix C and C++ compilers ver. 7.3.1.2, the following is reported to work
CC=cc CXX=CC CFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include \ -L/usr/local/lib' CXXFLAGS='-O3 -n32 -TARG:platform=IP22 \ -I/usr/local/include -L/usr/local/lib' ./configure \ --prefix=/usr/local/mysql --with-innodb --with-berkeley-db \ --with-libwrap=/usr/local \ --with-named-curses-libs=/usr/local/lib/libncurses.a
The current port is tested only on a ``sco3.2v5.0.4'' and ``sco3.2v5.0.5'' system. There has also been a lot of progress on a port to ``sco 3.2v4.2''.
For the moment the recommended compiler on OpenServer is gcc 2.95.2. With this you should be able to compile MySQL with just:
CC=gcc CXX=gcc ./configure ... (options)
./configure in the `threads/src' directory and
select the SCO OpenServer option. This command copies
`Makefile.SCO5' to `Makefile'.
make.
cd to the `thread/src' directory, and run
make install. make when making MySQL.
safe_mysqld as root, you probably will get
only the default 110 open files per process. mysqld will write a
note about this in the log file.
configure
command should work: shell> ./configure --prefix=/usr/local/mysql --disable-shared
configure command should work: shell> CFLAGS="-D_XOPEN_XPG4" CXX=gcc CXXFLAGS="-D_XOPEN_XPG4" \
./configure \
--prefix=/usr/local/mysql \
--with-named-thread-libs="-lgthreads -lsocket -lgen -lgthreads" \
--with-named-curses-libs="-lcurses"
You may get some problems with some include files. In this case, you can
find new SCO-specific include files at http://www.mysql.com/Downloads/SCO/SCO-3.2v4.2-includes.tar.gz.
You should unpack this file in the `include' directory of your MySQL
source tree. Caldera (SCO) development notes:
mysqld with -lgthreads -lsocket -lgthreads.
malloc. If you encounter problems with memory usage, make sure
that `gmalloc.o' is included in `libgthreads.a' and
`libgthreads.so'.
read(), write(), getmsg(),
connect(), accept(), select(), and
wait().
If you want to install DBI on Caldera (SCO), you have to edit the `Makefile' in DBI-xxx and each subdirectory.
Note that the following assumes gcc 2.95.2 or newer:
OLD: NEW: CC = cc CC = gcc CCCDLFLAGS = -KPIC -W1,-Bexport CCCDLFLAGS = -fpic CCDLFLAGS = -wl,-Bexport CCDLFLAGS = LD = ld LD = gcc -G -fpic LDDLFLAGS = -G -L/usr/local/lib LDDLFLAGS = -L/usr/local/lib LDFLAGS = -belf -L/usr/local/lib LDFLAGS = -L/usr/local/lib LD = ld LD = gcc -G -fpic OPTIMISE = -Od OPTIMISE = -O1 OLD: CCCFLAGS = -belf -dy -w0 -U M_XENIX -DPERL_SCO5 -I/usr/local/include NEW: CCFLAGS = -U M_XENIX -DPERL_SCO5 -I/usr/local/include
This is because the Perl dynaloader will not load the DBI
modules if they were compiled with icc or cc.
Perl works best when compiled with cc.
You must use a version of MySQL at least as recent as Version 3.22.13 because that version fixes some portability problems under Unixware.
We have been able to compile MySQL with the following configure
command on Unixware Version 7.0.1:
CC=cc CXX=CC ./configure --prefix=/usr/local/mysql
If you want to use gcc, you must use gcc 2.95.2 or
newer.
Caldera provides libsocket.so.2 at ftp://stage.caldera.com/pub/security/tools for pre-OSR506 security fixes. Also, the telnetd fix at ftp://stage.caldera.com/pub/security/openserver/CSSA-2001-SCO.10/ as both libsocket.so.2 and libresolv.so.1 with instructions for installing on pre-OSR506 systems.
It's probably a good idea to install the above patches before trying to compile/use MySQL.
MySQL uses quite a few open files. Because of this, you should add something like the following to your `CONFIG.SYS' file:
SET EMXOPT=-c -n -h1024
If you don't do this, you will probably run into the following error:
File 'xxxx' not found (Errcode: 24)
When using MySQL with OS/2 Warp 3, FixPack 29 or above is required. With OS/2 Warp 4, FixPack 4 or above is required. This is a requirement of the Pthreads library. MySQL must be installed in a partition that supports long filenames such as HPFS, FAT32, etc.
The `INSTALL.CMD' script must be run from OS/2's own `CMD.EXE' and may not work with replacement shells such as `4OS2.EXE'.
The `scripts/mysql-install-db' script has been renamed. It is now called `install.cmd' and is a REXX script, which will set up the default MySQL security settings and create the WorkPlace Shell icons for MySQL.
Dynamic module support is compiled in but not fully tested. Dynamic modules should be compiled using the Pthreads run-time library.
gcc -Zdll -Zmt -Zcrtdll=pthrdrtl -I../include -I../regex -I.. \
-o example udf_example.cc -L../lib -lmysqlclient udf_example.def
mv example.dll example.udf
Note: Due to limitations in OS/2, UDF module name stems must
not exceed 8 characters. Modules are stored in the `/mysql2/udf'
directory; the safe-mysqld.cmd script will put this directory in
the BEGINLIBPATH environment variable. When using UDF modules,
specified extensions are ignored@-it is assumed to be `.udf'. For
example, in Unix, the shared module might be named `example.so' and you
would load a function from it like this:
mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME "example.so";
Is OS/2, the module would be named `example.udf', but you would not specify the module extension:
mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME "example";
We are really interested in getting MySQL to work on BeOS, but unfortunately we don't have any person who knows BeOS or has time to do a port.
We are interested in finding someone to do a port, and we will help them with any technical questions they may have while doing the port.
We have previously talked with some BeOS developers that have said that MySQL is 80% ported to BeOS, but we haven't heard from them in a while.
We are really interested in getting MySQL to work on NetWare, but unfortunately we don't have any person who knows NetWare or has time to do a port.
We are interested in finding someone to do a port, and we will help them with any technical questions they may have while doing the port.
Perl support for MySQL is provided by means of the
DBI/DBD client interface. See section 8.2 MySQL
Perl API. The Perl DBD/DBI client code requires
Perl Version 5.004 or later. The interface will not work if you
have an older version of Perl.
MySQL Perl support also requires that you've installed MySQL client programming support. If you installed MySQL from RPM files, client programs are in the client RPM, but client programming support is in the developer RPM. Make sure you've installed the latter RPM.
As of Version 3.22.8, Perl support is distributed separately from the main MySQL distribution. If you want to install Perl support, the files you will need can be obtained from http://www.mysql.com/Downloads/Contrib/.
The Perl distributions are provided as compressed tar archives
and have names like `MODULE-VERSION.tar.gz', where MODULE
is the module name and VERSION is the version number. You should
get the Data-Dumper, DBI, and
Msql-Mysql-modules distributions and install them in that order.
The installation procedure is shown here. The example shown is for the
Data-Dumper module, but the procedure is the same for all three
distributions:
shell> gunzip < Data-Dumper-VERSION.tar.gz | tar xvf -This command creates a directory named `Data-Dumper-VERSION'.
shell> cd Data-Dumper-VERSION
shell> perl Makefile.PL shell> make shell> make test shell> make install
The make test command is important because it verifies that the
module is working. Note that when you run that command during the
Msql-Mysql-modules installation to exercise the interface code, the
MySQL server must be running or the test will fail.
It is a good idea to rebuild and reinstall the
Msql-Mysql-modules distribution whenever you install a new release
of MySQL, particularly if you notice symptoms such as all your DBI
scripts dumping core after you upgrade MySQL.
If you don't have the right to install Perl modules in the system directory or if you to install local Perl modules, the following reference may help you:
http://www.iserver.com/support/contrib/perl5/modules.html
Look under the heading Installing New Modules that Require Locally
Installed Modules.
To install the MySQL DBD module with ActiveState Perl on
Windows, you should do the following:
set HTTP_proxy=my.proxy.com:3128
C:\> c:\perl\bin\ppm.pl
DBI: ppm> install DBI
install \ ftp://ftp.de.uu.net/pub/CPAN/authors/id/JWIED/DBD-mysql-1.2212.x86.ppd
The above should work at least with ActiveState Perl Version 5.6.
If you can't get the above to work, you should instead install the
MyODBC driver and connect to MySQL server through ODBC:
use DBI;
$dbh= DBI->connect("DBI:ODBC:$dsn","$user","$password") ||
die "Got error $DBI::errstr when connecting to $dsn\n";
The MySQL Perl distribution contains DBI, DBD:MySQL
and DBD:ODBC.
C: so that you get a
`C:\PERL' directory.
perl works by executing perl -v in a
DOS shell. DBI/DBD InterfaceIf Perl reports that it can't find the `../mysql/mysql.so' module, then the problem is probably that Perl can't locate the shared library `libmysqlclient.so'.
You can fix this by any of the following methods:
Msql-Mysql-modules distribution with perl
Makefile.PL -static -config rather than perl Makefile.PL.
libmysqlclient.so to the directory where your other
shared libraries are located (probably `/usr/lib' or
`/lib').
LD_RUN_PATH environment variable. If you get the following errors from DBD-mysql, you are probably
using gcc (or using an old binary compiled with gcc):
/usr/bin/perl: can't resolve symbol '__moddi3' /usr/bin/perl: can't resolve symbol '__divdi3'
Add -L/usr/lib/gcc-lib/... -lgcc to the link command when the
`mysql.so' library gets built (check the output from make
for `mysql.so' when you compile the Perl client). The -L
option should specify the pathname of the directory where `libgcc.a' is
located on your system.
Another cause of this problem may be that Perl and MySQL aren't both compiled
with gcc. In this case, you can solve the mismatch by compiling
both with gcc.
If you get the following error from Msql-Mysql-modules when you
run the tests:
t/00base............install_driver(mysql) failed: Can't load '../blib/arch/auto/DBD/mysql/mysql.so' for module DBD::mysql: ../blib/arch/auto/DBD/mysql/mysql.so: undefined symbol: uncompress at /usr/lib/perl5/5.00503/i586-linux/DynaLoader.pm line 169.
it means that you need to include the compression library, -lz, to the link line. This can be doing the following change in the file `lib/DBD/mysql/Install.pm':
$sysliblist .= " -lm"; to $sysliblist .= " -lm -lz";
After this, you must run 'make realclean' and then proceed with the installation from the beginning.
If you want to use the Perl module on a system that doesn't support dynamic
linking (like Caldera/SCO) you can generate a static version of Perl that
includes DBI and DBD-mysql. The way this works is that
you generate a version of Perl with the DBI code linked in and
install it on top of your current Perl. Then you use that to build a version of
Perl that additionally has the DBD code linked in, and install
that.
On Caldera (SCO), you must have the following environment variables set:
shell> LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/progressive/lib or shell> LD_LIBRARY_PATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:\ /usr/progressive/lib:/usr/skunk/lib shell> LIBPATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:\ /usr/progressive/lib:/usr/skunk/lib shell> MANPATH=scohelp:/usr/man:/usr/local1/man:/usr/local/man:\ /usr/skunk/man:
First, create a Perl that includes a statically linked DBI by
running these commands in the directory where your DBI distribution
is located:
shell> perl Makefile.PL -static -config shell> make shell> make install shell> make perl
Then you must install the new Perl. The output of make perl will
indicate the exact make command you will need to execute to perform
the installation. On Caldera (SCO), this is make -f Makefile.aperl
inst_perl MAP_TARGET=perl.
Next, use the just-created Perl to create another Perl that also includes a
statically-linked DBD::mysql by running these commands in the
directory where your Msql-Mysql-modules distribution is located:
shell> perl Makefile.PL -static -config shell> make shell> make install shell> make perl
Finally, you should install this new Perl. Again, the output of make
perl indicates the command to use.