download
TRANSCRIPT
MySQL Database Administrator
Training Guide
by
L.Ramkumar.,
M.Sc.(C.S)., D.W.D., M.Com., (Co-Op)., B.G.L., (PhD)
1. Information about MySQL.
1.1 What is MySQL?
1.2 History of MySQL.
1.3 The Main Features of MySQL.
1.4 MySQL Development Roadmap
1.5 What is new in MySQL 5.0 ?
2 Installing and Upgrading MySQL
2.1 Overview of MySQL Community Server Installation.
2.2 Operating Systems Supported by MySQL Community Server.
2.3 How to Get MySQL ?
2.4 Installation Wizard.
2.5 Starting the MySQL Installation Wizard.
2.5.1 Choosing an Installation Type.
2.5.2 The Custom Installation Dialog.
2.5.3 The Confirmation Dialog.
2.6 Upgrading MySQL with the Installation Wizard.
2.7 MySQL Server Configuration Wizard.
2.7.1 Starting the MySQL Server Configuration Wizard.
2.7.2 Starting the MySQL Server Configuration Wizard on
Linux.
2.7.3 Choosing a Configuration Type.
2.7.4 The Server Type Dialog.
2.7.5 The Database Usage Dialog.
2.7.6 The InnoDB Tablespace Dialog.
2.7.7 The Concurrent Connections Dialog.
2.7.8 The Networking and Strict Mode Options Dialog.
2.7.9 The Character Set Dialog.
2.7.10 The Service Options Dialog.
2.7.11 The Security Option Dialog.
2.7.12 The Confirmation Dialog.
2.8 Selecting a MySQL Server Type.
2.9 Starting MySQL from the Windows.
2.10 Installing MySQL from RPM Packages on Linux.
3 Introduction to MySQL Administrator. (Installation).
3.1 Installing Under Windows.
3.2 Installing Under Linux.
3.2.1 Installing the Generic tarball.
3.2.2 RPM Installation.
4 Running MySQL GUI Tools
4.1 Running Under Windows.
4.2 Connection Dialog.
4.3 Server Connections.
4.4 Threads
4.5 User Connections
4.6 User Administration
4.6.1 User Accounts
4.6.2 User Information
4.6.3 Schema Privileges
4.6.4 Global Privileges
4.6.5 Table Column Privileges
5 The MySQL System Tray Monitor
6 Backup
6.1 Backup Project.
6.2 Advanced Options
6.2.1 Backup Execution Method
6.2.2 Output File Options
7 Restore
7.1 The General Tab
7.2 Restore Content Tab
8 Replication Status
8.1 Configuring Replication Servers
8.2 Using the Replication Status Section
9 Storage Engines
9.1 The MyISAM Storage Engine
9.2 The InnoDB Storage Engine
9.3 The MERGE Storage Engine.
9.4 The MEMORY (HEAP) Storage Engine.
9.5 The EXAMPLE Storage Engine.
9.6 The FEDERATED Storage Engine
9.7 The ARCHIVE Storage Engine
9.8 The CSV Storage Engine
9.9 The BLACKHOLE Storage Engine
10 Optimization
1. Information about MySQL
1.1 What is MySQL?
MySQL, the most popular Open Source SQL database management system, is developed, distributed, and supported by MySQL AB. MySQL AB is a commercial company, founded by the MySQL developers. It is a second generation Open Source company that unites Open Source values and methodology with a successful business model.
The MySQL Web site (http://www.mysql.com/) provides the latest information about MySQL software and MySQL AB.
MySQL is a database management system.
A database is a structured collection of data. It may be anything from a simple shopping list to a picture gallery or the vast amounts of information in a corporate network. To add, access, and process data stored in a computer database, you need a database management system such as MySQL Server. Since computers are very good at handling large amounts of data, database management systems play a central role in computing, as standalone utilities, or as parts of other applications.
MySQL is a relational database management system.
A relational database stores data in separate tables rather than putting all the data in one big storeroom. This adds speed and flexibility. The SQL part of “MySQL” stands for “Structured Query Language.” SQL is the most common standardized language used to access databases and is defined by the ANSI/ISO SQL Standard. The SQL standard has been evolving since 1986 and several versions exist. In this manual, “SQL-92” refers to the standard released in 1992, “SQL:1999” refers to the standard released in 1999, and “SQL:2003” refers to the current version of the standard. We use the phrase “the SQL standard” to mean the current version of the SQL Standard at any time.
MySQL software is Open Source.
Open Source means that it is possible for anyone to use and modify the software. Anybody can download the MySQL software from the Internet and use it without paying anything. If you wish, you may study the source code and change it to suit your needs. The MySQL software uses the GPL (GNU General Public License), http://www.fsf.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 the MySQL Licensing Overview for more information (http://www.mysql.com/company/legal/licensing/).
The MySQL Database Server is very fast, reliable, and easy to use.
If that is what you are looking for, you should give it a try. MySQL Server also has a practical set of features developed in close cooperation with our users..
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. Although 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 Server works in client/server or embedded systems.
The MySQL Database Software is a client/server system that consists of a multi-threaded SQL server that supports different backends, several different client programs and libraries, administrative tools, and a wide range of application programming interfaces (APIs).
We also provide MySQL Server as an embedded multi-threaded library that you can link into your application to get a smaller, faster, easier-to-manage standalone product.
A large amount of contributed MySQL software is available.
It is very likely that your favorite application or language supports the MySQL Database Server.
The official way to pronounce “MySQL” is “My Ess Que Ell” (not “my sequel”), but we don't mind if you pronounce it as “my sequel” or in some other localized way.
1.2 History of MySQL
MySQL is named after co-founder Monty Widenius's daughter, My.
The name of the MySQL Dolphin (our logo) is “Sakila,” which was chosen by the founders of MySQL AB from a huge list of names suggested by users in our “Name the Dolphin” contest. The winning name was submitted by Ambrose Twebaze, an Open Source software developer from Swaziland, Africa. According to Ambrose, the feminine name Sakila has its roots in SiSwati, the local language of Swaziland. Sakila is also the name of a town in Arusha, Tanzania, near Ambrose's country of origin, Uganda.
1.3 The Main Features of MySQL
Internals and Portability:
Written in C and C++. Tested with a broad range of different compilers.
Works on many different platforms
Uses GNU Automake, Autoconf, and Libtool for portability.
The MySQL Server design is multi-layered with independent modules.
Fully multi-threaded using kernel threads. It can easily use multiple CPUs if they are available.
Provides transactional and non-transactional storage engines.
Uses very fast B-tree disk tables (MyISAM) with index compression.
Relatively easy to add other storage engines. This is useful if you want to provide an SQL interface for an in-house database.
A very fast thread-based memory allocation system.
Very fast joins using an optimized one-sweep multi-join.
In-memory hash tables, which are used as temporary tables.
SQL functions are implemented using a highly optimized class library and should be as fast as possible. Usually there is no memory allocation at all after query initialization.
The MySQL code is tested with Purify (a commercial memory leakage detector) as well as with Valgrind, a GPL tool (http://developer.kde.org/~sewardj/).
The server is available as a separate program for use in a client/server networked environment. It is also available as a library that can be embedded (linked) into standalone applications. Such applications can be used in isolation or in environments where no network is available.
Data Types:
Many data types: signed/unsigned integers 1, 2, 3, 4, and 8 bytes long, FLOAT, DOUBLE, CHAR, VARCHAR, TEXT, BLOB, DATE, TIME, DATETIME, TIMESTAMP, YEAR, SET, ENUM, and OpenGIS spatial types.
Fixed-length and variable-length records.
Statements and Functions:
Full operator and function support in the SELECT list and WHERE clause of queries. For example:
mysql> SELECT CONCAT(first_name, ' ', last_name) -> FROM citizen -> WHERE income/dependents > 10000 AND age > 30;
Full support for SQL GROUP BY and ORDER BY clauses. Support for group functions (COUNT(), COUNT(DISTINCT ...), AVG(), STD(), SUM(), MAX(), MIN(), and GROUP_CONCAT()).
Support for LEFT OUTER JOIN and RIGHT OUTER JOIN with both standard SQL and ODBC syntax.
Support for aliases on tables and columns as required by standard SQL.
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.
The MySQL-specific SHOW statement can be used to retrieve information about databases, storage engines, tables, and indexes. MySQL 5.0 adds support for the INFORMATION_SCHEMA database, implemented according to standard SQL.
The EXPLAIN statement can be used to determine how the optimizer resolves a query.
Function names do not clash with table or column names. For example, 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.
You can refer to tables from different databases in the same statement.
Security:
A privilege and password system that is very flexible and secure, and that allows host-based verification.
Passwords are secure because all password traffic is encrypted when you connect to a server.
Scalability and Limits:
Handles large databases. We use MySQL Server with databases that contain 50 million records. We also know of users who use MySQL Server with 60,000 tables and about 5,000,000,000 rows.
Up to 64 indexes per table are allowed (32 before MySQL 4.1.2). Each index may consist of 1 to 16 columns or parts of columns. The maximum index width is 1000 bytes (767 for InnoDB); before MySQL 4.1.2, the limit is 500 bytes. An index may use a prefix of a column for CHAR, VARCHAR, BLOB, or TEXT column types.
Connectivity:
Clients can connect to MySQL Server using several protocols: o Clients can connect using TCP/IP sockets on any platform.
o On Windows systems in the NT family (NT, 2000, XP, 2003, or Vista), clients can connect using named pipes if the server is started with the --enable-named-pipe option. In MySQL 4.1 and higher, Windows servers also support shared-memory connections if started with the --
shared-memory option. Clients can connect through shared memory by using the --protocol=memory option.
o On Unix systems, clients can connect using Unix domain socket files.
MySQL client programs can be written in many languages. A client library written in C is available for clients written in C or C++, or for any language that provides C bindings.
APIs for C, C++, Eiffel, Java, Perl, PHP, Python, Ruby, and Tcl are available, allowing MySQL clients to be written in many languages.
The Connector/ODBC (MyODBC) interface provides MySQL support for client programs that use ODBC (Open Database Connectivity) connections. For example, you can use MS Access to connect to your MySQL server. Clients can be run on Windows or Unix. MyODBC source is available. All ODBC 2.5 functions are supported, as are many others.
The Connector/J interface provides MySQL support for Java client programs that use JDBC connections. Clients can be run on Windows or Unix. Connector/J source is available.
MySQL Connector/NET enables developers to easily create .NET applications that require secure, high-performance data connectivity with MySQL. It implements the required ADO.NET interfaces and integrates into ADO.NET aware tools. Developers can build applications using their choice of .NET languages. MySQL Connector/NET is a fully managed ADO.NET driver written in 100% pure C#.
Localization:
The server can provide error messages to clients in many languages. Full support for several different character sets, including latin1 (cp1252),
german, big5, ujis, and more. For example, the Scandinavian characters “å”, “ä” and “ö” are allowed in table and column names. Unicode support is available as of MySQL 4.1.
All data is saved in the chosen character set.
Sorting and comparisons are done according to the chosen character set and collation (using latin1 and Swedish collation by default). It is possible to change this when the 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 time and runtime.
As of MySQL 4.1, the server time zone can be changed dynamically, and individual clients can specify their own time zone
Clients and Tools:
MySQL AB provides several client and utility programs. These include both command-line programs such as mysqldump and mysqladmin, and graphical programs such as MySQL Administrator and MySQL Query Browser.
MySQL Server has built-in support for SQL statements to check, optimize, and repair tables. These statements are available from the command line through the mysqlcheck client. MySQL also includes myisamchk, a very fast command-line utility for performing these operations on MyISAM tables.
MySQL programs can be invoked with the --help or -? option to obtain online assistance.
1.4 MySQL Development Roadmap
The current production release series is MySQL 5.0, which was declared stable for production use as of MySQL 5.0.15, released in October 2005. The previous production release series was MySQL 4.1, which was declared stable for production use as of MySQL 4.1.7, released in October 2004. “Production status” means that future 5.0 and 4.1 development is limited only to bugfixes. For the older MySQL 4.0 and 3.23 series, only critical bugfixes are made.
Active MySQL development currently is taking place in the MySQL 5.0 and 5.1 release series, and new features are being added only to the latter
The most requested features and the versions in which they were implemented or are scheduled for implementation are summarized in the following table:
Feature MySQL Series
Unions 4.0
Subqueries 4.1
R-trees 4.1 (for the MyISAM storage engine)
Stored procedures 5.0
Views 5.0
Cursors 5.0
XA transactions 5.0
Triggers 5.0 and 5.1
Event scheduler 5.1
Partitioning 5.1
Pluggable storage engine API 5.1
Plugin API 5.1
Row-based replication 5.1
Server log tables 5.1
Foreign keys 6.x (implemented in 3.23 for InnoDB)
1.5 What's New in MySQL 5.0
The following features are implemented in MySQL 5.0.
BIT Data Type: Can be used to store numbers in binary notation Cursors: Elementary support for server-side cursors
Information Schema: The introduction of the INFORMATION_SCHEMA database in MySQL 5.0 provided a standards-compliant means for accessing the MySQL Server's metadata; that is, data about the databases (schemas) on the server and the objects which they contain.
Instance Manager: Can be used to start and stop the MySQL Server, even from a remote host.
Precision Math: MySQL 5.0 introduced stricter criteria for acceptance or rejection of data, and implemented a new library for fixed-point arithmetic. These contributed to a much higher degree of accuracy for mathematical operations and greater control over invalid values.
Storage Engines: Storage engines added in MySQL 5.0 include ARCHIVE and FEDERATED. .
Stored Routines: Support for named stored procedures and stored functions was implemented in MySQL 5.0.
Strict Mode and Standard Error Handling: MySQL 5.0 added a strict mode where by it follows standard SQL in a number of ways in which it did not previously.
Triggers: MySQL 5.0 added limited support for triggers. .
VARCHAR Data Type: The effective maximum length of a VARCHAR column was increased to 65,535 bytes, and stripping of trailing whitespace was eliminated. (The actual maximum length of a VARCHAR is determined by the maximum row
size and the character set you use. The maximum effective column length is subject to a row size of 65,535 bytes, which is shared among all columns.)
Views: MySQL 5.0 added support for named, updatable views.
XA Transactions
Performance enhancements: A number of improvements were made in MySQL 5.0 to improve the speed of certain types of queries and in the handling of certain types. These include:
o MySQL 5.0 introduces a new “greedy” optimizer which can greatly reduce the time required to arrive at a query execution plan. This is particularly noticeable where several tables are to be joined and no good join keys can otherwise be found. Without the greedy optimizer, the complexity of the search for an execution plan is calculated as N!, where N is the number of tables to be joined. The greedy optimizer reduces this to N!/(D-1)!, where D is the depth of the search. Although the greedy optimizer does not guarantee the best possible of all execution plans (this is currently being worked on), it can reduce the time spent arriving at an execution plan for a join involving a great many tables — 30, 40, or more — by a factor of as much as 1,000. This should eliminate most if not all situations where users thought that the optimizer had hung when trying to perform joins across many tables.
o Use of the Index Merge method to obtain better optimization of AND and OR relations over different keys. (Previously, these were optimized only where both relations in the WHERE clause involved the same key.) This also applies to other one-to-one comparison operators (>, <, and so on), including = and the IN operator. This means that MySQL can use multiple indexes in retrieving results for conditions such as WHERE key1 > 4 OR key2 < 7 and even combinations of conditions such as WHERE (key1 > 4 OR key2 < 7) AND (key3 >= 10 OR key4 = 1).
o A new equality detector finds and optimizes “hidden” equalities in joins. For example, a WHERE clause such as
t1.c1=t2.c2 AND t2.c2=t3.c3 AND t1.c1 < 5
implies these other conditions
t1.c1=t3.c3 AND t2.c2 < 5 AND t3.c3 < 5
These optimizations can be applied with any combination of AND and OR operators.
o Optimization of NOT IN and NOT BETWEEN relations, reducing or eliminating table scans for queries making use of them by mean of range analysis. The performance of MySQL with regard to these relations now matches its performance with regard to IN and BETWEEN.
o The VARCHAR data type as implemented in MySQL 5.0 is more efficient than in previous versions, due to the elimination of the old (and nonstandard) removal of trailing spaces during retrieval.
o The addition of a true BIT column type; this type is much more efficient for storage and retrieval of Boolean values than the workarounds required in MySQL in versions previous to 5.0.
o Performance Improvements in the InnoDB Storage Engine:
New compact storage format which can save up to 20% of the disk space required in previous MySQL/InnoDB versions.
Faster recovery from a failed or aborted ALTER TABLE.
Faster implementation of TRUNCATE.
o Performance Improvements in the NDBCluster Storage Engine:
Faster handling of queries that use IN and BETWEEN.
Condition pushdown: In cases involving the comparison of an unindexed column with a constant, this condition is “pushed down” to the cluster where it is evaluated in all partitions simultaneously, eliminating the need to send non-matching records over the network. This can make such queries 10 to 100 times faster than in MySQL 4.1 Cluster.
2.0 Installing and Upgrading MySQL
2.1 Overview of MySQL Community Server Installation
1. Determine whether MySQL runs and is supported on your platform. Not all platforms are equally suitable for running MySQL, and not all platforms on which MySQL is known to run are officially supported by MySQL AB.
2. Choose which distribution to install. Several versions of MySQL are available, and most are available in multiple distribution formats. You can choose from prepackaged distributions containing binary (precompiled) programs or source code. When in doubt, use a binary distribution.
3. Download the distribution that you want to install. .
4. Install the distribution.
5. Perform any necessary post-installation setup. After installing MySQL, read Post-Installation Setup and Testing which contains important information about making sure the MySQL server is working properly. It also describes how to secure the initial MySQL user accounts, which have no passwords until you assign passwords. The information in this section applies whether you install MySQL using a binary or source distribution.
6. Perform setup for running benchmarks (optional). If you want to use the MySQL benchmark scripts, Perl support for MySQL must be available
2.2 Operating Systems Supported by MySQL Community Server.
MySQL has been reported to compile successfully on the following combinations of operating system and thread package.
AIX 4.x and 5.x with native threads. FreeBSD 5.x and up with native threads.
HP-UX 11.x with native threads.
Linux. MySQL builds on all fairly recent Linux distributions with glibc 2.3.
Mac OS X.
NetBSD 1.3/1.4 Intel and NetBSD 1.3 Alpha.
Novell NetWare 6.0 and 6.5.
OpenBSD 2.5 and with native threads. OpenBSD earlier than 2.5 with the MIT-pthreads package. .
SCO Openserver 6.0.x
SCO UnixWare 7.1.x.
SGI Irix 6.x with native threads.
Solaris 2.5 and above with native threads on SPARC and x86.
Tru64 Unix.
Windows 2000, XP, and Windows Server 2003, as well as 32-bit Windows Vista.
2.3 How to Get MySQL
Check downloads page at http://dev.mysql.com/downloads/ for information about the current version of MySQL and for downloading instructions. For a complete up-to-date list of MySQL download mirror sites, see http://dev.mysql.com/downloads/mirrors.html .
Installation Layouts
This section describes the default layout of the directories created by installing binary or source distributions provided by MySQL AB.
For MySQL 5.0 on Windows, the default installation directory is C:\Program Files\MySQL\MySQL Server 5.0. (Some Windows users prefer to install in C:\mysql, the directory that formerly was used as the default. However, the layout of the subdirectories remains the same.) The installation directory has the following subdirectories:
Directory Contentsbin Client programs and the mysqld server
data Log files, databasesDocs Manual in CHM formatexamples Example programs and scriptsinclude Include (header) fileslib Librariesscripts Utility scriptsshare Error message files
Installations created from MySQL AB's Linux RPM distributions result in files under the following system directories:
Directory Contents/usr/bin Client programs and scripts/usr/sbin The mysqld server
/var/lib/mysql Log files, databases/usr/share/info Manual in Info format/usr/share/man Unix man pages/usr/include/mysql Include (header) files/usr/lib/mysql Libraries/usr/share/mysql Error message and character set files
/usr/share/sql-bench Benchmarks
On Unix, a tar file 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 Contentsbin Client programs and the mysqld server
data Log files, databasesdocs Manual in Info formatman Unix manual pagesinclude Include (header) fileslib Librariesscripts mysql_install_db
share/mysql Error message filessql-bench Benchmarks
2.4 Installation Wizard
MySQL Installation Wizard is an installer for the MySQL server that uses the latest installer technologies for Microsoft Windows. The MySQL Installation Wizard, in combination with the MySQL Configuration Wizard, allows a user to install and configure a MySQL server that is ready for use immediately after installation.
The MySQL Installation Wizard is the standard installer for all MySQL server distributions, version 4.1.5 and higher. Users of previous versions of MySQL need to shut down and remove their existing MySQL installations manually before installing MySQL with the MySQL Installation Wizard
For MySQL 5.0, there are three installation packages to choose from when installing MySQL on Windows:
The Essentials package. This package has a filename similar to mysql-essential-5.0.60-win32.msi and contains the minimum set of files needed to install MySQL on Windows, including the Configuration Wizard. This package does not include optional components such as the embedded server and benchmark suite.
The Complete package. This package has a filename similar to mysql-5.0.60-win32.zip and contains all files needed for a complete Windows installation, including the Configuration Wizard. This package includes optional components such as the embedded server and benchmark suite.
The no-install archive. This package has a filename similar to mysql-noinstall-5.0.60-win32.zip and contains all the files found in the Complete install package, with the exception of the Configuration Wizard. This package does not include an automated installer, and must be manually installed and configured.
2.5 Starting the MySQL Installation Wizard
The process for starting the wizard depends on the contents of the installation package you download. If there is a setup.exe file present, double-click it to start the installation process. If there is an .msi file present, double-click it to start the installation process
2.5.1 Choosing an Installation Type
There are three installation types available: Typical, Complete, and Custom
The Typical installation type installs the MySQL server, the mysql command-line client, and the command-line utilities. The command-line clients and utilities include mysqldump , myisamchk , and several other tools to help you manage the MySQL server.
The Complete installation type installs all components included in the installation package. The full installation package includes components such as the embedded server library, the benchmark suite, support scripts, and documentation.
The Custom installation type gives you complete control over which packages you wish to install and the installation path that is used.
If you choose the Typical or Complete installation types and click the Next button, you advance to the confirmation screen to verify your choices and begin the installation. If you choose the Custom installation type and click the Next button, you advance to the custom installation dialog
2.5.2 The Custom Installation Dialog.
If you wish to change the installation path or the specific components that are installed by the MySQL Installation Wizard, choose the Custom installation type
A tree view on the left side of the custom install dialog lists all available components. Components that are not installed have a red X icon; components that are installed have a gray icon. To change whether a component is installed, click on that component's icon and choose a new option from the drop-down list that appears.
You can change the default installation path by clicking the Change... button to the right of the displayed installation path.
After choosing your installation components and installation path, click the Next button to advance to the confirmation dialog.
2.5.3 The Confirmation Dialog
Once you choose an installation type and optionally choose your installation components, you advance to the confirmation dialog. Your installation type and installation path are displayed for you to review
To install MySQL if you are satisfied with your settings, click the Install button. To change your settings, click the Back button. To exit the MySQL Installation Wizard without installing MySQL, click the Cancel button.
After installation is complete, you have the option of registering with the MySQL web site.
2.6 Upgrading MySQL with the Installation Wizard
The MySQL Installation Wizard can perform server upgrades automatically using the upgrade capabilities of MSI. That means you do not need to remove a previous installation manually before installing a new release. The installer automatically shuts down and removes the previous MySQL service before installing the new version.
Automatic upgrades are available only when upgrading between installations that have the same major and minor version numbers. For example, you can upgrade automatically from MySQL 4.1.5 to MySQL 4.1.6, but not from MySQL 4.1 to MySQL 5.0.
2.7 MySQL Server Configuration Wizard
The MySQL Server Configuration Wizard helps automate the process of configuring your server. It creates a custom MySQL configuration file (my.ini or my.cnf ) by asking you a series of questions and then applying your responses to a template to generate the configuration file that is tuned to your installation.
The MySQL Server Configuration Wizard is included with the MySQL 5.0 server. For Community Server users, the MySQL Server Configuration Wizard is available only for Windows. For Enterprise Server users, the MySQL Server Configuration Wizard is included as part of the standard Enterprise Installer.
2.7.1 Starting the MySQL Server Configuration Wizard
The MySQL Server Configuration Wizard is normally started as part of the installation process. You should only need to run the MySQL Server Configuration Wizard again when you need to change the configuration parameters of your server.
If you chose not to open a port prior to installing MySQL on Windows Vista, you can choose to use the MySQL Server Configuration Wizard after installation. However, you must open a port in the Windows Firewall. Rather than opening a port, you also have the option of adding MySQL as a program that bypasses the Windows Firewall. One or the other option is sufficient — you need not do both. Additionally, when running the MySQL Server Configuration Wizard on Windows Vista ensure that you are logged in as a user with administrative rights.
You can launch the MySQL Configuration Wizard by clicking the MySQL Server Instance Config Wizard entry in the MySQL section of the Windows Start menu.
Alternatively, you can navigate to the bin directory of your MySQL installation and launch the MySQLInstanceConfig.exe file directly.
The MySQL Server Configuration Wizard places the my.ini file in the installation directory for the MySQL server. This helps associate configuration files with particular server instances.
To ensure that the MySQL server knows where to look for the my.ini file, an argument similar to this is passed to the MySQL server as part of the service installation:
--defaults-file="C:\Program Files\MySQL\MySQL Server 5.0\my.ini"
Here, C:\Program Files\MySQL\MySQL Server 5.0 is replaced with the installation path to the MySQL Server. The --defaults-file option instructs the MySQL server to read the specified file for configuration options when it starts.
Apart from making changes to the my.ini file by running the MySQL Server Configuration Wizard again, you can modify it by opening it with a text editor and making any necessary changes. You can also modify the server configuration with the MySQL Administrator utility.
MySQL clients and utilities such as the mysql and mysqldump command-line clients are not able to locate the my.ini file located in the server installation directory. To configure the client and utility applications, create a new my.ini file in the Windows installation directory (for example, C:\WINDOWS).
Under Windows Server 2003, Windows Server 2000 and Windows XP, MySQL Server Configuration Wizard will configure MySQL to work as a Windows service. To start and stop MySQL you use the Services application that is supplied as part of the Windows Administrator Tools.
2.7.2 Starting the MySQL Server Configuration Wizard on Linux
To start the MySQL Configuration Wizard on Linux, you must run the mysqlsetup command. You must be running an X Windows System server for the MySQL Server Configuration Wizard.
To display the MySQL Server Configuration Wizard interface on a different machine, set the value of the DISPLAY variable on the command line:
shell>DISPLAY=remote:0.0 mysqlsetup
The MySQL Server Configuration Wizard places the my.cnf file in the /etc directory.
This configuration file is automatically used when mysqld is started. The standard MySQL server initialization script, typically located within /etc/init.d/mysql, will also use this file automatically.
Apart from making changes to the my.ini file by running the MySQL Server Configuration Wizard again, you can modify it by opening it with a text editor and making any necessary changes. You can also modify the server configuration with the MySQL Administrator utility.
2.7.3 Choosing a Configuration Type
When you start the MySQL Server Configuration Wizard for a new MySQL installation, or choose the Re-configure Instance option for an existing installation, you advance to the Configuration Type dialog.
There are two configuration types available: Detailed Configuration and Standard Configuration. The Standard Configuration option is intended for new users who want to get started with MySQL quickly without having to make many decisions about server configuration. The Detailed Configuration option is intended for advanced users who want more fine-grained control over server configuration.
If you are new to MySQL and need a server configured as a single-user developer machine, the Standard Configuration should suit your needs. Choosing the Standard Configuration option causes the MySQL Configuration Wizard to set all configuration options automatically with the exception of Service Options and Security Options.
The Standard Configuration sets options that may be incompatible with systems where there are existing MySQL installations. If you have an existing MySQL installation on your system in addition to the installation you wish to configure, the Detailed Configuration option is recommended
2.7.4 The Server Type Dialog
There are three different server types available to choose from. The server type that you choose affects the decisions that the MySQL Server Configuration Wizard makes with regard to memory, disk, and processor usage.
Developer Machine : Choose this option for a typical desktop workstation where MySQL is intended only for personal use. It is assumed that many other desktop applications are running. The MySQL server is configured to use minimal system resources.
Server Machine : Choose this option for a server machine where the MySQL server is running alongside other server applications such as FTP, email, and Web
servers. The MySQL server is configured to use a moderate portion of the system resources.
Dedicated MySQL Server Machine : Choose this option for a server machine that is intended to run only the MySQL server. It is assumed that no other applications are running. The MySQL server is configured to use all available system resources.
2.7.5 The Database Usage Dialog
The Database Usage dialog allows you to indicate the storage engines that you expect to use when creating MySQL tables. The option you choose determines whether the InnoDB storage engine is available and what percentage of the server resources are available to InnoDB.
Multifunctional Database : This option enables both the InnoDB and MyISAM storage engines and divides resources evenly between the two. This option is recommended for users who use both storage engines on a regular basis.
Transactional Database Only : This option enables both the InnoDB and MyISAM storage engines, but dedicates most server resources to the InnoDB storage engine. This option is recommended for users who use InnoDB almost exclusively and make only minimal use of MyISAM.
Non-Transactional Database Only : This option disables the InnoDB storage engine completely and dedicates all server resources to the MyISAM storage engine. This option is recommended for users who do not use InnoDB.
The Configuration Wizard uses a template to generate the server configuration file. The Database Usage dialog sets one of the following option strings:
Multifunctional Database: MIXEDTransactional Database Only: INNODBNon-Transactional Database Only: MYISAM
When these options are processed through the default template (my-template.ini) the result is:
Multifunctional Database:default-storage-engine=InnoDB_myisam_pct=50
Transactional Database Only:default-storage-engine=InnoDB_myisam_pct=5
Non-Transactional Database Only:default-storage-engine=MyISAM_myisam_pct=100skip-innodb
The _myisam_pct value is used to calculate the percentage of resources dedicated to MyISAM. The remaining resources are allocated to InnoDB.
2.7.6 The InnoDB Tablespace Dialog
Some users may want to locate the InnoDB tablespace files in a different location than the MySQL server data directory. Placing the tablespace files in a separate location can be desirable if your system has a higher capacity or higher performance storage device available, such as a RAID storage system.
To change the default location for the InnoDB tablespace files, choose a new drive from the drop-down list of drive letters and choose a new path from the drop-down list of paths. To create a custom path, click the ... button.
If you are modifying the configuration of an existing server, you must click the Modify button before you change the path. In this situation you must move the existing tablespace files to the new location manually before starting the server
2.7.7 The Concurrent Connections Dialog
To prevent the server from running out of resources, it is important to limit the number of concurrent connections to the MySQL server that can be established. The Concurrent Connections dialog allows you to choose the expected usage of your server, and sets the limit for concurrent connections accordingly. It is also possible to set the concurrent connection limit manually.
Decision Support (DSS)/OLAP : Choose this option if your server does not require a large number of concurrent connections. The maximum number of connections is set at 100, with an average of 20 concurrent connections assumed.
Online Transaction Processing (OLTP) : Choose this option if your server requires a large number of concurrent connections. The maximum number of connections is set at 500.
Manual Setting : Choose this option to set the maximum number of concurrent connections to the server manually. Choose the number of concurrent connections from the drop-down box provided, or enter the maximum number of connections into the drop-down box if the number you desire is not listed.
2.7.8 The Networking and Strict Mode Options Dialog
Use the Networking Options dialog to enable or disable TCP/IP networking and to configure the port number that is used to connect to the MySQL server
TCP/IP networking is enabled by default. To disable TCP/IP networking, uncheck the box next to the Enable TCP/IP Networking option.
Port 3306 is used by default. To change the port used to access MySQL, choose a new port number from the drop-down box or type a new port number directly into the drop-down box. If the port number you choose is in use, you are prompted to confirm your choice of port number.
Set the Server SQL Mode to either enable or disable strict mode. Enabling strict mode (default) makes MySQL behave more like other database management systems. If you run applications that rely on MySQL's old “forgiving” behavior, make sure to either adapt those applications or to disable strict mode
2.7.9 The Character Set Dialog
The MySQL server supports multiple character sets and it is possible to set a default server character set that is applied to all tables, columns, and databases unless overridden. Use the Character Set dialog to change the default character set of the MySQL server.
Standard Character Set : Choose this option if you want to use latin1 as the default server character set. latin1 is used for English and many Western European languages.
Best Support For Multilingualism : Choose this option if you want to use utf8 as the default server character set. This is a Unicode character set that can store characters from many different languages.
Manual Selected Default Character Set / Collation : Choose this option if you want to pick the server's default character set manually. Choose the desired character set from the provided drop-down list.
2.7.10 The Service Options Dialog
On Windows platforms, the MySQL server can be installed as a Windows service. When installed this way, the MySQL server can be started automatically during system startup, and even restarted automatically by Windows in the event of a service failure.
The MySQL Server Configuration Wizard installs the MySQL server as a service by default, using the service name MySQL. If you do not wish to install the service, uncheck the box next to the Install As Windows Service option. You can change the service name
by picking a new service name from the drop-down box provided or by entering a new service name into the drop-down box.
To install the MySQL server as a service but not have it started automatically at startup, uncheck the box next to the Launch the MySQL Server Automatically option.
2.7.11 The Security Options Dialog
It is strongly recommended that you set a root password for your MySQL server, and the MySQL Server Configuration Wizard requires by default that you do so. If you do not wish to set a root password, uncheck the box next to the Modify Security Settings option
To set the root password, enter the desired password into both the New root password and Confirm boxes. If you are reconfiguring an existing server, you need to enter the existing root password into the Current root password box.
To prevent root logins from across the network, check the box next to the Root may only connect from localhost option. This increases the security of your root account.
To create an anonymous user account, check the box next to the Create An Anonymous Account option. Creating an anonymous account can decrease server security and cause login and permission difficulties. For this reason, it is not recommended.
2.7.12 The Confirmation Dialog
The final dialog in the MySQL Server Configuration Wizard is the Confirmation Dialog . To start the configuration process, click the Execute button. To return to a previous dialog, click the Back button. To exit the MySQL Server Configuration Wizard without configuring the server, click the Cancel button.
After you click the Execute button, the MySQL Server Configuration Wizard performs a series of tasks and displays the progress onscreen as the tasks are performed.
The MySQL Server Configuration Wizard first determines configuration file options based on your choices using a template prepared by MySQL AB developers and engineers. This template is named my-template.ini and is located in your server installation directory.
The MySQL Configuration Wizard then writes these options to the corresponding configuration file.
If you chose to create a service for the MySQL server, the MySQL Server Configuration Wizard creates and starts the service. If you are reconfiguring an existing service, the MySQL Server Configuration Wizard restarts the service to apply your configuration changes.
If you chose to set a root password, the MySQL Configuration Wizard connects to the server, sets your new root password, and applies any other security settings you may have selected.
After the MySQL Server Configuration Wizard has completed its tasks, it displays a summary. Click the Finish button to exit the MySQL Server Configuration Wizard
2.8 Selecting a MySQL Server Type
The following table shows the available servers for Windows in MySQL 5.0.
Binary Descriptionmysqld-nt Optimized binary with named-pipe supportmysqld Optimized binary without named-pipe supportmysqld-debug
Like mysqld-nt, but compiled with full debugging and automatic memory allocation checking
All of the preceding binaries are optimized for modern Intel processors, but should work on any Intel i386-class or higher processor.
Each of the servers in a distribution support the same set of storage engines. The SHOW ENGINES statement displays which engines a given server supports.
All Windows MySQL 5.0 servers have support for symbolic linking of database directories.
MySQL supports TCP/IP on all Windows platforms. MySQL servers on Windows support named pipes as indicated in the following list. However, the default is to use TCP/IP regardless of platform. (Named pipes are slower than TCP/IP in many Windows configurations.)
Use of named pipes is subject to these conditions:
Named pipes are enabled only if you start the server with the --enable-named-pipe option. It is necessary to use this option explicitly because some users have experienced problems with shutting down the MySQL server when named pipes were used.
Named-pipe connections are allowed only by the mysqld-nt and mysqld- debug servers.
2.9 Starting MySQL from the Windows
2.10 Installing MySQL from RPM Packages on Linux
The recommended way to install MySQL on RPM-based Linux distributions is by using the RPM packages. The RPMs provided by MySQL AB to the community should work on all versions of Linux that support RPM packages and use glibc 2.3. MySQL AB also provides RPMs with binaries that are statically linked to a patched version of glibc 2.2, but only for the x86 (32-bit) architecture
For non-RPM Linux distributions, you can install MySQL using a .tar.gz package.
MySQL AB does provide some platform-specific RPMs; the difference between a platform-specific RPM and a generic RPM is that a platform-specific RPM is built on the targeted platform and is linked dynamically whereas a generic RPM is linked statically with LinuxThreads.
Note
RPM distributions of MySQL often are provided by other vendors. Be aware that they may differ in features and capabilities from those built by MySQL AB, and that the instructions in this manual do not necessarily apply to installing them. The vendor's instructions should be consulted instead.
In most cases, you need to install only the MySQL-server and MySQL-client packages to get a functional MySQL installation. The other packages are not required for a standard installation.
For upgrades, if your installation was originally produced by installing multiple RPM packages, it is best to upgrade all the packages, not just some. For example, if you previously installed the server and client RPMs, do not upgrade just the server RPM.
If you get a dependency failure when trying to install MySQL packages (for example, error: removing these packages would break dependencies: libmysqlclient.so.10 is needed by ...), you should also install the MySQL-shared-compat package, which includes both the shared libraries for backward compatibility (libmysqlclient.so.12 for MySQL 4.0 and libmysqlclient.so.10 for MySQL 3.23).
Some Linux distributions still ship with MySQL 3.23 and they usually link applications dynamically to save disk space. If these shared libraries are in a separate package (for example, MySQL-shared), it is sufficient to simply leave this package installed and just upgrade the MySQL server and client packages (which are statically linked and do not depend on the shared libraries). For distributions that include the shared libraries in the same package as the MySQL server (for example, Red Hat Linux), you could either install our 3.23 MySQL-shared RPM, or use the MySQL-shared-compat package instead. (Do not install both.)
The RPM packages shown in the following list are available. The names shown here use a suffix of .glibc23.i386.rpm, but particular packages can have different suffixes, as described later. Packages that have community in the names are Community Server builds, available from MySQL 5.0.27 on.
MySQL-server-VERSION.glibc23.i386.rpm, MySQL-server-community-VERSION.glibc23.i386.rpm
The MySQL server. You need this unless you only want to connect to a MySQL server running on another machine.
MySQL-client-VERSION.glibc23.i386.rpm, MySQL-client-community-VERSION.glibc23.i386.rpm
The standard MySQL client programs. You probably always want to install this package.
MySQL-bench-VERSION.glibc23.i386.rpm
Tests and benchmarks. Requires Perl and the DBI and DBD::mysql modules.
MySQL-devel-VERSION.glibc23.i386.rpm, MySQL-devel-community-VERSION.glibc23.i386.rpm
The libraries and include files that are needed if you want to compile other MySQL clients, such as the Perl modules.
MySQL-debuginfo-VERSION.glibc23.i386.rpm, MySQL-community-debuginfo-VERSION.glibc23.i386.rpm
This package contains debugging information. debuginfo RPMs are never needed to use MySQL software; this is true both for the server and for client programs. However, they contain additional information that might be needed by a debugger to analyze a crash.
MySQL-shared-VERSION.glibc23.i386.rpm, MySQL-shared-community-VERSION.glibc23.i386.rpm
This package contains the shared libraries (libmysqlclient.so*) that certain languages and applications need to dynamically load and use MySQL. It contains single-threaded and thread-safe libraries. If you install this package, do not install the MySQL-shared-compat package.
MySQL-shared-compat-VERSION.glibc23.i386.rpm
This package includes the shared libraries for MySQL 3.23, 4.0, 4.1, and 5.0. It contains single-threaded and thread-safe libraries. Install this package instead of MySQL-shared if you have applications installed that are dynamically linked against older versions of MySQL but you want to upgrade to the current version without breaking the library dependencies.
MySQL-clustermanagement-communityVERSION.glibc23.i386.rpm, MySQL-clusterstorage-communityVERSION.glibc23.i386.rpm, MySQL-clustertools-communityVERSION.glibc23.i386.rpm, MySQL-clusterextra-communityVERSION.glibc23.i386.rpm
Packages that contain additional files for MySQL Cluster installations. These are platform-specific RPMs, in contrast to the platform-independent ndb-xxx RPMs.
Note
The MySQL-clustertools RPM requires a working installation of perl and the DBI and HTML::Template packages
MySQL-ndb-management-VERSION.glibc23.i386.rpm, MySQL-ndb-storage-VERSION.glibc23.i386.rpm, MySQL-ndb-tools-VERSION.glibc23.i386.rpm, MySQL-ndb-extra-VERSION.glibc23.i386.rpm
Packages that contain additional files for MySQL Cluster installations. These are platform-independent RPMs, in contrast to the platform-specific clusterxxx-community RPMs.
MySQL-test-community-VERSION.glibc23.i386.rpm
This package includes the MySQL test suite.
MySQL-VERSION.src.rpm
This contains the source code for all of the previous packages. It can also be used to rebuild the RPMs on other architectures (for example, Alpha or SPARC).
The suffix of RPM package names (following the VERSION value) has the following syntax:
[.PLATFORM].CPU.rpm
The PLATFORM and CPU values indicate the type of system for which the package is built. PLATFORM, if present, indicates the platform, and CPU indicates the processor type or family.
If the PLATFORM value is missing (for example, MySQL-server-VERSION .i386.rpm ), the package is statically linked against a version of glibc 2.2 that has been patched to handle larger numbers of threads with larger stack sizes than the stock library.
If PLATFORM is present, the package is dynamically linked against glibc 2.3 and the PLATFORM value indicates whether the package is platform independent or intended for a specific platform:
glibc23 Platform independent, should run on any Linux distribution that supports glibc 2.3
rhel3, rhel4 Red Hat Enterprise Linux 3 or 4
sles9, sles10
SuSE Linux Enterprise Server 9 or 10
The CPU value indicates the processor type or family for which the package is built:
i386 x86 processor, 386 and upi586 x86 processor, Pentium and upx86_64 64-bit x86 processoria64 Itanium (IA-64) processor
To see all files in an RPM package (for example, a MySQL-server RPM), run a command like this:
shell> rpm -qpl MySQL-server-VERSION.glibc23.i386.rpm
To perform a standard minimal installation, install the server and client RPMs:
shell> rpm -i MySQL-server-VERSION.glibc23.i386.rpmshell> rpm -i MySQL-client-VERSION.glibc23.i386.rpm
To install only the client programs, install just the client RPM:
shell> rpm -i MySQL-client-VERSION.glibc23.i386.rpm
RPM provides a feature to verify the integrity and authenticity of packages before installing them. If you would like to learn more about this feature.
The server RPM places data under the /var/lib/mysql directory. The RPM also creates a login account for a user named mysql (if one does not exist) to use for running the MySQL server, and creates the appropriate entries in /etc/init.d/ to start the server automatically at boot time. (This means that if you have performed a previous installation and have made changes to its startup script, you may want to make a copy of the script so that you don't lose it when you install a newer RPM.)
If you want to install the MySQL RPM on older Linux distributions that do not support initialization scripts in /etc/init.d (directly or via a symlink), you should create a symbolic link that points to the location where your initialization scripts actually are installed. For example, if that location is /etc/rc.d/init.d, use these commands before installing the RPM to create /etc/init.d as a symbolic link that points there:
shell> cd /etcshell> ln -s rc.d/init.d .
However, all current major Linux distributions should support the new directory layout that uses /etc/init.d, because it is required for LSB (Linux Standard Base) compliance.
If the RPM files that you install include MySQL-server, the mysqld server should be up and running after installation. You should be able to start using MySQL.
Note
The accounts that are listed in the MySQL grant tables initially have no passwords. After starting the server, you should set up passwords for them using the instructions.
3.0 Introduction to MySQL Administrator (Installation)
MySQL Administrator is a program for performing administrative operations, such as configuring, monitoring and starting and stopping a MySQL server, managing users and connections, performing backups, and a number of other administrative tasks.
Most tasks can be performed using a command-line client such as mysqladmin or mysql, but MySQL Administrator has the following advantages:
Its graphical user interface makes it more intuitive. It provides a better overview of the settings that are crucial for the performance,
reliability, and security of your MySQL servers.
It displays performance indicators graphically, thus making it easier to determine and tune server settings.
MySQL Administrator is designed to work with MySQL versions 4.0 and higher.
3.1 Installing Under Windows
MySQL GUI Tools run on recent 32-bit Windows NT based operating systems, including Windows 2000, XP, and 2003. They don't run on Windows NT 4 and below
Using the Windows Installer
MySQL GUI Tools can be installed on all Windows operating systems using the Windows Installer (.msi) installation package. The MSI package is contained within a ZIP archive named mysql-gui-tools-version-win32.msi, where version indicates the MySQL GUI Tools version.
To install MySQL GUI Tools, right click on the MSI file and select Install.
At the Setup Type window you may choose a complete or custom installation. If you do not wish to install all of the MySQL GUI Tools choose the custom option. Custom installation also gives you the option of installing support for languages other than English. MySQL GUI Tools supports, German, Greek, Japanese, Polish, and Brazilian Portuguese.
Unless you choose otherwise, MySQL GUI Tools are installed in C:\%PROGRAMFILES%\MySQL\MySQL Tools for version\, where %PROGRAMFILES% is the default directory for programs on your machine and version is the version number of MySQL GUI Tools. The %PROGRAMFILES%directory might be C:\Program Files or C:\programme.
3.2 Installing Under Linux
MySQL GUI Tools runs on Linux machines that have a graphical desktop installed. It is designed to run under the Gnome desktop with GTK2 and has been tested on Linux kernel versions 2.4 and 2.6. It should also run on other versions, and even on a number of Unix-like operating systems.
3.2.1 Installing the Generic Tarball
The generic tar archive allows you to install MySQL GUI Tools on most Linux distributions. The tarball file is called mysql-gui-tools-version.tar.gz, where version indicates the MySQL GUI Tools version (for example, 5.0r3).
To see all files in the tarball, run this command:
shell> tar -tzf mysql-gui-tools-version.tar.gz
To install MySQL GUI Tools, run this command:
shell> tar --directory=/opt -xzvf mysql-gui-tools-version.tar.gz
This installs the various application binaries in the directory, /opt/mysql-gui-tools-version.
If you install MySQL GUI Tools to the opt directory, icons for use with desktop shortcuts or for creating menu items are found under the opt/mysql-gui-tools-version/share/mysql-gui directory.
3.2.2 RPM Installation
In addition to a generic tarball, some distribution-specific RPMs are available. Currently these include Red Hat Enterprise Linux (RHEL) 3 and 4, Fedora Core 5 (FC5), and SuSE Linux 10.x. For FC5 and SuSE the gtkmm24 toolkit is a requirement for installing the RPM version of MySQL GUI Tools. You may also need to install the widget for displaying HTML pages. On FC5 you may install these RPMs from the command line in the following way:
shell> yum install gtkmm24 gtkhtml2
For installation on SuSE Linux:
shell> yast2 -i gtkmm24 gtkhtml2
Note
You may need root privileges to run the yast2 command.
The Red Hat RPMs are self contained so no additional packages need to be installed.
The RPM downloads are made up of the individual GUI Tools components combined into a single TAR archive. Extract the individual RPMs in the following way:
shell> tar -zxf mysql-gui-tools-version.tar.gz
This will decompress the RPM files to the current directory.
Install all the RPM files by typing:
shell> rpm -ivh mysql-*.rpm
If you install the RPM files individually, you must install the mysql-gui-tools-version.rpm file first in order to satisfy dependencies.
If you wish, you may install only one of the MySQL GUI Tools. For example, to install MySQL Administrator only, do the following:
shell> rpm -ivh mysql-gui-toolsversion.rpm mysql-administratorversion.rpm
Icons for use with desktop shortcuts or for creating menu items are found under the /usr/share/mysql-gui directory.
4.0 Running MySQL GUI Tools.
4.1 Running Under Windows.
Under Windows, the names of the executable files in the MySQL GUI Tools suite are:
MySQLAdministrator.exe MySQLQueryBrowser.exe
MySQLWorkbench.exe
MySQLMigrationTool.exe
Start any one of the MySQL GUI Tools by double clicking its desktop icon, or by selecting it from the Start menu. Alternatively, you can open a DOS window and start it from the command line. For example, you could run the MySQL Administrator in the following way:
C:\> "C:\%PROGRAMFILES%\MySQL\MySQL Tools for version\MySQLAdministrator.exe"
%PROGRAMFILES% is the default directory for programs on your machine, for example C:\Program Files or C:\programme. If your path contains spaces, you must enclose the command within quotation marks as shown above.
4.2 Connection Dialog
Once MySQL Administrator has been started, it displays a connection dialog box. Specify the MySQL server you would like to connect to, the necessary credentials, and both the host and port. You may also specify a number of other options, if required.
As an alternative to connecting to a running MySQL server, you can run MySQL Administrator in configure-service mode.
Note that MySQL Administrator will not work with MySQL servers prior to version 4.0. If you try to connect to an older server, an error message will appear, telling you that this is not possible.
If the server connection is successfully established, all of the values filled in the fields of the connection dialog will be saved for future connections. The Password field, however, will always be empty: For security reasons, the password is not stored along with the other options, unless you explicitly specify.
You can change any of the values in the connection profiles by overwriting the existing values with new ones. Similarly, if you select another connection profile, you can change any of its values. When you click the OK button after changing a profile's values, the changes are stored permanently if a successful connection to the MySQL server is established. However, the preferred method for changing a profile is to click the ... button next to the Connection drop-down box. That brings up an Options dialog window that has a Connections section for modifying connection profiles.
4.3 Server Connections
Server connections allows you to view and manage the current connections to the server (also called threads). If you have the PROCESS privilege, you can see all threads. If you have the SUPER privilege, you can also terminate threads other than your own. (Note that the SUPER privilege is available for MySQL servers as of version 4.0.3 only.) Otherwise, you can see your own threads only.
4.4 Threads
Threads allows you to view all connections to the server (threads). By default, threads are sorted by their PID (MySQL process identification number), but you can change that order by clicking on the appropriate headings (User, Host, etc.). You can select one or more threads using the mouse or the keyboard.
To reload the process list from the server, press the Refresh button.
If you have selected one or more threads, you can terminate them by clicking the Kill Thread button, or by right-clicking on that thread. Remember that you need the PROCESS privilege to see threads other than your own, and the SUPER privilege to kill threads other than your own. Furthermore, note that MySQL Administrator imposes a restriction that prevents you from terminating your own threads. On Windows, using the Kill Thread button on your own threads has no effect; on Linux, that button is disabled when selecting your own threads.
4.5 User Connections.
This tab displays all connections to the server (threads), but in a different way than the Threads tab does: You will see users rather than individual threads. The number of connections for each user is listed under Num.. Right-clicking on a username and selecting Show User Infos displays the Full Name and the Description, as specified in the User Information tab of the User Administration section. Initially, users are sorted by their MySQL Username, but you can change the order by clicking on the headings (Num., Full Name, or Description). Clicking on a username will display the individual threads of that user in the lower box of the tab, ordered by PID. Likewise, you can change the order by clicking on one of the headings.
Clicking on a user will enable the Kill User button, allowing you to terminate all threads of that user with a single click. This command is also available by right clicking on the username. Clicking on an individual thread in the lower box enables the Kill Thread button, which is used to terminate a connection. This command is also available by right clicking on a thread.
To reload the user list from the server, press the Refresh button.
4.6 User Administration
This section shows how to administer existing users, add new users, and delete existing users.
4.6.1 User Accounts
Existing users are listed in the lower left area of the sidebar. If there are many user accounts on your MySQL server, the field with the magnifying glass icon may be handy
for filtering the users you are looking for. Typing in t or T, for example, will set the filter to users whose names begin with a t. The filter works in a case-insensitive fashion.
If you are an experienced MySQL user, you will notice that users are not listed in the typical MySQL way (user@host ), but rather with their usernames only. If double clicking on a username does not show subcategories for that user, this means that the user's privileges are not restricted to a specific host, or hosts. If there are subcategories, the user's privileges are restricted to a specific host, or set of hosts. You may assign various (and different) sets of privileges, depending on the host from which the user connects to the MySQL server.
MySQL Administrator has a different concept of what a user is than MySQL has. In MySQL, a user is always identified by a username/host combination. This means that, for example, 'brian'@'%' may be a user completely different from 'brian'@'localhost'. The former might be Brian Miller, while the latter might be Brian Schultz. That distinction does not hold true for MySQL Administrator: User brian is always a particular user, no matter from which host he connects to the MySQL server. That said, 'brian'@'%' may still have privileges different from 'brian'@'localhost'.
For example, you might have a user called superuser. If double clicking on that username shows two subcategories, localhost and athena, this means that the user has a specific set of privileges if he/she connects from localhost, and a (probably different) set of privileges if he/she connects from athena.
Right clicking on a username, or on one of the subcategories a user might have, provides access to the following commands:
Add a new User : Selecting this command adds a new user with the default name New User to the user list. You will have to fill in at least a username in the
MySQL User field of the User Information tab, which, after applying this change, will also rename that user in the user accounts list.
Add Host from which the User can connect : Allows you to specify a host from which the user can connect. This command is unavailable if you highlight a subcategory.
Remove Host from which the User can connect : Allows you to remove a host from which the user can connect. If there are no sub-categories, the user will be removed (you will be prompted to confirm the removal).
Clone User : Makes a copy of the selected user, including all subcategories. The new user is called New User until you specify another name in the MySQL User field of the User Information tab. This command is useful for creating users with identical privileges.
Delete User : Allows you to delete the selected user. You will be prompted to confirm that you really want to delete that user.
Refresh User List : Rereads the user list from the MySQL server. This is helpful when other users (on other connections) are editing user accounts. Note that selecting that command will collapse all subcategories.
4.6.2 User Information
The fields in this tab are unavailable unless you either click on a username in the User Accounts area of the sidebar, or create a new user in that sidebar or using the New User button on this tab. In the former case, the fields are filled with the information stored for that user, in the latter case, all fields are empty.
Note that all fields will be stored only when you click the Apply Changes button. If you don't want to save your changes, click the Discard Changes button.
4.6.3 Schema Privileges
Schema Privileges allows you to grant privileges on a schema level. In MySQL, a schema is the same as a database. To grant privileges for a specific database, click on the database name in the left box. (You cannot select more than one database at a time.)
You may use wild cards to grant privileges on a number of schemata simultaneously. Use ‘%’ to replace multiple characters and ‘_’ to replace a single character. To use this feature, right click any database name in the schemata list, choose the Add Schema with Wildcards option from the pop-up menu and enter the pattern you wish to match. Entering m% for example, will add the entry, m% to the schemata list. Highlight this entry and any privileges granted will be granted for all schemata starting with the letter ‘m’.
4.6.4 Global Privileges
Global Privilege tab is available only if the Show Global Privileges checkbox in the Administrator Section of the Options dialog has been checked.
Under Assigned Privileges, you find the global privileges assigned to the selected user. Global means that those privileges apply to the MySQL server in general (like the Shutdown privilege), or to all databases on the server (like the SELECT privilege).
Privileges not assigned to the user are listed under Available Privileges. You can remove
privileges by selecting them in the left box, and then clicking the > button. Removed privileges will appear in the Available Privileges box. You can assign privileges by
selecting them in the Available Privileges box, and then clicking the < button.
4.6.5 Table Column Privileges.
Table Privilege tab is available only if the Show Schema Object Privileges checkbox in the Administrator section of the Options dialog has been checked. It allows you to grant privileges on a table level or on a column level.
To access the tables, double click on the schema (database) name containing that table. You will not see and cannot grant privileges on a schema level in this tab; if you want to do that, use the Global Privileges tab instead. Also, you cannot select more than one table at a time.
If you want to grant privileges on a column level, double click on the table name; this will give you access to its columns. You cannot select more than one column at a time.
Privileges not assigned to the user are listed under Available Privileges. You can remove privileges by selecting them in the left box, and then clicking the > button. Removed privileges will appear in the Available Privileges box. You can assign privileges by selecting them in the Available Privileges box, and then clicking the < button.
5. The MySQL System Tray Monitor
The MySQL System Tray Monitor is a tool that allows you to monitor the status of your local mysql server through an indicator that resides in the system tray. The MySQL System Tray Monitor also gives quick access to the various MySQL GUI tools through its context menu.
To start the MySQL System Tray Monitor, you can either execute the MySQLSystemTrayMonitor.exe application that resides in your MySQL
Administrator installation directory, or choose the MySQL System Tray Monitor option of the Tools menu.
Once the MySQL System Tray Monitor is running, it resides in the system tray and provides visual status information for your MySQL server. A green icon is displayed at the top left corner of the MySQL System Tray Monitorif the MySQL server is running, and a red icon is displayed if the service is stopped. In addition, the CPU load may optionally be displayed along the right side of the MySQL System Tray Monitor.
The MySQL System Tray Monitor
If you right-click on the MySQL System Tray Monitor, a pop-up menu will appear, listing all installed MySQL services and their individual statuses. For each service, the following options are available:
Shutdown Instance : this will begin the shutdown operation on the selected running service.
Start Instance : this will start a currently stopped server instance.
Configure Instance : this will launch the MySQL Administrator in configure service mode for the currently selected instance.
Monitoring Options : currently the Monitoring Options submenu has one available option: Ignore Instance State. Ignore Instance State will cause the MySQL System Tray Monitor to stop monitoring the selected service.
In addition to the service controls, you can also start the MySQL Query Browser and MySQL Administrator from the pop-up menu.
The Manage MySQL Instances option of the Actions menu can be used to start MySQL Administrator in configure service mode so you can manage your server configurations.
The Monitor Options menu has two options, which affect the general behavior of the MySQL System Tray Monitor. Display CPU Load determines whether the CPU usage is displayed on the right of the MySQL System Tray Monitor. Launch Monitor after Login sets the MySQL System Tray Monitorto launch when you log into Windows.
6. Backup
This section shows you how to create backup projects and to perform backups. This section will produce backup files that are plain text and composed of multiple SQL statements that can be executed to restore your database, similar to the output generated by the mysqldump utility.
Existing backup projects are listed in the lower left area of the sidebar. If there are many backup projects, the field with the magnifying glass icon can be used to filter the projects you are looking for. Typing in t or T, for example, will set the filter to projects whose names begin with a t. The filter works in a case-insensitive fashion.
You can update the list of backup projects by right clicking on a project and choosing the Refresh Backup Projects option from the drop-down menu. You can delete a backup project by right clicking on the project and choosing the Delete Backup Project(s) option from the drop-down menu.
If you are not working from a previously saved backup project, click the New Project button to create a new backup project. You cannot begin configuring a backup operation without either loading an existing project or creating a new project.
Once you have configured your backup project, you can click the Save Project button to save your project for future use. To start your backup, click the Execute Backup Now button. You will be prompted for a path and filename for the backup file, after which the backup operation will begin.
6.1 Backup Project
The Backup Project tab allows you to set the name of your backup project and also determine what data will be backed up.
You can name your project by filling out a name in the Project Name field. If you have enabled the Add Date/Time to Backup Files option in the Administrator Options dialog then the date and time of the backup will be appended to the project name automatically.
Specify a name that clearly identifies the project, such as Full Backup.The project name may contain arbitrary characters, including spaces.
To choose the databases and tables that will be backed up, select the database from the
schemata list and click the > button. Once the database is in the Backup Content list, you can uncheck specific tables that you do not wish to back up.
The Backup Project tab allows you to set the name of your backup project and also determine what data will be backed up.
You can name your project by filling out a name in the Project Name field. If you have enabled the Add Date/Time to Backup Files option in the Administrator Options dialog then the date and time of the backup will be appended to the project name automatically.
6.2 Advanced Options
The Advanced Options tab allows you to configure advanced options that affect the way the backup operation behaves. These include concurrency controls, backup type, and output formatting.
6.2.1. Backup Execution Method
The Backup Execution Method affects concurrency within the backup itself.
InnoDb Online Backup will begin a transaction before reading from the tables. Because of the InnoDB versioning system this will allow all tables to be read in a consistent state. This method is recommended when backing up InnoDB tables.
Lock all tables will cause all tables within the backup to be locked simultaneously to prevent writing. This will prevent users from writing to the tables during the backup operation and will ensure that the tables are in a consistent state. This option is recommended for MyISAM tables.
Normal Backup will lock each table individually when performing the backup. While this can have less impact on the actions of users during the backup operation, these is a potential for tables to be backed up in an inconsistent state in relation to one another. This method is not recommended unless the risk of inconsistency is minimal.
Online with binlog pos is the same as InnoDb Online Backup but also logs the current position within the binary log.
Complete Backup overrides the table selection made in the Backup Project tab and backs up all tables in the selected schema. This option can be useful when scheduling the backup of a schema that changes regularly.
6.2.2. Output File Options
The Output File Options section controls the formatting of the backup file. At present there is only one Backup Type available, the SQL Files format, which outputs a file similar to the output of the mysqldump utility.
No CREATEs will suppress CREATE DATABASE statements. This can be useful if you need to restore the data to a different database than it was backed up from.
No EXTENDED INSERTS will supress the default behavior of combining multiple inserts into a single statement (for example INSERT INTO test VALUES ('1',Some data',2234),('2','Some More Data',23444)). While the EXTENDED INSERT syntax is more efficient both in terms of storage and execution, it is not compatible with most RDBMSes.
Add DROP Statements adds DROP TABLE IF EXISTS statements to the backup file.
Note
If your backup project includes views then you must choose this option. Restoration of a view is a two step process that involves creating a dummy table with the same name as the view. This table must be dropped before the view can be recreated.
Complete INSERTs will produce full INSERT statements that include a column list (i.e. INSERT INTO tablename(columnA, columnB) VALUES(valueA, valueB)). Without this option the column list will be omitted.
Comment writes additional backup information to the backup file in the form of SQL comments.
Fully Qualified Identifiers causes MySQL Administrator to write statements in the format, schema_name.table_name, instead of writing only the object name. (Under Linux this check box is labeled Don't write full path.) Don't check this option if you plan to restore your database objects to a different database.
Compatibility mode creates backup files that are compatible with older versions of MySQL Administrator.
ANSI Quotes will cause all table and database names to be quoted with ANSI style double quotes instead of backticks.
Disable keys will add an ALTER TABLE ... DISABLE KEYS statement to the backup file before the INSERT statements that populate the tables. This allows for faster recovery by loading all data before rebuilding the index information
7. Restore
The Restore section helps with disaster recover by helping you restore backup files created using MySQL Administrator.
The backup files created by MySQL Administrator are similar but not identical to those created by mysqldump. A consequence of the differences is that MySQL Administrator cannot read dump files created by mysqldump.
7.1 The General Tab
In this tab, you specify which backup file should be restored, the character set and format, and the target location for restored tables.
To set any options on this tab, you must first open a backup file by clicking the Open Backup File button at the bottom of the window. When all options are set, you can click the Start Restore button to begin the restore process.
The following options are available:
File to restore : Specify the path and filename of the backup file. You can browse for that file by clicking the Open Backup File button.
Target Schema : You can choose the Original Schema option to have all tables restored into their original databases. You can also choose the New Schema ... option to restore all tables into a new database. Finally you can choose from one of the existing databases in the drop-down list to force all tables to be restored to that database.
Backup Type : At the moment, the only available option is SQL Files. Those are backup files containing SQL statements such as those produced by mysqldump.
Ignore Errors : Selecting this option allows a user to continue with the restore operation even if errors are encountered. However, results are not likely to be 100% correct.
Create database(s) if they don't exist : If a non-existent database is referenced it will automatically be created if this option is checked.
File Charset : Backup files created with MySQL Administrator are encoded in the utf8 character set. Backup files created with other tools such as winmysqladmin may be encoded with other character sets. Before a backup file can be successfully imported you will need to specify its character set. If you do
not know the character set of your backup file, click the Auto-Detect Character Set button to have MySQL Administrator attempt to determine it automatically.
7.2 Restore Content Tab
If you do not wish to restore all the databases or tables listed within your backup file, you can use the Restore Content tab to limit which databases and tables are restored.
To prevent a database or table from being restored, uncheck the box next to the object's name.
After clicking the Analyze Backup File Content button, a list of all databases and tables contained within the backup file will be displayed.
8. Replication Status
The Replication Status sections give you a visual overview of your MySQL replication master and slaves. The server status icons beside each machine tells you which slave machines are connected to the master and which ones are offline.
8.1 Configuring Replication Servers
To use the Replication Status section you must be connected to the server that acts as the master in your replication scheme. Your MySQL servers must be version 4 or higher to use this feature.
For a slave server to show in the Replication Status screen, it must register itself with the master server. To have a slave server register itself with the master, set the report-host option in your server configuration (my.cnf/my.ini) file
8.2 Using the Replication Status Section.
Once your servers are configured, they will appear in the Replication Status section, as seen in the following figure:
All servers are listed under the Hostname column, along with their server ID, Port, and current status.
New servers that are not currently being monitored will have an exclamation mark as their status symbol, and will be listed as a New Instance in the Status column of their entry.
Servers that are currently being monitored and are online will have a green status icon and will be listed as Available in the Status column of their entry.
Servers that are currently not in contact with the master server will have a red status icon and will be listed as Not Available.
There will be a slight delay between a slave machine going offline and having its status updated to allow for an adequate timeout in the communications between master and slave.
To start monitoring a new server that is not currently being monitored, click the Add Instance to Monitoring List button. To stop monitoring a server that is currently being monitored, click the Remove Instance from monitoring List button.
9. Storage Engines
MySQL supports several storage engines that act as handlers for different table types. MySQL storage engines include both those that handle transaction-safe tables and those that handle non-transaction-safe tables:
MyISAM manages non-transactional tables. It provides high-speed storage and retrieval, as well as fulltext searching capabilities. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.
The MEMORY storage engine provides in-memory tables. The MERGE storage engine allows a collection of identical MyISAM tables to be handled as a single table. Like MyISAM, the MEMORY and MERGE storage engines handle non-transactional tables, and both are also included in MySQL by default.
Note
The MEMORY storage engine formerly was known as the HEAP engine.
The InnoDB and BDB storage engines provide transaction-safe tables. InnoDB is included by default in all MySQL 5.0 binary distributions. In source distributions, you can enable or disable either engine by configuring MySQL as you like.
The EXAMPLE storage engine is a “stub” engine that does nothing. You can create tables with this engine, but no data can be stored in them or retrieved from them. The purpose of this engine is to serve as an example in the MySQL source code that illustrates how to begin writing new storage engines. As such, it is primarily of interest to developers.
NDBCLUSTER is the storage engine used by MySQL Cluster to implement tables that are partitioned over many computers. It is available in MySQL 5.0 binary distributions. This storage engine is currently supported on a number of Unix platforms. There will be support for this engine on other platforms, including Windows, in future MySQL releases.
The ARCHIVE storage engine is used for storing large amounts of data without indexes with a very small footprint.
The CSV storage engine stores data in text files using comma-separated values format.
The BLACKHOLE storage engine accepts but does not store data and retrievals always return an empty set.
The FEDERATED storage engine was added in MySQL 5.0.3. This engine stores data in a remote database. Currently, it works with MySQL only, using the MySQL C Client API. In future releases, we intend to enable it to connect to other data sources using other drivers or client connection methods.
When you create a new table, you can specify which storage engine to use by adding an ENGINE or TYPE table option to the CREATE TABLE statement:
CREATE TABLE t (i INT) ENGINE = INNODB;CREATE TABLE t (i INT) TYPE = MEMORY;
The older term TYPE is supported as a synonym for ENGINE for backward compatibility, but ENGINE is the preferred term and TYPE is deprecated.
If you omit the ENGINE or TYPE option, the default storage engine is used. Normally, this is MyISAM, but you can change it by using the --default-storage-engine or --default-table-type server startup option, or by setting the default-storage-engine or default-table-type option in the my.cnf configuration file.
You can set the default storage engine to be used during the current session by setting the storage_engine or table_type variable:
SET storage_engine=MYISAM;SET table_type=BDB;
When MySQL is installed on Windows using the MySQL Configuration Wizard, the InnoDB storage engine can be selected as the default instead of MyISAM.
To convert a table from one storage engine to another, use an ALTER TABLE statement that indicates the new engine:
ALTER TABLE t ENGINE = MYISAM;ALTER TABLE t TYPE = BDB;
If you try to use a storage engine that is not compiled in or that is compiled in but deactivated, MySQL instead creates a table using the default storage engine, usually MyISAM. This behavior is convenient when you want to copy tables between MySQL
servers that support different storage engines. (For example, in a replication setup, perhaps your master server supports transactional storage engines for increased safety, but the slave servers use only non-transactional storage engines for greater speed.)
This automatic substitution of the default storage engine for unavailable engines can be confusing for new MySQL users. A warning is generated whenever a storage engine is automatically changed.
For new tables, MySQL always creates an .frm file to hold the table and column definitions. The table's index and data may be stored in one or more other files, depending on the storage engine. The server creates the .frm file above the storage engine level. Individual storage engines create any additional files required for the tables that they manage.
A database may contain tables of different types. That is, tables need not all be created with the same storage engine.
Transaction-safe tables (TSTs) have several advantages over non-transaction-safe tables (NTSTs):
They are safer. Even if MySQL crashes or you get hardware problems, you can get your data back, either by automatic recovery or from a backup plus the transaction log.
You can combine many statements and accept them all at the same time with the COMMIT statement (if autocommit is disabled).
You can execute ROLLBACK to ignore your changes (if autocommit is disabled).
If an update fails, all of your changes are reverted. (With non-transaction-safe tables, all changes that have taken place are permanent.)
Transaction-safe storage engines can provide better concurrency for tables that get many updates concurrently with reads.
You can combine transaction-safe and non-transaction-safe tables in the same statements to get the best of both worlds. However, although MySQL supports several transaction-safe storage engines, for best results, you should not mix different storage engines within a transaction with autocommit disabled. For example, if you do this, changes to non-transaction-safe tables still are committed immediately and cannot be rolled back..
Non-transaction-safe tables have several advantages of their own, all of which occur because there is no transaction overhead:
Much faster Lower disk space requirements
Less memory required to perform updates
9.1 The MyISAM Storage Engine
MyISAM is the default storage engine. It is based on the older ISAM code but has many useful extensions. (Note that MySQL 5.0 does not support ISAM.)
Each MyISAM table is stored on disk in three files. The files have names that begin with the table name and have an extension to indicate the file type. An .frm file stores the table format. The data file has an .MYD (MYData) extension. The index file has an .MYI (MYIndex) extension.
To specify explicitly that you want a MyISAM table, indicate that with an ENGINE table option:
CREATE TABLE t (i INT) ENGINE = MYISAM;
The older term TYPE is supported as a synonym for ENGINE for backward compatibility, but ENGINE is the preferred term and TYPE is deprecated.
Normally, it is unnecesary to use ENGINE to specify the MyISAM storage engine. MyISAM is the default engine unless the default has been changed. To ensure that MyISAM is used in situations where the default might have been changed, include the ENGINE option explicitly.
You can check or repair MyISAM tables with the mysqlcheck client or myisamchk utility.
MyISAM tables have the following characteristics:
All data values are stored with the low byte first. This makes the data machine and operating system independent. The only requirements for binary portability are that the machine uses two's-complement signed integers and IEEE floating-point format. These requirements are widely used among mainstream machines. Binary compatibility might not be applicable to embedded systems, which sometimes have peculiar processors.
There is no significant speed penalty for storing data low byte first; the bytes in a table row normally are unaligned and it takes little more processing to read an unaligned byte in order than in reverse order. Also, the code in the server that fetches column values is not time critical compared to other code.
All numeric key values are stored with the high byte first to allow better index compression.
Large files (up to 63-bit file length) are supported on filesystems and operating systems that support large files.
There is a limit of 232 (~4.295E+09) rows in a MyISAM table. If you build MySQL with the --with-big-tables option, the row limitation is increased to (232)2 (1.844E+19) rows. Binary distributions for Unix and Linux are built with this option.
The maximum number of indexes per MyISAM table is 64. This can be changed by recompiling. Beginning with MySQL 5.0.18, you can configure the build by invoking configure with the --with-max-indexes=N option, where N is the maximum number of indexes to permit per MyISAM table. N must be less than or equal to 128. Before MySQL 5.0.18, you must change the source.
The maximum number of columns per index is 16.
The maximum key length is 1000 bytes. This can also be changed by changing the source and recompiling. For the case of a key longer than 250 bytes, a larger key block size than the default of 1024 bytes is used.
When rows are inserted in sorted order (as when you are using an AUTO_INCREMENT column), the index tree is split so that the high node only contains one key. This improves space utilization in the index tree.
Internal handling of one AUTO_INCREMENT column per table is supported. MyISAM automatically updates this column for INSERT and UPDATE operations. This makes AUTO_INCREMENT columns faster (at least 10%). Values at the top of the sequence are not reused after being deleted. (When an AUTO_INCREMENT column is defined as the last column of a multiple-column index, reuse of values deleted from the top of a sequence does occur.) The AUTO_INCREMENT value can be reset with ALTER TABLE or myisamchk.
Dynamic-sized rows are much less fragmented when mixing deletes with updates and inserts. This is done by automatically combining adjacent deleted blocks and by extending blocks if the next block is deleted.
MyISAM supports concurrent inserts: If a table has no free blocks in the middle of the data file, you can INSERT new rows into it at the same time that other threads are reading from the table. A free block can occur as a result of deleting rows or an update of a dynamic length row with more data than its current contents. When all free blocks are used up (filled in), future inserts become concurrent again.
You can put the data file and index file in different directories on different physical devices to get more speed with the DATA DIRECTORY and INDEX DIRECTORY table options to CREATE TABLE.
BLOB and TEXT columns can be indexed.
NULL values are allowed in indexed columns. This takes 0–1 bytes per key.
Each character column can have a different character set.
There is a flag in the MyISAM index file that indicates whether the table was closed correctly. If mysqld is started with the --myisam-recover option, MyISAM tables are automatically checked when opened, and are repaired if the table wasn't closed properly.
myisamchk marks tables as checked if you run it with the --update-state option. myisamchk --fast checks only those tables that don't have this mark.
myisamchk --analyze stores statistics for portions of keys, as well as for entire keys.
myisampack can pack BLOB and VARCHAR columns.
MyISAM also supports the following features:
Support for a true VARCHAR type; a VARCHAR column starts with a length stored in one or two bytes.
Tables with VARCHAR columns may have fixed or dynamic row length.
The sum of the lengths of the VARCHAR and CHAR columns in a table may be up to 64KB.
Arbitrary length UNIQUE constraints.
MyISAM Table Problems
Even though the MyISAM table format is very reliable (all changes to a table made by an SQL statement are written before the statement returns), you can still get corrupted tables if any of the following events occur:
The mysqld process is killed in the middle of a write. An unexpected computer shutdown occurs (for example, the computer is turned
off).
Hardware failures.
You are using an external program (such as myisamchk) to modify a table that is being modified by the server at the same time.
A software bug in the MySQL or MyISAM code.
Typical symptoms of a corrupt table are:
You get the following error while selecting data from the table: Incorrect key file for table: '...'. Try to repair it
Queries don't find rows in the table or return incomplete results.
You can check the health of a MyISAM table using the CHECK TABLE statement, and repair a corrupted MyISAM table with REPAIR TABLE.
9.2 The InnoDB Storage Engine.
InnoDB provides MySQL with a transaction-safe (ACID compliant) storage engine that has commit, rollback, and crash recovery capabilities. InnoDB does locking on the row level and also provides an Oracle-style consistent non-locking read in SELECT statements. These features increase multi-user concurrency and performance. There is no need for lock escalation in InnoDB because row-level locks fit in very little space. InnoDB also supports FOREIGN KEY constraints. You can freely mix InnoDB tables with tables from other MySQL storage engines, even within the same statement.
InnoDB has been designed for maximum performance when processing large data volumes. Its CPU efficiency is probably not matched by any other disk-based relational database engine.
Fully integrated with MySQL Server, the InnoDB storage engine maintains its own buffer pool for caching data and indexes in main memory. InnoDB stores its tables and indexes in a tablespace, which may consist of several files (or raw disk partitions). This is different from, for example, MyISAM tables where each table is stored using separate files. InnoDB tables can be of any size even on operating systems where file size is limited to 2GB.
InnoDB is included in binary distributions by default. The Windows Essentials installer makes InnoDB the MySQL default storage engine on Windows.
InnoDB is used in production at numerous large database sites requiring high performance. The famous Internet news site Slashdot.org runs on InnoDB. Mytrix, Inc. stores over 1TB of data in InnoDB, and another site handles an average load of 800 inserts/updates per second in InnoDB.
Creating and Using InnoDB Tables
To create an InnoDB table, specify an ENGINE = InnoDB option in the CREATE TABLE statement:
CREATE TABLE customers (a INT, b CHAR (20), INDEX (a)) ENGINE=InnoDB;
The older term TYPE is supported as a synonym for ENGINE for backward compatibility, but ENGINE is the preferred term and TYPE is deprecated.
The statement creates a table and an index on column a in the InnoDB tablespace that consists of the data files that you specified in my.cnf. In addition, MySQL creates a file customers.frm in the test directory under the MySQL database directory. Internally, InnoDB adds an entry for the table to its own data dictionary. The entry includes the database name. For example, if test is the database in which the customers table is created, the entry is for 'test/customers'. This means you can create a table of the same name customers in some other database, and the table names do not collide inside InnoDB.
You can query the amount of free space in the InnoDB tablespace by issuing a SHOW TABLE STATUS statement for any InnoDB table. The amount of free space in the tablespace appears in the Comment section in the output of SHOW TABLE STATUS. For example:
SHOW TABLE STATUS FROM test LIKE 'customers'
Note that the statistics SHOW displays for InnoDB tables are only approximate. They are used in SQL optimization. Table and index reserved sizes in bytes are accurate, though
Converting MyISAM Tables to InnoDB.
Important: Do not convert MySQL system tables in the mysql database (such as user or host) to the InnoDB type. This is an unsupported operation. The system tables must always be of the MyISAM type.
If you want all your (non-system) tables to be created as InnoDB tables, you can simply add the line default-storage-engine=innodb to the [mysqld] section of your server option file.
InnoDB does not have a special optimization for separate index creation the way the MyISAM storage engine does. Therefore, it does not pay to export and import the table and create indexes afterward. The fastest way to alter a table to InnoDB is to do the inserts directly to an InnoDB table. That is, use ALTER TABLE ... ENGINE=INNODB, or create an empty InnoDB table with identical definitions and insert the rows with INSERT INTO ... SELECT * FROM ....
If you have UNIQUE constraints on secondary keys, you can speed up a table import by turning off the uniqueness checks temporarily during the import operation:
SET UNIQUE_CHECKS=0;... import operation ...SET UNIQUE_CHECKS=1;
For big tables, this saves a lot of disk I/O because InnoDB can then use its insert buffer to write secondary index records as a batch. Be certain that the data contains no duplicate keys. UNIQUE_CHECKS allows but does not require storage engines to ignore duplicate keys.
To get better control over the insertion process, it might be good to insert big tables in pieces:
INSERT INTO newtable SELECT * FROM oldtable WHERE yourkey > something AND yourkey <= somethingelse;
After all records have been inserted, you can rename the tables.
During the conversion of big tables, you should increase the size of the InnoDB buffer pool to reduce disk I/O. Do not use more than 80% of the physical memory, though. You can also increase the sizes of the InnoDB log files.
Make sure that you do not fill up the tablespace: InnoDB tables require a lot more disk space than MyISAM tables. If an ALTER TABLE operation runs out of space, it starts a rollback, and that can take hours if it is disk-bound. For inserts, InnoDB uses the insert buffer to merge secondary index records to indexes in batches. That saves a lot of disk I/O. For rollback, no such mechanism is used, and the rollback can take 30 times longer than the insertion.
In the case of a runaway rollback, if you do not have valuable data in your database, it may be advisable to kill the database process rather than wait for millions of disk I/O operations to complete
9.3 The MERGE Storage Engine
The MERGE storage engine, also known as the MRG_MyISAM engine, is a collection of identical MyISAM tables that can be used as one. “Identical” means that all tables have identical column and index information. You cannot merge MyISAM tables in which the columns are listed in a different order, do not have exactly the same columns, or have the indexes in different order. However, any or all of the MyISAM tables can be compressed with myisampack.
When you create a MERGE table, MySQL creates two files on disk. The files have names that begin with the table name and have an extension to indicate the file type. An .frm file stores the table format, and an .MRG file contains the names of the tables that should be used as one. The tables do not have to be in the same database as the MERGE table itself.
Starting with MySQL 5.0.36 the underlying table definitions and indexes must conform more closely to the definition of the MERGE table. Conformance will be checked when the merged tables are opened, not when the MERGE table is created. This means that changes to the definitions of tables within a MERGE may cause a failure when the MERGE table is accessed.
You can use SELECT, DELETE, UPDATE, and INSERT on MERGE tables. You must have SELECT, UPDATE, and DELETE privileges on the MyISAM tables that you map to a MERGE table
Note
The use of MERGE tables entails the following security issue: If a user has access to MyISAM table t, that user can create a MERGE table m that accesses t. However, if the user's privileges on t are subsequently revoked, the user can continue to access t by doing so through m. If this behavior is undesirable, you can start the server with the new --skip-merge option to disable the MERGE storage engine. This option is available as of MySQL 5.0.24.
If you DROP the MERGE table, you are dropping only the MERGE specification. The underlying tables are not affected.
To create a MERGE table, you must specify a UNION=(list-of-tables) clause that indicates which MyISAM tables you want to use as one. You can optionally specify an INSERT_METHOD option if you want inserts for the MERGE table to take place in the first or last table of the UNION list. Use a value of FIRST or LAST to cause inserts to be made in the first or last table, respectively. If you do not specify an INSERT_METHOD option or if you specify it with a value of NO, attempts to insert rows into the MERGE table result in an error.
The following example shows how to create a MERGE table:
mysql> CREATE TABLE t1 ( -> a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, -> message CHAR(20)) ENGINE=MyISAM;mysql> CREATE TABLE t2 ( -> a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, -> message CHAR(20)) ENGINE=MyISAM;
mysql> INSERT INTO t1 (message) VALUES ('Testing'),('table'),('t1');mysql> INSERT INTO t2 (message) VALUES ('Testing'),('table'),('t2');mysql> CREATE TABLE total ( -> a INT NOT NULL AUTO_INCREMENT, -> message CHAR(20), INDEX(a)) -> ENGINE=MERGE UNION=(t1,t2) INSERT_METHOD=LAST;
The older term TYPE is supported as a synonym for ENGINE for backward compatibility, but ENGINE is the preferred term and TYPE is deprecated.
Note that the a column is indexed as a PRIMARY KEY in the underlying MyISAM tables, but not in the MERGE table. There it is indexed but not as a PRIMARY KEY because a MERGE table cannot enforce uniqueness over the set of underlying tables.
In MySQL 5.0.36 and higher, when a table that is part of a MERGE table is opened, the following checks are applied before opening each table. If any table fails the conformance checks, then the operation that triggered the opening of the table will fail. The conformance checks applied to each table are:
Table must have exactly the same amount of columns that MERGE table has. Column order in the MERGE table must match the column order in the underlying
tables.
Additionally, the specification for each column in the parent MERGE table and the underlying table are compared. For each column, MySQL checks:
o Column type in the underlying table equals the column type of MERGE table.
o Column length in the underlying table equals the column length of MERGE table.
o Column of underlying table and column of MERGE table can be NULL.
Underlying table must have at least the same amount of keys that merge table has. The underlying table may have morekeys than the MERGE table, but cannot have less.
Note
A known issue exists that keys on the some columns must be identical in order in both the MERGE table and the underlying MyISAM table.
For each key:
o Check if the key type of underlying table equals the key type of merge table.
o Check if number of key parts (i.e. multiple columns within a compound key) in the underlying table key definition equals the number of key parts in merge table key definition.
o For each key part:
Check if key part lengths are equal.
Check if key part types are equal.
Check if key part languages are equal.
Check if key part can be NULL.
After creating the MERGE table, you can issue queries that operate on the group of tables as a whole:
mysql> SELECT * FROM total;+---+---------+| a | message |+---+---------+| 1 | Testing || 2 | table || 3 | t1 || 1 | Testing || 2 | table || 3 | t2 |+---+---------+
To remap a MERGE table to a different collection of MyISAM tables, you can use one of the following methods:
DROP the MERGE table and re-create it. Use ALTER TABLE tbl_name UNION=(...) to change the list of underlying
tables.
Beginning with MySQL 5.0.60, it is also possible to use ALTER TABLE ... UNION=() (that is, with an empty UNION clause) to remove all of the underlying tables.
MERGE tables can help you solve the following problems:
Easily manage a set of log tables. For example, you can put data from different months into separate tables, compress some of them with myisampack, and then create a MERGE table to use them as one.
Obtain more speed. You can split a big read-only table based on some criteria, and then put individual tables on different disks. A MERGE table on this could be much faster than using the big table.
Perform more efficient searches. If you know exactly what you are looking for, you can search in just one of the split tables for some queries and use a MERGE table for others. You can even have many different MERGE tables that use overlapping sets of tables.
Perform more efficient repairs. It is easier to repair individual tables that are mapped to a MERGE table than to repair a single large table.
Instantly map many tables as one. A MERGE table need not maintain an index of its own because it uses the indexes of the individual tables. As a result, MERGE table collections are very fast to create or remap. (Note that you must still specify the index definitions when you create a MERGE table, even though no indexes are created.)
If you have a set of tables from which you create a large table on demand, you should instead create a MERGE table on them on demand. This is much faster and saves a lot of disk space.
Exceed the file size limit for the operating system. Each MyISAM table is bound by this limit, but a collection of MyISAM tables is not.
You can create an alias or synonym for a MyISAM table by defining a MERGE table that maps to that single table. There should be no really notable performance impact from doing this (only a couple of indirect calls and memcpy() calls for each read).
The disadvantages of MERGE tables are:
You can use only identical MyISAM tables for a MERGE table. You cannot use a number of MyISAM features in MERGE tables. For example, you
cannot create FULLTEXT indexes on MERGE tables. (You can, of course, create FULLTEXT indexes on the underlying MyISAM tables, but you cannot search the MERGE table with a full-text search.)
If the MERGE table is non-temporary, all underlying MyISAM tables must be non-temporary, too. If the MERGE table is temporary, the MyISAM tables can be any mix of temporary and non-temporary.
MERGE tables use more file descriptors. If 10 clients are using a MERGE table that maps to 10 tables, the server uses (10 × 10) + 10 file descriptors. (10 data file descriptors for each of the 10 clients, and 10 index file descriptors shared among the clients.)
Key reads are slower. When you read a key, the MERGE storage engine needs to issue a read on all underlying tables to check which one most closely matches the given key. To read the next key, the MERGE storage engine needs to search the read buffers to find the next key. Only when one key buffer is used up does the storage engine need to read the next key block. This makes MERGE keys much slower on eq_ref searches, but not much slower on ref searches.
9.4 The MEMORY (HEAP) Storage Engine
The MEMORY storage engine creates tables with contents that are stored in memory. Formerly, these were known as HEAP tables. MEMORY is the preferred term, although HEAP remains supported for backward compatibility.
Each MEMORY table is associated with one disk file. The filename begins with the table name and has an extension of .frm to indicate that it stores the table definition.
To specify explicitly that you want to create a MEMORY table, indicate that with an ENGINE table option:
CREATE TABLE t (i INT) ENGINE = MEMORY;
The older term TYPE is supported as a synonym for ENGINE for backward compatibility, but ENGINE is the preferred term and TYPE is deprecated.
As indicated by the name, MEMORY tables are stored in memory. They use hash indexes by default, which makes them very fast, and very useful for creating temporary tables. However, when the server shuts down, all rows stored in MEMORY tables are lost. The tables themselves continue to exist because their definitions are stored in .frm files on disk, but they are empty when the server restarts.
This example shows how you might create, use, and remove a MEMORY table:
mysql> CREATE TABLE test ENGINE=MEMORY -> SELECT ip,SUM(downloads) AS down -> FROM log_table GROUP BY ip;mysql> SELECT COUNT(ip),AVG(down) FROM test;mysql> DROP TABLE test;
MEMORY tables have the following characteristics:
Space for MEMORY tables is allocated in small blocks. Tables use 100% dynamic hashing for inserts. No overflow area or extra key space is needed. No extra space is needed for free lists. Deleted rows are put in a linked list and are reused when you insert new data into the table. MEMORY tables also have none of the problems commonly associated with deletes plus inserts in hashed tables.
MEMORY tables can have up to 32 indexes per table, 16 columns per index and a maximum key length of 500 bytes.
The MEMORY storage engine implements both HASH and BTREE indexes. You can specify one or the other for a given index by adding a USING clause as shown here:
CREATE TABLE lookup (id INT, INDEX USING HASH (id)) ENGINE = MEMORY;CREATE TABLE lookup (id INT, INDEX USING BTREE (id)) ENGINE = MEMORY;
You can have non-unique keys in a MEMORY table. (This is an uncommon feature for implementations of hash indexes.)
If you have a hash index on a MEMORY table that has a high degree of key duplication (many index entries containing the same value), updates to the table that affect key values and all deletes are significantly slower. The degree of this slowdown is proportional to the degree of duplication (or, inversely proportional to the index cardinality). You can use a BTREE index to avoid this problem.
Columns that are indexed can contain NULL values.
MEMORY tables use a fixed-length row storage format.
MEMORY tables cannot contain BLOB or TEXT columns.
MEMORY includes support for AUTO_INCREMENT columns.
You can use INSERT DELAYED with MEMORY tables.
MEMORY tables are shared among all clients (just like any other non-TEMPORARY table).
MEMORY table contents are stored in memory, which is a property that MEMORY tables share with internal tables that the server creates on the fly while processing queries. However, the two types of tables differ in that MEMORY tables are not subject to storage conversion, whereas internal tables are:
o If an internal table becomes too large, the server automatically converts it to an on-disk table. The size limit is determined by the value of the tmp_table_size system variable.
o MEMORY tables are never converted to disk tables.
o The maximum size of MEMORY tables is limited by the max_heap_table_size system variable, which has a default value of 16MB. To have larger (or smaller) MEMORY tables, you must change the value of this variable. The value in effect at the time a MEMORY table is created is the value used for the life of the table. (If you use ALTER TABLE or TRUNCATE TABLE, the value in effect at that time becomes the new maximum size for the table. A server restart also sets the maximum size of existing MEMORY tables to the global max_heap_table_size value.) You can set the size for individual tables as described later in this section.
The server needs sufficient memory to maintain all MEMORY tables that are in use at the same time.
Memory used by a MEMORY table is not reclaimed if you delete individual rows from the table. Memory is only reclaimed when the entire table is deleted. Memory that was previously used for rows that have been deleted will be re-used for new rows only within the same table. To free up the memory used by rows that have been deleted you should use ALTER TABLE ENGINE=MEMORY to force a table rebuild.
To free all the memory used by a MEMORY table when you no longer require its contents, you should execute DELETE or TRUNCATE TABLE, or remove the table altogether using DROP TABLE.
If you want to populate a MEMORY table when the MySQL server starts, you can use the --init-file option. For example, you can put statements such as INSERT INTO ... SELECT or LOAD DATA INFILE into this file to load the table from a persistent data source
If you are using replication, the master server's MEMORY tables become empty when it is shut down and restarted. However, a slave is not aware that these tables have become empty, so it returns out-of-date content if you select data from them. When a MEMORY table is used on the master for the first time since the master was started, a DELETE statement is written to the master's binary log automatically, thus synchronizing the slave to the master again. Note that even with this strategy, the slave still has outdated data in the table during the interval between the master's restart and its first use of the table. However, if you use the --init-file option to populate the MEMORY table on the master at startup, it ensures that this time interval is zero.
The memory needed for one row in a MEMORY table is calculated using the following expression:
SUM_OVER_ALL_BTREE_KEYS(max_length_of_key + sizeof(char*) × 4) + SUM_OVER_ALL_HASH_KEYS(sizeof(char*) × 2) + ALIGN(length_of_row+1, sizeof(char*))
ALIGN() represents a round-up factor to cause the row length to be an exact multiple of the char pointer size. sizeof(char*) is 4 on 32-bit machines and 8 on 64-bit machines.
As mentioned earlier, the max_heap_table_size system variable sets the limit on the maximum size of MEMORY tables. To control the maximum size for individual tables, set the session value of this variable before creating each table. (Do not change the global max_heap_table_size value unless you intend the value to be used for MEMORY tables created by all clients.) The following example creates two MEMORY tables, with a maximum size of 1MB and 2MB, respectively:
mysql> SET max_heap_table_size = 1024*1024;
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE TABLE t1 (id INT, UNIQUE(id)) ENGINE = MEMORY;Query OK, 0 rows affected (0.01 sec)
mysql> SET max_heap_table_size = 1024*1024*2;Query OK, 0 rows affected (0.00 sec)
mysql> CREATE TABLE t2 (id INT, UNIQUE(id)) ENGINE = MEMORY;Query OK, 0 rows affected (0.00 sec)
Both tables will revert to the server's global max_heap_table_size value if the server restarts.
You can also specify a MAX_ROWS table option in CREATE TABLE statements for MEMORY tables to provide a hint about the number of rows you plan to store in them. This does not allow the table to grow beyond the max_heap_table_size value, which still acts as a constraint on maximum table size. For maximum flexibility in being able to use MAX_ROWS, set max_heap_table_size at least as high as the value to which you want each MEMORY table to be able to grow.
9.5 The BDB (BerkeleyDB) Storage Engine.
Sleepycat Software has provided MySQL with the Berkeley DB transactional storage engine. This storage engine typically is called BDB for short. BDB tables may have a greater chance of surviving crashes and are also capable of COMMIT and ROLLBACK operations on transactions.
Currently, we know that the BDB storage engine works with the following operating systems:
Linux 2.x Intel Sun Solaris (SPARC and x86)
FreeBSD 4.x/5.x (x86, sparc64)
IBM AIX 4.3.x
SCO OpenServer
SCO UnixWare 7.1.x
Windows
The BDB storage engine does not work with the following operating systems:
Linux 2.x Alpha Linux 2.x AMD64
Linux 2.x IA-64
Linux 2.x s390
Mac OS X
Characteristics of BDB Tables
Each BDB table is stored on disk in two files. The files have names that begin with the table name and have an extension to indicate the file type. An .frm file stores the table format, and a .db file contains the table data and indexes.
To specify explicitly that you want a BDB table, indicate that with an ENGINE table option:
CREATE TABLE t (i INT) ENGINE = BDB;
The older term TYPE is supported as a synonym for ENGINE for backward compatibility, but ENGINE is the preferred term and TYPE is deprecated.
BerkeleyDB is a synonym for BDB in the ENGINE table option.
The BDB storage engine provides transactional tables. The way you use these tables depends on the autocommit mode:
If you are running with autocommit enabled (which is the default), changes to BDB tables are committed immediately and cannot be rolled back.
If you are running with autocommit disabled, changes do not become permanent until you execute a COMMIT statement. Instead of committing, you can execute ROLLBACK to forget the changes.
You can start a transaction with the START TRANSACTION or BEGIN statement to suspend autocommit, or with SET AUTOCOMMIT=0 to disable autocommit explicitly.
The BDB storage engine has the following characteristics:
BDB tables can have up to 31 indexes per table, 16 columns per index, and a maximum key size of 1024 bytes.
MySQL requires a primary key in each BDB table so that each row can be uniquely identified. If you don't create one explicitly by declaring a PRIMARY KEY, MySQL creates and maintains a hidden primary key for you. The hidden key has a length of five bytes and is incremented for each insert attempt. This key does not appear in the output of SHOW CREATE TABLE or DESCRIBE.
The primary key is faster than any other index, because it is stored together with the row data. The other indexes are stored as the key data plus the primary key, so it's important to keep the primary key as short as possible to save disk space and get better speed.
This behavior is similar to that of InnoDB, where shorter primary keys save space not only in the primary index but in secondary indexes as well.
If all columns that you access in a BDB table are part of the same index or part of the primary key, MySQL can execute the query without having to access the actual row. In a MyISAM table, this can be done only if the columns are part of the same index.
Sequential scanning is slower for BDB tables than for MyISAM tables because the data in BDB tables is stored in B-trees and not in a separate data file.
Key values are not prefix- or suffix-compressed like key values in MyISAM tables. In other words, key information takes a little more space in BDB tables compared to MyISAM tables.
There are often holes in the BDB table to allow you to insert new rows in the middle of the index tree. This makes BDB tables somewhat larger than MyISAM tables.
SELECT COUNT(*) FROM tbl_name is slow for BDB tables, because no row count is maintained in the table.
The optimizer needs to know the approximate number of rows in the table. MySQL solves this by counting inserts and maintaining this in a separate segment in each BDB table. If you don't issue a lot of DELETE or ROLLBACK statements, this number should be accurate enough for the MySQL optimizer. However, MySQL stores the number only on close, so it may be incorrect if the server terminates unexpectedly. It should not be fatal even if this number is not 100% correct. You can update the row count by using ANALYZE TABLE or OPTIMIZE TABLE.
Internal locking in BDB tables is done at the page level.
LOCK TABLES works on BDB tables as with other tables. If you do not use LOCK TABLES, MySQL issues an internal multiple-write lock on the table (a lock that does not block other writers) to ensure that the table is properly locked if another thread issues a table lock.
To support transaction rollback, the BDB storage engine maintains log files. For maximum performance, you can use the --bdb-logdir option to place the BDB logs on a different disk than the one where your databases are located.
MySQL performs a checkpoint each time a new BDB log file is started, and removes any BDB log files that are not needed for current transactions. You can also use FLUSH LOGS at any time to checkpoint the Berkeley DB tables.
For disaster recovery, you should use table backups plus MySQL's binary log
Warning
If you delete old log files that are still in use, BDB is not able to do recovery at all and you may lose data if something goes wrong.
Applications must always be prepared to handle cases where any change of a BDB table may cause an automatic rollback and any read may fail with a deadlock error.
If you get a full disk with a BDB table, you get an error (probably error 28) and the transaction should roll back. This contrasts with MyISAM tables, for which mysqld waits for sufficient free disk space before continuing
Restrictions on BDB Tables
The following list indicates restrictions that you must observe when using BDB tables:
Each BDB table stores in its .db file the path to the file as it was created. This is done to enable detection of locks in a multi-user environment that supports symlinks. As a consequence of this, it is not possible to move BDB table files from one database directory to another.
When making backups of BDB tables, you must either use mysqldump or else make a backup that includes the files for each BDB table (the .frm and .db files) as well as the BDB log files. The BDB storage engine stores unfinished transactions in its log files and requires them to be present when mysqld starts. The BDB logs are the files in the data directory with names of the form log.NNNNNNNNNN (ten digits).
If a column that allows NULL values has a unique index, only a single NULL value is allowed. This differs from other storage engines, which allow multiple NULL values in unique indexes.
9.5 The EXAMPLE Storage Engine
The EXAMPLE storage engine is a stub engine that does nothing. Its purpose is to serve as an example in the MySQL source code that illustrates how to begin writing new storage engines. As such, it is primarily of interest to developers.
The EXAMPLE storage engine is included in MySQL binary distributions. To enable this storage engine if you build MySQL from source, invoke configure with the --with-example-storage-engine option.
To examine the source for the EXAMPLE engine, look in the sql/examples directory of a MySQL source distribution.
When you create an EXAMPLE table, the server creates a table format file in the database directory. The file begins with the table name and has an .frm extension. No other files are created. No data can be stored into the table. Retrievals return an empty result.
mysql> CREATE TABLE test (i INT) ENGINE = EXAMPLE;Query OK, 0 rows affected (0.78 sec)
mysql> INSERT INTO test VALUES(1),(2),(3);ERROR 1031 (HY000): Table storage engine for 'test' doesn't have this option
mysql> SELECT * FROM test;Empty set (0.31 sec)
The EXAMPLE storage engine does not support indexing
9.6 The FEDERATED Storage Engine
The FEDERATED storage engine is available beginning with MySQL 5.0.3. It is a storage engine that accesses data in tables of remote databases rather than in local tables.
The FEDERATED storage engine is included in MySQL binary distributions. To enable this storage engine if you build MySQL from source, invoke configure with the --with-federated-storage-engine option
When you create a FEDERATED table, the server creates a table format file in the database directory. The file begins with the table name and has an .frm extension. No other files are created, because the actual data is in a remote table. This differs from the way that storage engines for local tables work.
For local database tables, data files are local. For example, if you create a MyISAM table named users, the MyISAM handler creates a data file named users.MYD. A handler for local tables reads, inserts, deletes, and updates data in local data files, and rows are stored in a format particular to the handler. To read rows, the handler must parse data into columns. To write rows, column values must be converted to the row format used by the handler and written to the local data file.
With the MySQL FEDERATED storage engine, there are no local data files for a table (for example, there is no .MYD file). Instead, a remote database stores the data that normally would be in the table. The local server connects to a remote server, and uses the MySQL client API to read, delete, update, and insert data in the remote table. For example, data retrieval is initiated via a SELECT * FROM tbl_name SQL statement.
When a client issues a SQL statement that refers to a FEDERATED table, the flow of information between the local server (where the SQL statement is executed) and the remote server (where the data is physically stored) is as follows:
1. The storage engine looks through each column that the FEDERATED table has and constructs an appropriate SQL statement that refers to the remote table.
2. The statement is sent to the remote server using the MySQL client API.
3. The remote server processes the statement and the the local server retrieves any result that the statement produces (an affected-rows count or a result set).
4. If the statement produces a result set, each column is converted to internal storage engine format that the FEDERATED engine expects and can use to display the result to the client that issued the original statement.
The local server communicates with the remote server using MySQL client C API functions. It invokes mysql_real_query() to send the statement. To read a result set, it uses mysql_store_result() and fetches rows one at a time using mysql_fetch_row().
Using Federated Tables
The procedure for using FEDERATED tables is very simple. Normally, you have two servers running, either both on the same host or on different hosts. (It is possible for a FEDERATED table to use another table that is managed by the same server, although there is little point in doing so.)
First, you must have a table on the remote server that you want to access by using a FEDERATED table. Suppose that the remote table is in the federated database and is defined like this:
CREATE TABLE test_table ( id INT(20) NOT NULL AUTO_INCREMENT, name VARCHAR(32) NOT NULL DEFAULT '', other INT(20) NOT NULL DEFAULT '0', PRIMARY KEY (id), INDEX name (name), INDEX other_key (other))ENGINE=MyISAMDEFAULT CHARSET=latin1;
The example uses a MyISAM table, but the table could use any storage engine.
Next, create a FEDERATED table on the local server for accessing the remote table:
CREATE TABLE federated_table ( id INT(20) NOT NULL AUTO_INCREMENT, name VARCHAR(32) NOT NULL DEFAULT '', other INT(20) NOT NULL DEFAULT '0', PRIMARY KEY (id), INDEX name (name), INDEX other_key (other))ENGINE=FEDERATEDDEFAULT CHARSET=latin1CONNECTION='mysql://fed_user@remote_host:9306/federated/test_table';
(Before MySQL 5.0.13, use COMMENT rather than CONNECTION.)
The structure of this table must be exactly the same as that of the remote table, except that the ENGINE table option should be FEDERATED and the CONNECTION table option is a connection string that indicates to the FEDERATED engine how to connect to the remote server.
The FEDERATED engine creates only the test_table.frm file in the federated database.
The remote host information indicates the remote server to which your local server connects, and the database and table information indicates which remote table to use as the data source. In this example, the remote server is indicated to be running as
remote_host on port 9306, so there must be a MySQL server running on the remote host and listening to port 9306.
The general form of the connection string in the CONNECTION option is as follows:
scheme://user_name[:password]@host_name[:port_num]/db_name/tbl_name
Only mysql is supported as the scheme value at this point; the password and port number are optional.
Sample connection strings:
CONNECTION='mysql://username:password@hostname:port/database/tablename'CONNECTION='mysql://username@hostname/database/tablename'CONNECTION='mysql://username:password@hostname/database/tablename'
The use of CONNECTION for specifying the connection string is non-optimal and is likely to change in future. Keep this in mind for applications that use FEDERATED tables. Such applications are likely to need modification if the format for specifying connection information changes.
Because any password given in the connection string is stored as plain text, it can be seen by any user who can use SHOW CREATE TABLE or SHOW TABLE STATUS for the FEDERATED table, or query the TABLES table in the INFORMATION_SCHEMA database.
Limitations of the FEDERATED Storage Engine.
The following items indicate features that the FEDERATED storage engine does and does not support:
The remote server must be a MySQL server. Support by FEDERATED for other database engines may be added in the future.
The remote table that a FEDERATED table points to must exist before you try to access the table through the FEDERATED table.
It is possible for one FEDERATED table to point to another, but you must be careful not to create a loop.
There is no support for transactions.
A FEDERATED table does not support indexes per se. Because access to the table is handled remotely, it is the remote table that supports the indexes. Care should be taken when creating a FEDERATED table since the index definition from an equivalent MyISAM or other table may not be supported. For example, creating a
FEDERATED table with an index prefix on VARCHAR, TEXT or BLOB columns will fail. The following definition in MyISAM is valid:
CREATE TABLE `T1`(`A` VARCHAR(100),UNIQUE KEY(`A`(30))) ENGINE=MYISAM;
The key prefix in this example is incompatible with the FEDERATED engine, and the equivalent statement will fail:
CREATE TABLE `T1`(`A` VARCHAR(100),UNIQUE KEY(`A`(30))) ENGINE=FEDERATED CONNECTION='MYSQL://127.0.0.1:3306/TEST/T1';
If possible, you should try to separate the column and index definition when creating tables on both the remote server and the local server to avoid these index issues.
Internally, the implementation uses SELECT, INSERT, UPDATE, and DELETE, but not HANDLER.
The FEDERATED storage engine supports SELECT, INSERT, UPDATE, DELETE, and indexes. It does not support ALTER TABLE, or any Data Definition Language statements that directly affect the structure of the table, other than DROP TABLE. The current implementation does not use prepared statements.
FEDERATED accepts INSERT ... ON DUPLICATE KEY UPDATE statements, but if a duplicate-key violation occurs, the statement fails with an error.
Performance on a FEDERATED table when performing bulk inserts (for example, on a INSERT INTO ... SELECT ... statement) is slower than with other table types because each selected row is treated as an individual INSERT statement on the federated table.
Before MySQL 5.0.46, for a multiple-row insert into a FEDERATED table that refers to a remote transactional table, if the insert failed for a row due to constraint failure, the remote table would contain a partial commit (the rows preceding the failed one) instead of rolling back the statement completely. This occurred because the rows were treated as individual inserts.
As of MySQL 5.0.46, FEDERATED performs bulk-insert handling such that multiple rows are sent to the remote table in a batch. This provides a performance improvement. Also, if the remote table is transactional, it enables the remote storage engine to perform statement rollback properly should an error occur. This capability has the following limitations:
o The size of the insert cannot exceed the maximum packet size between servers. If the insert exceeds this size, it is broken into multiple packets and the rollback problem can occur.
o Bulk-insert handling does not occur for INSERT ... ON DUPLICATE KEY UPDATE.
There is no way for the FEDERATED engine to know if the remote table has changed. The reason for this is that this table must work like a data file that would never be written to by anything other than the database system. The integrity of the data in the local table could be breached if there was any change to the remote database.
Any DROP TABLE statement issued against a FEDERATED table drops only the local table, not the remote table.
FEDERATED tables do not work with the query cache.
9.7 The ARCHIVE Storage Engine
The ARCHIVE storage engine is used for storing large amounts of data without indexes in a very small footprint.
The ARCHIVE storage engine is included in MySQL binary distributions. To enable this storage engine if you build MySQL from source, invoke configure with the --with-archive-storage-engine option.
To examine the source for the ARCHIVE engine, look in the sql directory of a MySQL source distribution.
You can check whether the ARCHIVE storage engine is available with this statement:
mysql> SHOW VARIABLES LIKE 'have_archive';
When you create an ARCHIVE table, the server creates a table format file in the database directory. The file begins with the table name and has an .frm extension. The storage engine creates other files, all having names beginning with the table name. The data and metadata files have extensions of .ARZ and .ARM, respectively. An .ARN file may appear during optimization operations.
The ARCHIVE engine supports INSERT and SELECT, but not DELETE, REPLACE, or UPDATE. It does support ORDER BY operations, BLOB columns, and basically all but spatial data types. The ARCHIVE engine uses row-level locking.
Storage: Rows are compressed as they are inserted. The ARCHIVE engine uses zlib lossless data compression. You can use OPTIMIZE TABLE to analyze the table and pack
it into a smaller format (for a reason to use OPTIMIZE TABLE, see later in this section). Beginning with MySQL 5.0.15, the engine also supports CHECK TABLE. There are several types of insertions that are used:
An INSERT statement just pushes rows into a compression buffer, and that buffer flushes as necessary. The insertion into the buffer is protected by a lock. A SELECT forces a flush to occur, unless the only insertions that have come in were INSERT DELAYED (those flush as necessary).
A bulk insert is visible only after it completes, unless other inserts occur at the same time, in which case it can be seen partially. A SELECT never causes a flush of a bulk insert unless a normal insert occurs while it is loading.
Retrieval: On retrieval, rows are uncompressed on demand; there is no row cache. A SELECT operation performs a complete table scan: When a SELECT occurs, it finds out how many rows are currently available and reads that number of rows. SELECT is performed as a consistent read. Note that lots of SELECT statements during insertion can deteriorate the compression, unless only bulk or delayed inserts are used. To achieve better compression, you can use OPTIMIZE TABLE or REPAIR TABLE. The number of rows in ARCHIVE tables reported by SHOW TABLE STATUS is always accurate
9.8 The CSV Storage Engine
The CSV storage engine stores data in text files using comma-separated values format. It is unavailable on Windows until MySQL 5.1.
The CSV storage engine is included in MySQL binary distributions (except on Windows). To enable this storage engine if you build MySQL from source, invoke configure with the --with-csv-storage-engine option.
To examine the source for the CSV engine, look in the sql/examples directory of a MySQL source distribution.
When you create a CSV table, the server creates a table format file in the database directory. The file begins with the table name and has an .frm extension. The storage engine also creates a data file. Its name begins with the table name and has a .CSV extension. The data file is a plain text file. When you store data into the table, the storage engine saves it into the data file in comma-separated values format.
mysql> CREATE TABLE test (i INT NOT NULL, c CHAR(10) NOT NULL) -> ENGINE = CSV;Query OK, 0 rows affected (0.12 sec)
mysql> INSERT INTO test VALUES(1,'record one'),(2,'record two');Query OK, 2 rows affected (0.00 sec)Records: 2 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM test;+------+------------+| i | c |+------+------------+| 1 | record one || 2 | record two |+------+------------+2 rows in set (0.00 sec)
If you examine the test.CSV file in the database directory created by executing the preceding statements, its contents should look like this:
"1","record one""2","record two"
This format can be read, and even written, by spreadsheet applications such as Microsoft Excel or StarOffice Calc.
The CSV storage engine does not support indexing.
9.9 The BLACKHOLE Storage Engine
The BLACKHOLE storage engine acts as a “black hole” that accepts data but throws it away and does not store it. Retrievals always return an empty result:
mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;Query OK, 0 rows affected (0.03 sec)
mysql> INSERT INTO test VALUES(1,'record one'),(2,'record two');Query OK, 2 rows affected (0.00 sec)Records: 2 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM test;Empty set (0.00 sec)
The BLACKHOLE storage engine is included in MySQL binary distributions. To enable this storage engine if you build MySQL from source, invoke configure with the --with-blackhole-storage-engine option.
To examine the source for the BLACKHOLE engine, look in the sql directory of a MySQL source distribution.
When you create a BLACKHOLE table, the server creates a table format file in the database directory. The file begins with the table name and has an .frm extension. There are no other files associated with the table.
The BLACKHOLE storage engine supports all kinds of indexes. That is, you can include index declarations in the table definition.
You can check whether the BLACKHOLE storage engine is available with this statement:
mysql> SHOW VARIABLES LIKE 'have_blackhole_engine';
Inserts into a BLACKHOLE table do not store any data, but if the binary log is enabled, the SQL statements are logged (and replicated to slave servers). This can be useful as a repeater or filter mechanism. For example, suppose that your application requires slave-side filtering rules, but transferring all binary log data to the slave first results in too much traffic. In such a case, it is possible to set up on the master host a “dummy” slave process whose default storage engine is BLACKHOLE, depicted as follows:
The master writes to its binary log. The “dummy” mysqld process acts as a slave, applying the desired combination of replicate-do-* and replicate-ignore-* rules, and writes a new, filtered binary log of its own. This filtered log is provided to the slave.
The dummy process does not actually store any data, so there is little processing overhead incurred by running the additional mysqld process on the replication master host. This type of setup can be repeated with additional replication slaves.
INSERT triggers for BLACKHOLE tables work as expected. However, because the BLACKHOLE table does not actually store any data, UPDATE and DELETE triggers are not
activated: The FOR EACH ROW clause in the trigger definition does not apply because there are no rows.
Other possible uses for the BLACKHOLE storage engine include:
Verification of dump file syntax. Measurement of the overhead from binary logging, by comparing performance
using BLACKHOLE with and without binary logging enabled.
BLACKHOLE is essentially a “no-op” storage engine, so it could be used for finding performance bottlenecks not related to the storage engine itself.
10. Optimization
Optimization is a complex task because ultimately it requires understanding of the entire system to be optimized. Although it may be possible to perform some local optimizations with little knowledge of your system or application, the more optimal you want your system to become, the more you must know about it.
This chapter tries to explain and give some examples of different ways to optimize MySQL. Remember, however, that there are always additional ways to make the system even faster, although they may require increasing effort to achieve.
The most important factor in making a system fast is its basic design. You must also know what kinds of processing your system is doing, and what its bottlenecks are. In most cases, system bottlenecks arise from these sources:
Disk seeks. It takes time for the disk to find a piece of data. With modern disks, the mean time for this is usually lower than 10ms, so we can in theory do about 100 seeks a second. This time improves slowly with new disks and is very hard to optimize for a single table. The way to optimize seek time is to distribute the data onto more than one disk.
Disk reading and writing. When the disk is at the correct position, we need to read the data. With modern disks, one disk delivers at least 10–20MB/s throughput. This is easier to optimize than seeks because you can read in parallel from multiple disks.
CPU cycles. When we have the data in main memory, we need to process it to get our result. Having small tables compared to the amount of memory is the most common limiting factor. But with small tables, speed is usually not the problem.
Memory bandwidth. When the CPU needs more data than can fit in the CPU cache, main memory bandwidth becomes a bottleneck. This is an uncommon bottleneck for most systems, but one to be aware of
When using the MyISAM storage engine, MySQL uses extremely fast table locking that allows multiple readers or a single writer. The biggest problem with this storage engine occurs when you have a steady stream of mixed updates and slow selects on a single table. If this is a problem for certain tables, you can use another storage.
MySQL can work with both transactional and non-transactional tables. To make it easier to work smoothly with non-transactional tables (which cannot roll back if something goes wrong), MySQL has the following rules. Note that these rules apply only when not running in strict SQL mode or if you use the IGNORE specifier for INSERT or UPDATE.
All columns have default values. If you insert an inappropriate or out-of-range value into a column, MySQL sets
the column to the “best possible value” instead of reporting an error. For numerical values, this is 0, the smallest possible value or the largest possible value. For strings, this is either the empty string or as much of the string as can be stored in the column.
All calculated expressions return a value that can be used instead of signaling an error condition. For example, 1/0 returns NULL.
To change the preceding behaviors, you can enable stricter data handling by setting the server SQL mode appropriately.