2. Scalability and Flexibility
The MySQL database server provides the ultimate in scalability, sporting the capacity to handle deeply embedded applications with a footprint of only 1MB to running massive data warehouses holding terabytes of information. Platform flexibility is a stalwart feature of MySQL with all flavors of Linux, UNIX, and Windows being supported. And, of course, the open source nature of MySQL allows complete customization for those wanting to add unique requirements to the database server.

3. Robust Transactional Support
MySQL offers one of the most powerful transactional database engines on the market. Features include complete ACID (atomic, consistent, isolated, durable) transaction support, unlimited row-level locking, distributed transaction capability, and multi-version transaction support where readers never block writers and vice-versa. Full data integrity is also assured through server-enforced referential integrity, specialized transaction isolation levels, and instant deadlock detection.

4. High Availability
Rock-solid reliability and constant availability are hallmarks of MySQL, with customers relying on MySQL to guarantee around-the-clock uptime. MySQL offers a variety of high-availability options from high-speed master/slave replication configurations, to specialized Cluster servers offering instant failover, to third party vendors offering unique high-availability solutions for the MySQL database server.

5. Web and Data Warehouse Strengths
MySQL is the de-facto standard for high-traffic web sites because of its high-performance query engine, tremendously fast data insert capability, and strong support for specialized web functions like fast full text searches. These same strengths also apply to data warehousing environments where MySQL scales up into the terabyte range for either single servers or scale-out architectures. Other features like main memory tables, B-tree and hash indexes, and compressed archive tables that reduce storage requirements by up to eighty-percent make MySQL a strong standout for both web and business intelligence applications.

6. Strong Data Protection
Because guarding the data assets of corporations is the number one job of database professionals, MySQL offers exceptional security features that ensure absolute data protection. In terms of database authentication, MySQL provides powerful mechanisms for ensuring only authorized users have entry to the database server, with the ability to block users down to the client machine level being possible. SSH and SSL support are also provided to ensure safe and secure connections. A granular object privilege framework is present so that users only see the data they should, and powerful data encryption and decryption functions ensure that sensitive data is protected from unauthorized viewing. Finally, backup and recovery utilities provided through MySQL and third party software vendors allow for complete logical and physical backup as well as full and point-in-time recovery.

7. Comprehensive Application Development
One of the reasons MySQL is the world’s most popular open source database is that it provides comprehensive support for every application development need. Within the database, support can be found for stored procedures, triggers, functions, views, cursors, ANSI-standard SQL, and more. For embedded applications, plug-in libraries are available to embed MySQL database support into nearly any application. MySQL also provides connectors and drivers (ODBC, JDBC, etc.) that allow all forms of applications to make use of MySQL as a preferred data management server. It doesn’t matter if it’s PHP, Perl, Java, Visual Basic, or .NET, MySQL offers application developers everything they need to be successful in building database-driven information systems.

8. Management Ease
MySQL offers exceptional quick-start capability with the average time from software download to installation completion being less than fifteen minutes. This rule holds true whether the platform is Microsoft Windows, Linux, Macintosh, or UNIX. Once installed, self-management features like automatic space expansion, auto-restart, and dynamic configuration changes take much of the burden off already overworked database administrators. MySQL also provides a complete suite of graphical management and migration tools that allow a DBA to manage, troubleshoot, and control the operation of many MySQL servers from a single workstation. Many third party software vendor tools are also available for MySQL that handle tasks ranging from data design and ETL, to complete database administration, job management, and performance monitoring.

9. Lowest Total Cost of Ownership
By migrating current database-drive applications to MySQL, or using MySQL for new development projects, corporations are realizing cost savings that many times stretch into seven figures. Accomplished through the use of the MySQL database server and scale-out architectures that utilize low-cost commodity hardware, corporations are finding that they can achieve amazing levels of scalability and performance, all at a cost that is far less than those offered by proprietary and scale-up software vendors. In addition, the reliability and easy maintainability of MySQL means that database administrators don’t waste time troubleshooting performance or downtime issues, but instead can concentrate on making a positive impact on higher level tasks that involve the business side of data.

10.Easy support.

You can get easy support from thousands of mysql administrators worldwide. Sometimes for free and sometimes for very negligible charges. You can contact me anytime for mysql support at nilesh.pawar@kaizenz.com or visit at http://www.kaizenz.com

The idea started two years ago. During the MySQL conference, the blog posts were going fast and furiously down the screen. There were so many blog posts on Planet MySQL that their average life was 1 hour or less. Some of them went to the second page without having enjoyed a single minute of top page exposure. And then there were the presentation files, hidden or forgotten on some site, and never to be seen again, especially when you need them months later. After the conference, between travel, catching up with email, and whatever happens next, you lose track of most the interesting content that was generated by some of the best community members in the ecosystem. And the same happens when you go on vacation for two weeks. When you come back, catching up with the good stuff is hard. You should read hundred of less than interesting posts to get the important ones.
Improving the search on Planet MySQL helps a lot. But it won’t let you easily find an article that was published in a blog that is not aggregated, because the author writes about MySQL only once in a while. And the planet won’t let you find the presentations about interesting stuff, unless the accompanying text and tags reflect your search query.

The Librarian changes it all. The good content from conferences, stray presentations, videos, articles, can all be referenced in one place.
We started planning this tool in November 2008. Its implementation required a radical change of the Planet MySQL code, with months of thankless work to refactoring the existing features with a more flexible infrastructure. The small visible changes that appeared on Planet MySQL from February to June 2009 are the tip of the iceberg of a huge code change (kudos to Dups, who had the vision and the perseverance to tackle the task). If you were wondering why planetmysql.org started redirecting to planet.mysql.com, here’s the reason. We needed a single login, which could only be achieved by taking the planet under the main domain.

Click here to view more information on this.

CREATE TABLE Table1 ...

MySQL creates files named Table1.MYD (”MySQL Data”), Table1.MYI (”MySQL Index”), and Table1.frm (”Format”). These files will be in the directory:

///

For example, if you use Linux, you might find the files in the /usr/local/var/test directory (assuming your database name is test). if you use Windows, you might find the files in the \mysql\data\test\ directory.

Let’s look at the .MYD Data file (MyISAM SQL Data file) more closely. There are three possible formats — fixed, dynamic, and packed. First, let’s discuss the fixed format.

The length of the record header is thus:

(1 + number of NULL columns + 7) / 8 bytes

After the header, all columns are stored in the order that they were created, which is the same order that you would get from SHOW COLUMNS.

Here’s an example. Suppose you say:

CREATE TABLE Table1 (column1 CHAR(1), column2 CHAR(1), column3 CHAR(1));
INSERT INTO Table1 VALUES ('a', 'b', 'c');
INSERT INTO Table1 VALUES ('d', NULL, 'e');

A CHAR(1) column takes precisely one byte (plus one bit of overhead that is assigned to every column — I’ll describe the details of column storage later). So the file Table1.MYD looks like this:

Hexadecimal Display of Table1.MYD file

F1 61 62 63 00 F5 64 00 66 00              ... .abc..d e.

Here’s how to read this hexadecimal-dump display:

(It’s probably easier to understand the flag setting if you restate F5 as 11110101 binary, and (a) notice that the third flag bit from the right is on, and (b) remember that the first flag bit is the X bit.)

There are complications — the record header is more complex if there are variable-length fields — but the simple display shown in the example is exactly what you’d see if you looked at the MySQL Data file with a debugger or a hexadecimal file dumper.

So much for the fixed format. Now, let’s discuss the dynamic format.

The dynamic file format is necessary if rows can vary in size. That will be the case if there are BLOB columns, or “true” VARCHAR columns. (Remember that MySQL may treat VARCHAR columns as if they’re CHAR columns, in which case the fixed format is used.) A dynamic row has more fields in the header. The important ones are “the actual length”, “the unused length”, and “the overflow pointer”. The actual length is the total number of bytes in all the columns. The unused length is the total number of bytes between one physical record and the next one. The overflow pointer is the location of the rest of the record if there are multiple parts.

For example, here is a dynamic row:

03, 00             start of header
04                 actual length
0c                 unused length
01, fc             flags + overflow pointer
****               data in the row
************       unused bytes
                  <-- next row starts here)

In the example, the actual length and the unused length are short (one byte each) because the table definition says that the columns are short — if the columns were potentially large, then the actual length and the unused length could be two bytes each, three bytes each, and so on. In this case, actual length plus unused length is 10 hexadecimal (sixteen decimal), which is a minimum.

As for the third format — packed — we will only say briefly that:

For details, see the source files /myisam/mi_statrec.c (for fixed format), /myisam/mi_dynrec.c (for dynamic format), and /myisam/mi_packrec.c (for packed format).

Note: Internally, MySQL uses a format much like the fixed format which it uses for disk storage. The main differences are:

Data in MySQL is stored in files (or memory) using a variety of different techniques. Each of these techniques employs different storage mechanisms, indexing facilities, locking levels and ultimately provides a range of different functions and capabilities. By choosing a different technique you can gain additional speed or functionality benefits that will improve the overall functionality of your application.

For example, if you work with a large amount of temporary data, you may want to make use of the MEMORY storage engine, which stores all of the table data in memory. Alternatively, you may want a database that supports transactions (to ensure data resilience).

Each of these different techniques and suites of functionality within the MySQL system is referred to as a storage engine (also known as a table type). By default, MySQL comes with a number of different storage engines pre-configured and enabled in the MySQL server. You can select the storage engine to use on a server, database and even table basis, providing you with the maximum amount of flexibility when it comes to choosing how your information is stored, how it is indexed and what combination of performance and functionality you want to use with your data.

This flexibility to choose how your data is stored and indexed is a major reason why MySQL is so popular; other database systems, including most of the commercial options, support only a single type of database storage. Unfortunately the ‘one size fits all approach’ in these other solutions means that either you sacrifice performance for functionality, or have to spend hours or even days finely tuning your database. With MySQL, we can just change the engine we are using.

In this article, we’re not going to concentrate on the technical aspects of the different storage engines (although we will inevitably have to look at some of these elements); instead we will concentrate on how and where these different engines can be best employed. To achieve this, we’ll have to look at some of the fundamental issues before moving on to the specifics of each engine type.

Determining Available Engines

You can determine a list of engines by using the show engines command within MySQL (assuming a MySQL server version later than 4.1.2).

mysql> show engines;
+------------+---------+------------------------------------------------------------+
| Engine     | Support | Comment                                                    |
+------------+---------+------------------------------------------------------------+
| MyISAM     | DEFAULT | Default engine as of MySQL 3.23 with great performance     |
| HEAP       | YES     | Alias for MEMORY                                           |
| MEMORY     | YES     | Hash based, stored in memory, useful for temporary tables  |
| MERGE      | YES     | Collection of identical MyISAM tables                      |
| MRG_MYISAM | YES     | Alias for MERGE                                            |
| ISAM       | NO      | Obsolete storage engine, now replaced by MyISAM            |
| MRG_ISAM   | NO      | Obsolete storage engine, now replaced by MERGE             |
| InnoDB     | YES     | Supports transactions, row-level locking, and foreign keys |
| INNOBASE   | YES     | Alias for INNODB                                           |
| BDB        | NO      | Supports transactions and page-level locking               |
| BERKELEYDB | NO      | Alias for BDB                                              |
| NDBCLUSTER | NO      | Clustered, fault-tolerant, memory-based tables             |
| NDB        | NO      | Alias for NDBCLUSTER                                       |
| EXAMPLE    | NO      | Example storage engine                                     |
| ARCHIVE    | NO      | Archive storage engine                                     |
| CSV        | NO      | CSV storage engine                                         |
+------------+---------+------------------------------------------------------------+
16 rows in set (0.01 sec)

The listing shows the full list of available database engines, and whether the support is available in the current database server.

For versions of MySQL earlier than 4.1.2, use

mysql> show variables like "have_%";
+------------------+----------+
| Variable_name    | Value    |
+------------------+----------+
| have_bdb         | YES      |
| have_crypt       | YES      |
| have_innodb      | DISABLED |
| have_isam        | YES      |
| have_raid        | YES      |
| have_symlink     | YES      |
| have_openssl     | YES      |
| have_query_cache | YES      |
+------------------+----------+
8 rows in set (0.01 sec)

You can configure the available engines within a MySQL installation by changing the options to the configure script. If you are using a pre-packaged MySQL binary distribution then most of the commonly used engines are included. Note, however, that if you want access to some of the more unusual types (particularly the CSV, ARCHIVE and BLACKHOLE engines) then you may want to build your MySQL database by hand.

Using an Engine

There are a number of ways you can specify the storage engine to use. The simplest method, if you have a preference for a engine type that fits most of your database needs to set the default engine type within the MySQL configuration file (using the option storage_engine or when starting the database server by supplying the –default-storage-engine or –default-table-type options on the command line).

More flexibility is offered by allowing you specify the storage engine to be used MySQL, the most obvious is to specify the engine type when creating the table:

CREATE TABLE mytable (id int, title char(20)) ENGINE = INNODB

You can also alter the storage engine used for an existing table:

ALTER TABLE mytable ENGINE = MyISAM

However, you should be careful when altering table types in this way as making a modification to a type that does not support the same indexes, field types or sizes may mean that you lose data. If you specify a storage engine that doesn’t exist in the current database then a table of type MyISAM (the default) is created instead.

Differentiating the Engines

In order to make a decision about which engine to choose, we first need to think about the different core functionality provided in each engine that allows us to differentiate between them. We can generally divide up the core functionality into four areas; the supported field and data types, locking types, indexing and transactions. Some engines have unique functionality that can also drive your decision, we’ll be taking a closer look at these specifics in a moment.

Field and Data Types

Although all of the engines support the common data types, i.e., integers, reals and character based storage, not all engines support other field types, particularly the BLOB (binary large object) or TEXT types. Other engines may support only limited character widths and data sizes.

These limitations, while directly affecting the information you store may also have a related effect to the types of searches you perform, or the indexes you create on that information. In turn, these differences can affect the performance and functionality of your application as you may have to make decisions about functionality based on the storage engine choice you make for the type of data you are storing.

Locking Types

Locking within database engines defines how access and updates to information are controlled. When an object in the database is locked for updating, other processes cannot modify (or in some cases read) the data until the update has completed.

Locking not only affects how many different applications can update the information in the database, it can also affect queries on that data. The reason for this is that the queries may be accessing data that may be being altered or updated. In general, such delays are minimal. The bulk of the locking mechanism is devoted to preventing multiple processes updating the same data. Since both additions (INSERT statements) and alterations (UPDATE statements) to the data require locking, you can imagine that multiple applications using the same database can have a significant impact.

Locks are supported by different storage engines at different object levels, and these levels affect the concurrency of access to the information. Three different levels are supported, table locking, block locking and row locking. Table locking is most commonly supported and is the locking provided in MyISAM. It locks an entire table during an update. This will limit the number of applications that are updating a specific table to just one, and this can affect heavily used multi-user databases because it introduces delays into the update process.

Page level locking is used by the Berkeley DB storage engine and locks data according to the page (8Kb) of information that is being uploaded. When performing updates across a range of locations within the database, the locking is not a problem, but because adding rows involves locking the final 8Kb of the data structure, adding large numbers of rows, particularly of small data, can be a problem.

Row level locking provides the best concurrency; only individual rows within a table are locked, which means that many applications can be updating different rows of the same table without causing a lock situation. Only the InnoDB storage engine supports row level locking.

Indexing

Indexing can dramatically increase the performance when searching and recovering data from the database. Different storage engines provide different indexing techniques and some may be better suited for the type of data you are storing.

Some storage engines simply do not support indexing at all either because they use the indexing of the underlying tables (in the MERGE engine for example) or because the data storage method does not allow indexing (FEDERATED or BLACKHOLE engines).

Transactions

Transactions provide data reliability during the update or insert of information by enabling you to add data to the database, but only to commit that data when other conditions and stages in the application execution have completed successfully. For example, when transferring information from one account to another you would use transactions to ensure that both the debit from one account and the credit to the other completed successfully. If either process failed, you could cancel the transaction and the changes would be lost. If the process completed,then we would confirm it by committing the changes.

Storage Engines

MyISAM

The MyISAM engine is the default engine in most MySQL installations and is a derivative of the original ISAM engine type supported in the early versions of the MySQL system. The engine provides the best combination of performance and functionality, although it lacks transaction capabilities (use the InnoDB or BDB engines) and uses table-level locking.

Unless you need transactions, there are few databases and applications that cannot effectively be stored using the MyISAM engine. However, very high-performance applications where there are large numbers of data inserts/updates compared to the number of reads can cause performance problems for the MyISAM engine. It was originally designed with the idea that more than 90% of the database access to a MyISAM table would be reads, rather than writes.

With table-level locking, a database with a high number of row inserts or updates becomes a performance bottleneck as the table is locked while data is added. Luckily this limitation also works well within the restrictions of a non-transaction database.

MyISAM Summary
Name MyISAM
Introduced v3.23
Default install Yes
Data limitations None
Index limitations 64 indexes per table (32 pre 4.1.2); Max 16 columns per index
Transaction No
Locking level Table

MERGE

The MERGE engine type allows you to combine a number of identical tables into a single table. You can then execute queries that return the results from multiple tables as if they were just one table. Each table merged must have the same table definition.

The MERGE table is particularly effective if you are logging data directly or indirectly into a MySQL database and create an individual table per day, week or month and want to be able to produce aggregate queries from multiple tables. There are limitations to this however, you can only merge MyISAM tables and the identical table definition restriction is strictly enforced. Although this seems like a major issue, if you had used one of the other table types (for example InnoDB) then the merge probably wouldn’t be required.

MERGE Summary
Name MERGE
Introduced v3.23.25
Default install Yes
Data limitations Underlying tables must be MyISAM
Index limitations N/A
Transaction No
Locking level Table

MEMORY

The MEMORY storage engine (previously known as the HEAP storage engine) stores all data in memory; once the MySQL server has been shut down any information stored in a MEMORY database will have been lost. However, the format of the individual tables is kept and this enables you to create temporary tables that can be used to store information for quick access without having to recreate the tables each time the database server is started.

Long term use of the MEMORY storage engine is not generally a good idea, because the data could so easily be lost. However, providing you have the RAM to support the databases you are working on, use of MEMORY based tables is an efficient way of running complex queries on large data sets and benefiting from the performance gains.

The best way to use MEMORY tables is to use a SELECT statement to select a larger data set from your original, disk-based, tables and then sub-analyse that information for the specific elements you want. I’ve used this technique in the past to extract a month worth of web log data, actually from tables using the ARCHIVE storage engine, and then run the queries on specific URLs, sites and other focus points.

MEMORY Summary
Name MEMORY (HEAP, deprecated)
Introduced 1.0 (only known as MEMORY since 4.1)
Default install Yes
Data limitations BLOB and TEXT types not supported
Index limitations None
Transaction No
Locking level Table

EXAMPLE

The EXAMPLE engine is actually a programming example of a storage engine that can be used as the basis for other engines within the MySQL system. It does not support data inserts and isn’t a practical engine for any form of database access. It is, however, a good guide to how to develop your own storage engine, and is therefore an effective guide for programmers.

EXAMPLE Summary
Name EXAMPLE
Introduced v4.1.3
Default install No
Data limitations N/A
Index limitations N/A
Transaction N/A
Locking level N/A

FEDERATED

The FEDERATED storage engine (added in MySQL 5.03) enables you to access data from remote MySQL database (other databases may be supported in the future) as if it were a local database. In effect, the MySQL server acts as a proxy to the remote server, using the MySQL client access library to connect to the remote host, execute queries and then reformat the data into the localized format.

In essence, it is a way for a server, rather than a client, to access a remote database and can be an effective way of combining data from multiple hosts or of copying specific data from remote databases into local tables without the use of data exports and imports.

FEDERATED Summary
Name FEDERATED
Introduced v5.0
Default install No
Data limitations Limited by remote database
Index limitations N/A
Transaction No
Locking level No

ARCHIVE

The ARCHIVE storage engine supports only the INSERT and SELECT statements, but does support most of the MySQL field types. Information stored in an ARCHIVE storage engine table is compressed and cannot be modified and so ARCHIVE tables are perfect for storing log data (which you don’t want to be able to change) or information that is no longer in active use (for example, old invoicing or sales data).

While the information is stored very efficient, care should be taken when accessing data stored in the ARCHIVE tables. Because the information is compressed, selects have to read the entire table, and that also means decompressing the information. This can obviously increase the time taken to perform complex searches and retrievals. If you are performing a large number of queries on the information in these tables it may be easier to temporarily copy your data to another, uncompressed, data type such as MyISAM.

ARCHIVE Summary
Name ARCHIVE
Introduced v4.1.3
Default install No
Data limitations Data can only be inserted (no updates)
Index limitations N/A
Transaction No
Locking level N/A

CSV

The CSV storage engine stores data not in a binary format, but in the form a CSV (Command Separated Values) file. Because of this, there are limitations to the data stored. It is not an efficient method for storing large volumes of data, or larger data types like BLOB, although such types are supported. There is also no indexing. However, because the data is stored in the CSV format it is exceedingly portable; these CSV files generated can easily be imported into many different software packages, including Excel, OpenOffice and database systems like Access or FileMaker.

In general, the CSV engine is impractical as a general database engine. It is, however, probably the most effective and easiest method for data exchange. What makes it so convenient is that we can use SELECT and INSERT statements to create the database, which in turn means that we can easily produce CSV files based on queries of other data.

With some careful work, the CSV storage engine can also be used as an effective way of getting information into MySQL. Here, you can create the tables first, shutdown the MySQL server, copy over CSV files that you have exported from Excel, Access or another database, and you can then import the data and copy it over to MyISAM or InnoDB tables.

CSV Summary
Name CSV
Introduced v4.1.4
Default install No
Data limitations None
Index limitations Indexing is not supported
Transaction No
Locking level Table

BLACKHOLE

Strange though it may seem, the BLACKHOLE engine does not actually store any data. Although you can create tables and indexes, all SQL statements that would add or update information to the database are executed without actually writing any data. The database structure is retained, however, and you can create any indexes on the (non-existent) information that you want.

Although this seems like a futile exercise, it does allow you to test out database structures and play with table definitions without actually creating any data. Even more useful, however, is that SQL statements on BLACKHOLE databases are written to the binary log, and therefore are replicated to slave databases.

You can use this functionality to update one or more slaves directly without writing any local data. There are a number of potential uses for this functionality. One such use I have employed in past is to write log data to a BLACKHOLE table, which is then echoed to two slaves. Because the write is instantaneous (there are no local disk files or indexes to update), I can maintain a high logging rate, and rely on the binary logging and slave replication to distribute the data. An extension of this, as suggested in the MySQL manual, is to use filtering to control the distribution of records to the slaves.

BLACKHOLE Summary
Name BLACKHOLE
Introduced 4.1.11
Default install No
Data limitations No data is stored, but statements are written to the binary log (and therefore distributed to slave databases)
Index limitations N/A
Transaction No
Locking level N/A

ISAM

The ISAM storage engine was the original engine type available with versions of MySQL up until MySQL 3.23, when the MyISAM storage engine was introduced. ISAM has a number of different limitations that make it impractical as a database engine. These include the storage format, which is native to the platform (and therefore not portable between systems), a maximum table size of just 4GB and limited text searching facilities. Indexes are also more limited. Since MyISAM is supported on the same platforms as ISAM, and provides better compatibility, portability and performance.

ISAM is included for backwards compatibility, you certainly shouldn’t use ISAM for new databases, use MyISAM instead.

ISAM Summary
Name ISAM
Introduced v1.0
Default install Yes
Data limitations Limited maximum database size (4GB)
Index limitations Maximum 16 indexes per table, 16 parts per key
Transaction No
Locking level Table

Berkeley DB (BDB)

The Berkeley DB (or BDB) engine is based on the technology provided by the Berkeley DB storage system developed by SleepyCat software. BDB is a hash based storage mechanism, and the keys to the hash values are stored very efficiently. This makes the recovery of information–especially when accessed directly using a unique key incredibly quick, and by far the quickest of the available database types. Recovering full records is even quicker if you the data is short enough to be stored with the unique key (i.e., under 1024 bytes long). BDB is also one of only two types of storage engine that support transactions.

BDB is, however, limited in other ways. Although it uses page locking, locking only 8192 bytes of a table, rather than the entire table, during an update this can cause problems if you are performing a large number of updates in the same page (for example, inserting many rows). There is unfortunately no way round this. Sequential data access–for example a large quantity of rows matching non-indexed data–can be a lot slower because the data needs to be scanned row by row.

Recovery of information with BDB tables can also be a problem. Data in BDB is stored in a combination of the key index, the data file and binary data logs. A loss of data in any of these sections, even just one of the data logs, can make the data in the database totally unrecoverable.

Where BDB shines therefore is in locations where you can access specific blocks of data by a unique key that does not frequently change. I’ve successfully used BDB tables in the past to store look up information for data like categories or option lists where the small size and unique key structure make it quick and easy to recover information that is not often changed from its initial definition.

Berkeley DB (BDB) Summary
Name BDB
Introduced v3.23.34a
Default install No
Data limitations None
Index limitations Max 31 indexes per table, 16 columns per index;max key size 1024 bytes
Transaction Yes
Locking level Page (8192 bytes)

InnoDB

The InnoDB Engine is provided by Innobase Oy and supports all of the database functionality (and more) of MyISAM engine and also adds full transaction capabilities (with full ACID (Atomicity, Consistency, Isolation, and Durability) compliance) and row level locking of data.

The key to the InnoDB system is a database, caching and indexing structure where both indexes and data are cached in memory as well as being stored on disk. This enables very fast recovery, and works even on very large data sets. By supporting row level locking, you can add data to an InnoDB table without the engine locking the table with each insert and this speeds up both the recovery and storage of information in the database.

As with MyISAM, there are few data types that cannot effectively be stored in an InnoDB database. In fact, there are no significant reasons why you shouldn’t always use an InnoDB database. The management overhead for InnoDB is slightly more onerous, and getting the optimization right for the sizes of in-memory and on disk caches and database files can be complex at first. However, it also means that you get more flexibility over these values and once set, the performance benefits can easily outweigh the initial time spent. Alternatively, you can let MySQL manage this automatically for you.

If you are willing (and able) to configure the InnoDB settings for your server, then I would recommend that you spend the time to optimize your server configuration and then use the InnoDB engine as the default.

InnoDB Summary
Name InnoDB
Introduced v3.23 (source only), v4.0 (source and binary)
Default install No
Data limitations None
Index limitations None
Transaction support Yes (ACID compliant)
Locking level Row

Summary

As you may have been able to conclude from the above summary of the different storage engines available, there are few reasons not to use either the MyISAM or InnoDB engine types. MyISAM will do in most situations, but if you have a high number of updates or inserts compared to your searches and selects then you will get better performance out of the InnoDB engine. To get the best performance out of InnoDB you need to tweak the parameters for your server, otherwise there is no reason not to use it.

But if both MyISAM and InnoDB are so great, why even consider using the other engine types! Simply because they provide specific functionality that is not otherwise available. The MERGE engine is an exceedingly effective way of querying data from multiple, identically defined, tables. The MEMORY engine is the best way to perform a large number of complex queries on data that would be inefficient to search on a disk based engine. The CSV engine is a great way to export data that could be used in other applications. BDB is excellent for data that has a unique key that is frequently accessed.

Some of these are possible to do with InnoDB (our separate MyISAM logs, for example, could be combined into a single InnoDB table), but the flexibility to choose an engine type that suits you and the data you are working with is what differentiates MySQL from other solutions.

Probably the most significant addition to the product in version 5.0 is support for stored program objects: views, stored procedures, functions, and triggers. These features promote code standardization and reuse. They also simplify security.

Views

A view is a virtual table: a SELECT statement with a name. Microsoft SQL Server calls them views as well; Microsoft Access calls them queries. Selecting from the view name executes the underlying SELECT statement, and returns the results as columns in the virtual table. MySQL views may be read only or updateable. A check option can be specified to prevent views from being updated with rows that they cannot themselves SELECT.

Stored procedures

Stored procedures are created via the CREATE PROCEDURE statement, and executed via the CALL statement. They may include input, output, and input-output parameters. MySQL stored procedures follow the SQL Server model, which permits a rowset to be returned simply by including a SELECT statement in the procedure. Unlike SQL Server, however, stored procedures in MySQL are not compiled. They do share many of the same advantages, such as standardizing code and reducing network traffic by performing business logic within the server.
A single statement such as a SELECT is coded immediately after the procedure declaration. Multi-statement procedures must be bracketed by BEGIN and END statements. Conditional statements available include a simple IF - THEN - ELSE and a searched form of CASE (all the cases are values which are matched to determine which case to execute). Loops include WHILE (tests at the top of the loop), REPEAT (tests at an arbitrary location where an UNTIL statement is placed), and LOOP (repeats forever until exited via a LEAVE statement). Exception handlers can be defined to catch and process errors.
As in SQL Server, granting EXECUTE privileges on a stored procedure grants implicit permission to access objects used in the view. This means a single EXECUTE privilege can take the place of many individual grants on individual tables. This is important, as MySQL does not as yet have a roles model to aggregate permissions.
Functions. Stored functions, like stored procedures, are objects in the database. The difference is that they return a result value which must be consumed by the calling program in some way.

Triggers

Triggers are event-driven stored procedures. They are tied to a specific table, and to an event on that table (INSERT, UPDATE, or DELETE). When the event occurs, the trigger is executed (or “fired”.)
One key difference between MySQL triggers and those in SQL Server is that MySQL triggers can be called either before the triggering action or after it, whereas SQL Server triggers are after only. SQL Server does have an INSTEAD OF trigger not present in MySQL. Another key difference is the FOR EACH ROW syntax in MySQL, that will cause the trigger to execute for each row modified. The prefixes “OLD.” and “NEW.” enable the trigger body to reference columns before or after being modified. SQL Server triggers execute once per statement, and must take into account the possibility of multiple rows being affected.

Storage enhancements

Datatype changes in this release include extending the VARCHAR to a maximum of 65,532 bytes, and the addition of a new BIT datatype.
MySQL’s architecture uses plug-in storage engines to implement the physical storage of database tables. Each table may use a different storage engine; each engine provides a different set of features. The default storage engine, MyISAM, is very fast but does not have the ability to capture transactions; the InnoDB storage engine features not only transactions, but also row-level locking and declarative integrity constraints. It follows the Oracle model of non-blocking reads. The InnoDB engine uses a more compact storage format than previously. MySQL AB estimates that simply migrating 3.x or 4.x InnoDB tables to version 5.0 can save 15-20% storage space.
Version 5.0 adds two new storage engine types to the product: Archive, and Federated. The Archive storage engine compresses all data stored using it, to save still more space. What’s really unique about this engine is that it only implements two DML commands: SELECT, and INSERT. Data goes in, but it cannot be updated or removed without changing what engine the table uses. This should make it very useful in archiving records for regulatory compliance with laws such as Sarbanes-Oxley and HIPAA.
The Federated storage engine enables access to remote tables, similar to a linked server definition in Microsoft SQL Server. In this release, the engine supports linking to other MySQL databases on the same or different operating system platform. Future releases may provide support for non-MySQL links.

Administration tools

In the past, MySQL development and administration has been done either at the command line, or by using third party tools such as phpMyAdmin. With the 5.0 release, MySql now includes a set of graphical user interfaces for common administration and development tasks. These are similar to those found in Microsoft SQL Server, although being their first release, are not nearly as comprehensive. Still, they do make basic administration tasks easier by hiding the underlying SQL syntax under a façade of form controls. The tools include:

MySQL Instance Configuration Wizard - This tool is currently available only in the Windows version. It is automatically invoked after installation, but can also be run from the Start menu. As the name implies, this tool is a step-by-step guide to configuring an instance of MySQL. Specifically, it creates the my.ini file, a text file containing startup configuration parameters.

MySQL Query Browser - Available for Windows, Linux and Mac OS X versions of MySQL, this tool can be used to build queries and test them. It’s similar to Query Analyzer in SQL Server 7.0 and 2000, with a schemata browser

MySQL Administrator - This console is also available for Windows, Linux, and Mac OS X. It lists all the installed MySQL services and the database catalogs each contains. Common administrative tasks such as creating, altering, and dropping tables in a database can be performed visually via the Table Editor. Indexes and constraints such as foreign keys can also be defined here.

MySQL System Tray Monitor - Similar to the Service Manager in SQL Server 2000, this tool puts an icon in the Windows SysTray to display the status of the MySQL Instance. Right-clicking the icon brings up a context menu that enables starting or stopping the instance, or opening tools such as MySQL Administrator or MySQL Query Browser.
Another manageability tool is the INFORMATION_SCHEMA database, one of three standard databases in a default MySQL 5.0 installation. INFORMATION_SCHEMA is defined by the ANSI SQL standard as a way to access metadata (definitions) about the objects in a database. The various views in this schema enable queries to obtain a list of tables, views, columns, triggers, and other objects. For example:

SELECT table_name from INFORMATION_SCHEMA.TABLES
WHERE table_schema = ‘test’;
will display all the tables defined in the test database.

Support and certification

For open source products like MySQL to succeed in the enterprise market, they have to have more than low cost on their side. Businesses have been reluctant to trust their systems to products that have only a community bulletin board for support. It is the number one concern of businesses regarding open source products, according to a Forrester Research report released in January 2004.
As a result, the major Linux vendors have developed support programs on a subscription basis, such as Red Hat Network for the Red Hat flavor of Linux. MySQL has done the same, with its MySQL Network subscription.
MySQL Network includes a stable, less-frequently released edition of MySQL called Pro Certified Server; access to a Knowledge Base online; and various levels of production support (Basic, Silver, Gold, Platinum levels). MySQL AB is also a member of the Technical Support Alliance Network (TSANet), which networks MySQL support engineers with those in other companies such as Red Hat, Microsoft, Cisco, Dell and HP to help solve complex issues involving multiple vendors.
Just as businesses need a support system for the software they purchase, they also need tools for IT skills management. With commercial vendors, the primary tool to date has been some form of certification program: a series of examinations that test a candidate’s knowledge and skills with a particular software product.
Certification programs have not caught on as well in the open source community as with proprietary software vendors. Discussions critical of “paper” certifications are staple fare on community sites such as Slashdot. However, certification programs are more common in larger firms. MySQL created certifications at the 4.0 level, and has updated them for the 5.0 release to be more aligned with an IT skills management focus.
Whereas the old exams focused on product features (MySQL 4 Core, and MySQL 4 Professional), the new exams are mapped to job function (MySQL 5 Developer, MySQL 5 Database Administrator). The skill sets tested relate to these job functions: for example, the Database Administrator exam covers topics such as installing MySQL, using its performance monitoring tools, and doing backups.

Even more in 5.1

Even more enterprise-related features are available in beta release for version 5.1. Although the exact mix won’t be known until the Generally Available (GA) release, here are some of the more significant ones in the beta:

Table partitioning - MySQL is following the Oracle model here, enabling a single table to reside over multiple tablespaces using a relatively transparent partitioning structure. Five different partitioning algorithms are planned for the 5.1 release: by range, by hash, by key (similar to hash, but with system generated identifiers), by list, and composites of these.

Background scheduler - Similar to SQL Server Agent or Oracle’s Job Scheduler, this tool will enable automatic execution of SQL commands at regular intervals. This will ease regular data loading and administration tasks, now done via scripts written in languages such as Perl and executed via operating system schedulers.

XML support - XML, which has been notably missing from MySQL to date, will gain ExtractValue() and UpdateXML() functions in 5.1. These functions will use XPath expressions to retrieve any specific fragment of an XML-formatted document, or to replace one XML fragment with another one.

Load emulator - The mysqlslap program will enable developers to simulate large user loads on their database configuration, to test whether the application as designed will scale to production.
The Bottom Line
MySQL 5.0 is a very significant release for MySQL AB. Although some of its features are not as comprehensive as DBAs and developers are used to in other platforms, it shows the company’s intent to play in the same space.

MyISAM has no clustered index, so the data isn’t physically ordered by any index (it’s in insertion order), but in InnoDB, the rows are physically ordered by the primary key. That means there can be page splits as rows are inserted between other rows — if there are too many rows to fit on a page, the page has to be split. MyISAM doesn’t have that problem, because rows don’t get stuffed between other rows (they are added at the end), so a secondary index’s leaf nodes always point directly to the row in the table. In fact, there’s no functional difference between primary and secondary keys in MyISAM. A MyISAM primary key is simply a unique index named “PRIMARY.”

Why doesn’t InnoDB just “point” to the rows like MyISAM? If InnoDB used that strategy, it would have to rewrite all the secondary indexes at every page split, when the rows get moved to a different location on disk. To avoid that cost, InnoDB uses the values from the primary key as its secondary index’s leaf nodes. That makes the secondary indexes independent of the physical order of the primary key, but the “pointer” isn’t a pointer directly to the row as in MyISAM. It also means secondary index lookups are more expensive than primary key lookups, because any secondary index lookup only results in a tuple that can be used to navigate the primary key — double work. MyISAM doesn’t have that issue. Of course, it doesn’t have rows in index order, either; and the primary key might be “deeper.” It’s a trade-off.

Secondary index optimizations
So there’s a cost to secondary indexes in InnoDB. There’s an optimization too. Once a query navigates to the leaf node of a secondary index, it knows two things: the values it used to navigate the index, and the primary key values of that row in the table.
For example, suppose I have a table structured like this:create table apples(
variety varchar(10) primary key,
note varchar(50),
price int,
key(price)
) engine=InnoDB;
insert into apples values
(’gala’, ‘hello’, 5),
(’fuji’, ‘hello’, 6),
(’limbertwig’, ‘hello’, 8),
(’red delicious’, ‘hello’, 3),
(’pippin’, ‘hello’, 8),
(’granny smith’, ‘hello’, 11),
(’roma’, ‘hello’, 6);
Note only the ‘gala’ row has a price of 5. Now suppose I issue the following query:select variety from apples where price=5;
The query takes the value 5 and navigates the price index. When it gets to the leaf node, it finds the value ‘gala’, which it can use to navigate the primary key. But why does it need to do that? It already has the value it was looking for!
In fact, if the query only refers to values in the secondary and clustered index, it doesn’t need to leave the secondary index. If you like fancy lingo, the index “covers” the query, so it is a “covering index” or “index cover.”
This is a fantastic optimization. It means each secondary index is like another table, clustered index-first. In this example, the secondary index is like a table containing just price and variety, clustered in that order (refer again to the diagrams above).
In MyISAM, the “don’t leave the index” optimization can be used too, but only if the query refers only to values in the index itself, because MyISAM indexes don’t have any PK values at their leaf nodes. A MyISAM index can’t be used to find any additional data without following the pointer to the row itself. Again, it’s a trade-off.

How to know when the optimization is used
Theoretically, the optimization can be used anytime a query only uses values from the clustered index and a secondary index in InnoDB, or only uses values from the index itself in MyISAM. That doesn’t mean the query will use that index, though. For a variety of reasons, the query might use some other index. To find out for sure, EXPLAIN the query. If the Extra column includes the text “Using index,” the optimization is being used.
How to design indexes for this optimization
Once you understand how indexes work, you can make deliberate decisions about indexes. Here is a methodical approach to designing indexes.
Begin with a table and the data it needs, but without any indexes except those designed to constrain the data to valid values (primary and unique indexes). Next, consider the queries that are issued against the table. Is it queried ad-hoc, or do certain types of queries happen repeatedly? This is very important to know.
Before you start, consider the size of the table and how much it is used. You should put your optimization effort where it is most needed. If one 5-minute query runs once a day and you know it should be possible to optimize it to 5 seconds, that’s 4 minutes and 55 seconds saved. If another query issued every minute takes 5 seconds and you know it should be possible to run it in a few milliseconds, that’s about 7,000 seconds saved. You should optimize the second query first. You should also consider carefully-designed archiving jobs to get those tables as small as possible. Smaller tables are a huge optimization.
Now, back to the index design discussion. If the table is queried ad-hoc all the time, you need to create generally useful indexes. Most of the time you should examine the data to figure out what they should be. Pretend you’re optimizing the apples table above. This table probably does not need an index on the note column. Look at its contents — every row just says “hello.” Indexing that would be a total waste. Plus, it just seems reasonable that you want to look at the note, but not filter by it. On the other hand, it’s very reasonable that you’d want to find apples by price. The price index is probably a good choice.
On the other hand, if you know there’s a certain query that happens all the time and needs to be very fast, you should consider specially optimized indexes. Suppose these two queries each run 50 times a second:select variety from apples where price = ?;
select note from apples where price = ?;
These queries deserve a close look. The optimization strategy will depend on the table size and the storage engine.
If you are using the InnoDB engine, the first query is already optimized as we’ve seen above. It will use the price index and not even look at the table itself. If you’re using the MyISAM engine, you need to consider how large the table is, and therefore how large an index on (price, variety) would be. If the table is very large, for example, if there are a bunch of large VARCHAR columns in it, that index might be significantly faster than all the bookmark lookups required to find the variety column for each row found in an index that only contains the price column.
The second query is trickier to optimize, because it really depends on how large the table is. If the table is very large, and has lots of other columns as I mentioned in the previous paragraph, it might make sense to create an index on (price, note). This is where careful testing is needed. I will explain how to do that testing in an upcoming article. It is non-trivial in MySQL, unfortunately.
The general strategy is as follows:
For InnoDB, put the columns in the WHERE clause first in the index, then add the columns named in the SELECT clause at the end, unless they are included in the primary key.
For MyISAM, put the columns in the WHERE clause first in the index, then add the columns named in the SELECT clause at the end.
How to write queries that don’t suck
I’ve noticed many people have a tendency to write SELECT * FROM… queries. If you don’t need all the columns, don’t select all the columns, because it can make the difference between a fast and a slow query. If you only select the columns you need, your query might be able to use one of the optimizations I’ve just explained. If you select every column and the query uses a secondary index, there’s no way to do that, and the query will have to wander around indexes finding the rows it needs, then do other operations to get the actual values from the rows.
Of course, if you only need a few columns, it can also be a lot less data not to select all the columns you don’t need. Getting that data off the disk and sending it to whatever asked for it is significant overhead. Don’t do it unless you need to.
Other InnoDB index design considerations
Since InnoDB secondary indexes already contain all columns from the primary key, there’s no need to add them to the secondary index unless the index needs them at the front of the index. In particular, adding an index on (price, variety) to the apples table above is completely redundant. And in tables where the primary key is several columns and it’s desirable to have the table “clustered two ways” by using the indexes as I’ve explained, not all of the columns need to be added to additional indexes. Indexes need to be designed very carefully to avoid causing a bunch of extra overhead. Every index adds a cost to the table, and it’s really important to avoid indexes that add cost but no benefit.
Suppose you added an index on (price, variety) to the apples table anyway. You might think the variety column can just be optimized out of the internal nodes, since the values are already at the leaf nodes. It can’t, because the primary key values are only at the leaf nodes, not in the internal nodes, and they can’t be optimized out of the internal nodes because they’re needed for navigating the index. Again, adding that column to the end of the index will just make the index larger, but result in the query knowing nothing it didn’t already know — and that’s useless.
I want to point out that it’s not always possible to design indexes so this optimization can be used! It is not necessarily a good design goal to make sure every query can be satisfied without leaving the indexes. In fact, it’s unrealistic. But in special cases, it may be possible and worth doing.
Another InnoDB optimization
Here’s another neat optimization: a tiny index might be used unexpectedly. For example,create table something (
id bigint not null auto_increment primary key,
is_something tinyint not null,
othercol_1 bigint not null,
othercol_2 bigint not null,
othercol_3 bigint not null,
index(is_something)
);
is_something is a 1/0 indicator of whether something is true about the row. Normally I’d say an index on that is a waste of disk and CPU, because it’s not selective enough for the query optimizer to use it, assuming there’s an equal distribution of ones and zeroes. But the fact that it’s a very small value is important for some queries. For example, select sum(id) from something will scan the is_something index because it’s the smallest available. Its internal nodes only have one-byte tinyint values, and the leaf nodes have a tinyint and an 8-byte bigint. That’s much smaller than the clustered index, which has 8-byte values in the internal nodes, and 33 bytes at each leaf.
Proof of InnoDB’s automatic clustered index
I said every InnoDB table gets a 6-byte internal clustered index if it has no primary key. Here’s a neat way to see that in action. I created a table like so:create table test(a int, b int, c int) engine=InnoDB;
insert into test values(1, 1, 1), (2, 2, 2);
I started a transaction and got an exclusive lock on it, then started another transaction on a different connection and tried to update that table:– connection 1:
set transaction isolation level serializable;
start transaction;
select * from test;
– connection 2:
set transaction isolation level serializable;
start transaction;
update test set a = 5;
The query blocked and waited for a lock to be granted. Then I issued SHOW ENGINE INNODB STATUS on another connection. The transaction information shows the lock on the internally generated index:—TRANSACTION 0 81411, ACTIVE 1410 sec, process no 8799, OS thread id 1141414240 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1216
MySQL thread id 4, query id 194 localhost xaprb Updating
update test set a = 5
——- TRX HAS BEEN WAITING 9 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 131074 n bits 72 index `GEN_CLUST_INDEX` of table `test/test` trx id 0 81411 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len 6; hex 000000018a02; asc ;; 1: len 6; hex 000000013e0a; asc > ;; 2: len 7; hex 80000000320110; asc 2 ;; 3: len 4; hex 80000001; asc ;; 4: len 4; hex 80000001; asc ;; 5: len 4; hex 80000001; asc ;;
Notice the lock on the index called GEN_CLUST_INDEX. Notice also the number of fields (n_fields) in the lock struct: two more than the number of columns in the table. The first field in the index is the internally generated unique value, and it is 6 bytes as I said above.
If there is a primary key on a, it’s a different story:—TRANSACTION 0 81456, ACTIVE 17 sec, process no 8799, OS thread id 1141680480 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1216
MySQL thread id 9, query id 277 localhost xaprb Updating
update test set a = 5 where a = 1
——- TRX HAS BEEN WAITING 6 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 131076 n bits 72 index `PRIMARY` of table `test/test` trx id 0 81456 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000001; asc ;; 1: len 6; hex 000000013e27; asc >’;; 2: len 7; hex 80000000320110; asc 2 ;; 3: len 4; hex 80000001; asc ;; 4: len 4; hex 80000001; asc ;;
Now the lock is on the index called PRIMARY, there are only 5 fields in the lock structure, and the first one is 4 bytes instead of 6. Fields with the value 2 have the hex value 80000001. When the primary key is a column, that field comes first in the lock structure.
These examples prove that InnoDB adds a “hidden column” to your tables when you don’t create a primary key. Maybe I’m saying this too often, but you should always create a carefully designed primary key, because if you don’t, you’re throwing away one of the best things InnoDB gives you: a clustered index. Read my past articles for more on how to design an effective primary key.
Summary
The more you know about how indexes work, the more you can optimize your databases. Sometimes these optimizations don’t help much, but sometimes they’re huge. In this article I explained how InnoDB’s primary and secondary indexes are different from other storage engines. Now that you understand the differences, you can understand the optimizations and trade-offs each storage engine has, and how to take advantage of the optimizations and avoid the drawbacks if possible. I showed you several side effects of the index design, such as a query scanning a secondary index instead of the table, and went into a bit of InnoDB internals to see how tables without primary keys work.
If this article helped you, you should consider subscribing via feeds or e-mail, because it’s the best way to get my upcoming articles. I publish two or three times a week.

Setting the password:

1. From Unix:

shell> mysql -u username -h hostname -p password

mysql> SET PASSWORD FOR username@localhost=PASSWORD(’new_password’);

2. Directly manipulate the privilege tables:

shell> mysql -u username -h host -u username -p

mysql> UPDATE user SET Password=PASSWORD(’new_password’) WHERE user=’root’;

mysql> FLUSH PRIVILEGES;

3. Using the mysqladmin command:

shell> mysqladmin -u username password new_password

In our case we were able to change password specifying host name along with user name:

shell> bin/myslqadmin u username h localhost

MySQL Permissions & Grant Tables

In order to add a new user or update user’s privileges in mysql grant tables login to mysql as a root user.

There are two options: use GRANT/REVOKE command or manipulating the MySQL grant tables directly.

The preferred method is to use GRANT statements - more concise and less error-prone.

If you modify the grant tables manually (using INSERT, UPDATE, etc.), you should execute

a FLUSH PRIVILEGES statement to tell the server to reload the grant tables.

To remove user: mysql> delete from user where user=’username’;

mysql> FLUSH PRIVILEGES;

Examples adding a new user with different level of privileges:

dummy: A user who can connect without a password, but only from the local host.

mysql> GRANT USAGE ON *.* TO dummy@localhost;

myUser : A full superuser who can connect to the server from anywhere,

but who must use a password ‘pass’ to do so.

GRANT statements should be for both myUser@localhost and myUser@”%”.

to prevent the anonymous user entry for localhost take precedence.

mysql> GRANT ALL PRIVILEGES ON *.* TO myUser@localhost

IDENTIFIED BY ‘pass’ WITH GRANT OPTION;

mysql> GRANT ALL PRIVILEGES ON *.* TO myUser@”%”

IDENTIFIED BY ’some_pass’ WITH GRANT OPTION;

“%” - is a wildcard in mysql. If you are defining your DB table and in the ‘host’ field

enter ‘%’, that means that any host can access that database (Of course, that host

must also have a valid db user).

admin: A user who can connect from localhost without a password and who is granted

the RELOAD and PROCESS administrative privileges.

No database-related privileges are granted.

mysql> GRANT RELOAD,PROCESS ON *.* TO admin@localhost;

Add a user that has full rights to his database only but cannot see other database:

mysql> GRANT USAGE ON *.* TO ‘user’@'host’ GRANT Select, Insert, Update, Delete,

Create, Drop ON `database`.* TO ‘user’@'host’ FLUSH PRIVELEGS;

The FILE privelege and WITH GRANT OPTION may not be the best way to include, it is only in case of creating another superuser with full set of privileges or giving privileges to load data using mysql command INLOAD DATA.

GRANT TABLE FIELDS EXPLANATION:

TABLE USER: Everything after “password” is a privelege granted with values ‘Y’ or ‘N’.

This table controls individual user global access rights.

‘host’, ‘user’, ‘password’, ’select’, ‘insert’, ‘update’, ‘delete’, ‘index’, ‘alter’
,’create’, ‘drop’, ‘grant’, ‘reload’, ’shutdown’, ‘process’,'file’

TABLE DB: This controls access of USERS to databases.

‘host’, ‘db’, ‘user’, ’select’, ‘insert’, ‘update’, ‘delete’, ‘index’, ‘alter’,
‘create’,'drop’,'grant’

TABLE HOST: This controls which HOSTS are allowed what global access rights.

‘host’, ‘db’, ’select’, ‘insert’, ‘update’, ‘delete’, ‘index’, ‘alter’,
‘create’, ‘drop’, ‘grant’

HOST, USER, and DB table are very closely connected - if an authorized USER attempts an SQL request from an unauthorized HOST, it is denied. If a request from an authorized HOST is not an authorized USER, it is denied. If a globally authorized USER does not have rights to a certain DB, it is denied.

Backups in MySQL

Full backup of MySql databases:

1. shell> mysqldump –tab=/path/to/some/dir –opt –full

OR

2. shell> mysqlhotcopy database /path/to/some/dir

OR

3. simply copy all table files (`*.frm’, `*.MYD’, and `*.MYI’ files)
For a SQL level backup of a table use SELECT INTO OUTFILE or BACKUP TABLE.

mysql> BACKUP TABLE tbl_name[,tbl_name...] TO ‘/path/to/backup/directory’
Copies to the backup directory the minimum number of table files needed to restore the table, after flushing any buffered changes to disk.

RESTORE TABLE tbl_name[,tbl_name...] FROM ‘/path/to/backup/directory’
Restores the table(s) from the backup that was made with BACKUP TABLE.
Existing tables will not be overwritten; if you try to restore over an existing table, you will get an error. Restoring will take longer than backing up due to the need to rebuild the index. The more keys you have, the longer it will take.
Just as BACKUP TABLE, RESTORE TABLE currently works only for MyISAM tables.

Selective backups can be done with:
SELECT * INTO OUTFILE ‘file_name’ FROM tbl_name
and restore with:
LOAD DATA INFILE ‘file_name’ REPLACE …

To avoid duplicate records, you need a PRIMARY KEY or a UNIQUE key in the table.
The REPLACE keyword causes old records to be replaced with new ones when a new record duplicates an old record on a unique key value.

Monitoring tools

The myisamchk utility is used to get information, check, repair or optimise mysql database tables:
shell> myisamchk [options] tbl_name

With no options, myisamchk simply checks the table.

Some useful Options for myisamchk utility:

1. Print informational statistics about the table that is checked: -i or –information

2. Check only tables that have changed since the last check: -C or –check-only-changed

3. The recommended way to quickly check all tables:

myisamchk –silent –fast /path/to/datadir/*/*.MYI

To Start the server automatically at system startup time

The mysql.server and safe_mysqld scripts can be used to start/stop the server automatically.

shell> mysql.server start

shell> mysql.server stop

See mysql.server in the `share/mysql’ directory or in the `support-files’ directory of the MySQL source tree.

The mysql.server script understands the following options: datadir, basedir, and pid-file.

If your system uses `/etc/rc.local’ to start external scripts, you should append the following to it:

/bin/sh -c ‘cd /usr/local/mysql ; ./bin/safe_mysqld –user=mysql &’

The mysql.server script understands the following options: datadir, basedir, and pid-file.