Easy Tutorial
❮ Cpp Keyword Intro Java Varargs Parameter ❯

Six Major Differences Between MySQL Storage Engines InnoDB and MyISAM

Category Programming Technology

>

Abstract: MySQL offers multiple storage engines, each with its own advantages and disadvantages, allowing for optimal selection: MyISAM, InnoDB, MERGE, MEMORY(HEAP), BDB(BerkeleyDB), EXAMPLE, FEDERATED, ARCHIVE, CSV, BLACKHOLE.

MySQL supports several storage engines, each with its own advantages and disadvantages, allowing for optimal selection:

MyISAM, InnoDB, MERGE, MEMORY(HEAP), BDB(BerkeleyDB), EXAMPLE, FEDERATED, ARCHIVE, CSV, BLACKHOLE.

MySQL supports multiple storage engines as processors for different table types. These engines include those that handle transaction-safe tables and those that handle non-transaction-safe tables:

-

MyISAM manages non-transactional tables. It offers high-speed storage and retrieval, as well as full-text search capabilities. MyISAM is supported in all MySQL configurations and is the default storage engine unless configured otherwise.

-

The MEMORY storage engine provides "in-memory" tables. The MERGE storage engine allows grouping of identically processed MyISAM tables into a single table. Like MyISAM, the MEMORY and MERGE storage engines handle non-transactional tables and are included by default in MySQL.

Note: The MEMORY storage engine is formally identified as the HEAP engine.

-

InnoDB and BDB storage engines provide transaction-safe tables. BDB is included in the MySQL-Max binary distributions for operating systems that support it. InnoDB is also included by default in all MySQL 5.1 binary distributions, and you can configure MySQL to enable or disable either engine as preferred.

-

The EXAMPLE storage engine is a "stub" engine that does nothing. You can create tables with this engine, but no data is stored or retrieved. This engine serves as an example in the MySQL source code to demonstrate how to start writing a new storage engine. Its main interest is for developers.

-

NDB Cluster is the storage engine used by MySQL Cluster to implement distributed tables across multiple machines. It is provided in the MySQL-Max 5.1 binary distributions. This storage engine is currently supported only on Linux, Solaris, and Mac OS X. In future MySQL distributions, we plan to add support for other platforms, including Windows.

-

The ARCHIVE storage engine is used for storing large amounts of data without indexes in a very small footprint.

-

The CSV storage engine stores data in text files in comma-separated format.

-

The BLACKHOLE storage engine accepts but does not store data, and retrieval always returns an empty set.

-

The FEDERATED storage engine stores data in a remote database. In MySQL 5.1, it works only with MySQL using the MySQL C Client API. In future distributions, we plan to enable it to connect to other data sources using other drivers or client connection methods.

The Most Commonly Used Are MyISAM and InnoDB

| <br> <br> | MyISAM <br> <br> | InnoDB <br> <br> | | Structural Differences: <br> <br> | Each MyISAM is stored on disk as three files. The first file name begins with the table name and the extension indicates the file type. <br> <br>.frm file stores table definitions. <br> <br>Data file extension is .MYD (MYData). <br> <br>Index file extension is .MYI (MYIndex). <br> <br> | Disk-based resources are InnoDB tablespace data files and its log files. The size of an InnoDB table is limited only by the size of the operating system file, typically 2GB. <br> | | Transaction Processing: <br> <br> | MyISAM tables prioritize performance, executing faster than InnoDB, but do not support transactions. <br> <br> | InnoDB supports transactions, foreign keys, and other advanced database features. <br> <br> | | SELECT, UPDATE, INSERT, DELETE Operations <br> | If you perform a large number of SELECTs, MyISAM is a better choice. <br> <br> | 1. If your data involves a large number of INSERTs or UPDATEs, InnoDB should be used for performance reasons. <br> <br> 2. DELETE FROM table, InnoDB deletes rows one by one. <br> <br> 3. LOAD TABLE FROM MASTER operations do not work with InnoDB. The workaround is to first convert the InnoDB table to MyISAM, import the data, and then convert back to InnoDB, but this does not apply to tables using additional InnoDB features like foreign keys. <br> <br> | | AUTO_INCREMENT Handling <br> <br> <br> | Each table has an internal handling of the AUTO_INCREMENT column. <br> <br> MyISAM automatically updates this column for INSERT and UPDATE operations, making it faster (at least 10%). Once the top value in the sequence is deleted, it cannot be reused. <br> <br>AUTO_INCREMENT values can be reset with ALTER TABLE or myisamch. <br> <br>For AUTO_INCREMENT columns in InnoDB, an index must include only that column, but in MyISAM tables, it can be part of a combined index with other columns. <br> <br>Better and faster auto_increment handling. <br> <br> | When you specify an AUTO_INCREMENT column for a table, InnoDB's table handle in the data dictionary includes a counter called the auto-increment counter, used to assign new values to the column. <br> <br>The auto-increment counter is stored only in main memory, not on disk. <br> <br>For the algorithm implementation of this counter, refer to <br> <br> How AUTO_INCREMENT Columns Work in InnoDB <br> <br> | | Table Row Count <br> | select count() from table, MyISAM simply reads the stored row count, but both tables operate the same when the count() statement includes a where condition. <br> <br> | InnoDB does not store the exact row count for a table, so executing select count(*) from table requires InnoDB to scan the entire table to calculate the number of rows. <br> <br> | | Locking <br> | Table-level locking <br> <br> | Row-level locking, providing non-locking reads in SELECTs similar to Oracle, and InnoDB tables may also lock the entire table if MySQL cannot determine the scan range, such as with update table set num=1 where name like "%aaa%" |

How to Choose Between MySQL Storage Engines MyISAM and InnoDB?

Although MySQL offers more storage engines than just MyISAM and InnoDB, these two are the most commonly used. Some site owners may not pay attention to the storage engine used by MySQL, but it is a significant aspect of database design. So, which storage engine should be used for a blog system?

Below, we compare the two storage engines.

Based on these nine differences and the characteristics of personal blogs, it is recommended to use MyISAM for personal blog systems, as the primary operations are reading and writing, with few chain operations. Therefore, choosing MyISAM can make your blog pages load faster than those using InnoDB, although this is just a suggestion. Most blogs should carefully choose based on actual circumstances.

Some considerations for choosing between MyISAM and InnoDB:

MYISAM and INNODB are two storage engines provided by MySQL. Each has its strengths and weaknesses. INNODB supports advanced relational database features like transactions and row-level locking, which MYISAM does not. MYISAM offers better performance and smaller storage space. Therefore, the choice of storage engine depends on specific application needs.

If your application requires transactions, you should undoubtedly choose INNODB. However, note that INNODB's row-level locking is conditional. Without a primary key in the where condition, it can still lock the entire table, such as with DELETE FROM mytable.

If your application prioritizes query performance, choose MYISAM. Its indexes and data are separate, and its indexes are compressed, making it more memory-efficient and faster for queries than INNODB. Compressed indexes also save disk space. MYISAM supports full-text indexing, which optimizes LIKE query efficiency.

Some argue that MYISAM is only suitable for small applications, but this is a misconception. If data volume is large, scaling the architecture, such as sharding and partitioning, rather than relying solely on the storage engine, is necessary.

Other perspectives:

INNODB is generally preferred now, mainly due to MYISAM's table-level locking, serial read-write issues, and lower concurrency due to table locking. MYISAM is typically not chosen for read-write intensive applications.

Regarding the default storage engine for MySQL:

MyISAM and InnoDB are two storage engines for MySQL. If installed by default, it should be InnoDB, as you can find default-storage-engine=INNODB in the my.ini file. You can also specify the storage engine when creating a table. Use show create table xx to see the relevant information.

Comparison Between InnoDB and MyISAM in MySQL

MyISAM:

Each MyISAM is stored on disk as three files. The first file name begins with the table name, and the extension indicates the file type. The .frm file stores table definitions. The data file extension is .MYD (MYData).

MyISAM tables can be compressed and support full-text searches. They do not support transactions or foreign keys. Transaction rollbacks are incomplete and lack atomicity. During updates, table locks are applied, reducing concurrency. If you perform a large number of SELECTs, MyISAM is a better choice.

MyISAM's indexes and data are separate, and its indexes are compressed, making memory usage more efficient. This allows loading more indexes, while InnoDB's indexes and data are tightly bundled, without compression, making InnoDB larger than MyISAM.

MyISAM caches indexes in memory, not data. InnoDB caches data in memory, which means the larger the server memory, the greater the advantage for InnoDB.

Advantages: Faster data queries, suitable for large amounts of select operations, and supports full-text indexing. Disadvantages: Does not support transactions, does not support foreign keys, low concurrency, not suitable for a large number of updates.

InnoDB:

This type is transaction-safe. It has the same features as BDB type and also supports foreign keys. InnoDB tables are fast. It has richer features than BDB, so if you need a transaction-safe storage engine, it is recommended to use it. It locks rows during updates, offering relatively high concurrency. If your data involves a large number of INSERTs or UPDATEs, for performance considerations, you should use InnoDB tables.

Advantages: Supports transactions, supports foreign keys, high concurrency, suitable for a large number of updates.

Disadvantages: Faster data retrieval, not suitable for a large number of selects.

For InnoDB tables that support transactions, the main factor affecting speed is that the default setting for AUTOCOMMIT is on, and the program does not explicitly call BEGIN to start a transaction, resulting in each insertion being automatically committed, which seriously affects speed. You can call begin before executing the SQL, grouping multiple SQL statements into a transaction (even if AUTOCOMMIT is on), which will greatly improve performance.

Basic differences: MyISAM type does not support advanced transaction processing, while InnoDB type does.

MyISAM tables emphasize performance, executing faster than InnoDB, but do not provide transaction support, whereas InnoDB provides transaction support and advanced database features like foreign keys.

Other comparisons:

MyISAM is a newer version of the IASM table with the following extensions:

Here are some detailed and specific differences:

Additionally, InnoDB's row locking is not absolute. If MySQL cannot determine the scan range while executing a SQL statement, InnoDB tables will also lock the entire table, for example, UPDATE table SET num=1 WHERE name LIKE "%aaa%".

No table type is universally perfect; choosing the appropriate type based on the business needs is key to maximizing MySQL's performance advantages.

Comparison of updates between InnoDB and MyISAM:

InnoDB's data organization is based on the primary key as a B+ tree. If no primary key is explicitly defined, InnoDB will select a NOT NULL UNIQUE key as the primary key. If none exists, InnoDB will create a 6-byte primary key. The primary key index points to the page, not the specific row location.

Non-incremental primary keys can slow down insertion, such as using a phone number or ID card number as the primary key, so using AUTO_INCREMENT wisely is recommended.

Large tables are not a problem, but operations like COUNT or high offset LIMITs are. You can replace a large LIMIT with a series of smaller ones:

LIMIT 0 1000 | LIMIT 1001 1000 | LIMIT 2001 1000

LIMIT 0 1000 | WHERE id>max_id1 LIMIT 1000 | WHERE id>max_id2 LIMIT 1000

For InnoDB, partitioning a table by a column to improve performance on a single server is not meaningful.

Insertion speed and query speed can sometimes be incompatible.

Claiming that InnoDB is unsuitable for COUNT operations is incorrect; MyISAM is equally slow, except that MyISAM caches the row count of the entire table, making COUNT operations on the entire table faster. If there is a query condition and it is not a primary key query, there is no difference. The reason primary key COUNT operations are slow is that InnoDB organizes data by the primary key and loads data during such operations.

InnoDB's page-based storage makes it easier for InnoDB to perform whole table caching and hot backups.

If a table has many indexes, InnoDB's update speed is greater than MyISAM's because InnoDB's secondary indexes link to the table's primary key, a logical value, whereas all MyISAM indexes link to the physical location of the data. If the physical location changes upon update, all indexes must be updated.

InnoDB does not store the specific row count of the table, meaning that when executing SELECT COUNT(*) FROM table, InnoDB has to scan the entire table to calculate the number of rows, whereas MyISAM can simply read the stored row count. Note that when the COUNT(*) statement includes a WHERE condition, both tables operate the same way.

Original Source: https://my.oschina.net/junn/blog/183341

❮ Cpp Keyword Intro Java Varargs Parameter ❯