-[14.1.1 Benefits of Using InnoDB Tables](https://dev.mysql.com/doc/refman/5.7/en/innodb-benefits.html)
-[14.1.2 Best Practices for InnoDB Tables](https://dev.mysql.com/doc/refman/5.7/en/innodb-best-practices.html)
-[14.1.3 Verifying that InnoDB is the Default Storage Engine](https://dev.mysql.com/doc/refman/5.7/en/innodb-check-availability.html)
-[14.1.4 Testing and Benchmarking with InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-benchmarking.html)
-[14.1.5 Turning Off InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-turning-off.html)
<aname="14.1"></a>
[TOC]
`InnoDB` is a general-purpose storage engine that balances high reliability and high performance. In MySQL 5.7, `InnoDB` is the default MySQL storage engine. Unless you have configured a different default storage engine, issuing a [`CREATE TABLE`](https://dev.mysql.com/doc/refman/5.7/en/create-table.html) statement without an `ENGINE=` clause creates an `InnoDB` table.
### Key Advantages of InnoDB
- Its [DML](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_dml) operations follow the [ACID](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_acid) model, with [transactions](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_transaction) featuring [commit](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_commit), [rollback](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_rollback), and [crash-recovery](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_crash_recovery) capabilities to protect user data. See [Section 14.2, “InnoDB and the ACID Model”](https://dev.mysql.com/doc/refman/5.7/en/mysql-acid.html) for more information.
- Row-level [locking](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_locking) and Oracle-style [consistent reads](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_consistent_read) increase multi-user concurrency and performance. See [Section 14.7, “InnoDB Locking and Transaction Model”](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking-transaction-model.html) for more information.
-`InnoDB` tables arrange your data on disk to optimize queries based on [primary keys](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_primary_key). Each `InnoDB` table has a primary key index called the [clustered index](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_clustered_index) that organizes the data to minimize I/O for primary key lookups. See [Section 14.6.2.1, “Clustered and Secondary Indexes”](https://dev.mysql.com/doc/refman/5.7/en/innodb-index-types.html) for more information.
- To maintain data [integrity](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_referential_integrity), `InnoDB` supports [`FOREIGN KEY`](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_foreign_key) constraints. With foreign keys, inserts, updates, and deletes are checked to ensure they do not result in inconsistencies across different tables. See [Section 13.1.18.5, “FOREIGN KEY Constraints”](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html) for more information.
| **Backup/point-in-time recovery** (Implemented in the server, rather than in the storage engine.) | Yes |
| **Cluster database support** | No |
| **Clustered indexes** | Yes |
| **Compressed data** | Yes |
| **Data caches** | Yes |
| **Encrypted data** | Yes (Implemented in the server via encryption functions; In MySQL 5.7 and later, data-at-rest tablespace encryption is supported.) |
| **Foreign key support** | Yes |
| **Full-text search indexes** | Yes (InnoDB support for FULLTEXT indexes is available in MySQL 5.6 and later.) |
| **Geospatial data type support** | Yes |
| **Geospatial indexing support** | Yes (InnoDB support for geospatial indexing is available in MySQL 5.7 and later.) |
| **Hash indexes** | No (InnoDB utilizes hash indexes internally for its Adaptive Hash Index feature.) |
| **Index caches** | Yes |
| **Locking granularity** | Row |
| **MVCC** | Yes |
| **Replication support** (Implemented in the server, rather than in the storage engine.) | Yes |
| **Storage limits** | 64TB |
| **T-tree indexes** | No |
| **Transactions** | Yes |
| **Update statistics for data dictionary** | Yes |
To compare the features of `InnoDB` with other storage engines provided with MySQL, see the *Storage Engine Features* table in [Chapter 15, *Alternative Storage Engines*](https://dev.mysql.com/doc/refman/5.7/en/storage-engines.html).
### InnoDB Enhancements and New Features
For information about `InnoDB` enhancements and new features, refer to:
- The `InnoDB` enhancements list in [Section 1.3, “What Is New in MySQL 5.7”](https://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html).
- The [Release Notes](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/).
### Additional InnoDB Information and Resources
- For `InnoDB`-related terms and definitions, see the [MySQL Glossary](https://dev.mysql.com/doc/refman/5.7/en/glossary.html).
- For a forum dedicated to the `InnoDB` storage engine, see [MySQL Forums::InnoDB](http://forums.mysql.com/list.php?22).
-`InnoDB` is published under the same GNU GPL License Version 2 (of June 1991) as MySQL. For more information on MySQL licensing, see http://www.mysql.com/company/legal/licensing/.
<aname="14.1.1"></a>
### 14.1.1 Benefits of Using InnoDB Tables
You may find `InnoDB` tables beneficial for the following reasons:
- If your server unexpectedly exits because of a hardware or software issue, regardless of what was happening in the database at the time, you don't need to do anything special after restarting the database. `InnoDB`[crash recovery](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_crash_recovery) automatically finalizes any changes that were committed before the time of the crash, and undoes any changes that were in process but not committed. Just restart and continue where you left off.
- The `InnoDB` storage engine maintains its own [buffer pool](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_buffer_pool) that caches table and index data in main memory as data is accessed. Frequently used data is processed directly from memory. This cache applies to many types of information and speeds up processing. On dedicated database servers, up to 80% of physical memory is often assigned to the buffer pool.
- If you split up related data into different tables, you can set up [foreign keys](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_foreign_key) that enforce [referential integrity](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_referential_integrity). Update or delete data, and the related data in other tables is updated or deleted automatically. Try to insert data into a secondary table without corresponding data in the primary table, and the bad data gets kicked out automatically.
- If data becomes corrupted on disk or in memory, a [checksum](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_checksum) mechanism alerts you to the bogus data before you use it.
- When you design your database with appropriate [primary key](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_primary_key) columns for each table, operations involving those columns are automatically optimized. It is very fast to reference the primary key columns in [`WHERE`](https://dev.mysql.com/doc/refman/5.7/en/select.html) clauses, [`ORDER BY`](https://dev.mysql.com/doc/refman/5.7/en/select.html) clauses, [`GROUP BY`](https://dev.mysql.com/doc/refman/5.7/en/select.html) clauses, and [join](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_join) operations.
- Inserts, updates, and deletes are optimized by an automatic mechanism called [change buffering](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_change_buffering). `InnoDB` not only allows concurrent read and write access to the same table, it caches changed data to streamline disk I/O.
- Performance benefits are not limited to giant tables with long-running queries. When the same rows are accessed over and over from a table, a feature called the [Adaptive Hash Index](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_adaptive_hash_index) takes over to make these lookups even faster, as if they came out of a hash table.
- You can compress tables and associated indexes.
- You can create and drop indexes with much less impact on performance and availability.
- Truncating a [file-per-table](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_file_per_table) tablespace is very fast, and can free up disk space for the operating system to reuse, rather than freeing up space within the [system tablespace](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_system_tablespace) that only `InnoDB` can reuse.
- The storage layout for table data is more efficient for [`BLOB`](https://dev.mysql.com/doc/refman/5.7/en/blob.html) and long text fields, with the [DYNAMIC](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_dynamic_row_format) row format.
- You can monitor the internal workings of the storage engine by querying [INFORMATION_SCHEMA](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_information_schema) tables.
- You can monitor the performance details of the storage engine by querying [Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_performance_schema) tables.
- You can freely mix `InnoDB` tables with tables from other MySQL storage engines, even within the same statement. For example, you can use a [join](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_join) operation to combine data from `InnoDB` and [`MEMORY`](https://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html) tables in a single query.
-`InnoDB` has been designed for CPU efficiency and maximum performance when processing large data volumes.
-`InnoDB` tables can handle large quantities of data, even on operating systems where file size is limited to 2GB.
For `InnoDB`-specific tuning techniques you can apply in your application code, see [Section 8.5, “Optimizing for InnoDB Tables”](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb.html).
<aname="14.1.2"></a>
### 14.1.2 Best Practices for InnoDB Tables
This section describes best practices when using `InnoDB` tables.
- Specifying a [primary key](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_primary_key) for every table using the most frequently queried column or columns, or an [auto-increment](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_auto_increment) value if there is no obvious primary key.
- Using [joins](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_join) wherever data is pulled from multiple tables based on identical ID values from those tables. For fast join performance, define [foreign keys](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_foreign_key) on the join columns, and declare those columns with the same data type in each table. Adding foreign keys ensures that referenced columns are indexed, which can improve performance. Foreign keys also propagate deletes or updates to all affected tables, and prevent insertion of data in a child table if the corresponding IDs are not present in the parent table.
- Turning off [autocommit](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_autocommit). Committing hundreds of times a second puts a cap on performance (limited by the write speed of your storage device).
- Grouping sets of related [DML](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_dml) operations into [transactions](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_transaction), by bracketing them with `START TRANSACTION` and `COMMIT` statements. While you don't want to commit too often, you also don't want to issue huge batches of [`INSERT`](https://dev.mysql.com/doc/refman/5.7/en/insert.html), [`UPDATE`](https://dev.mysql.com/doc/refman/5.7/en/update.html), or [`DELETE`](https://dev.mysql.com/doc/refman/5.7/en/delete.html) statements that run for hours without committing.
- Not using [`LOCK TABLES`](https://dev.mysql.com/doc/refman/5.7/en/lock-tables.html) statements. `InnoDB` can handle multiple sessions all reading and writing to the same table at once, without sacrificing reliability or high performance. To get exclusive write access to a set of rows, use the [`SELECT ... FOR UPDATE`](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking-reads.html) syntax to lock just the rows you intend to update.
- Enabling the [`innodb_file_per_table`](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_file_per_table) option or using general tablespaces to put the data and indexes for tables into separate files, instead of the [system tablespace](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_system_tablespace).
The [`innodb_file_per_table`](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_file_per_table) option is enabled by default.
- Evaluating whether your data and access patterns benefit from the `InnoDB` table or page [compression](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_compression) features. You can compress `InnoDB` tables without sacrificing read/write capability.
- Running your server with the option [`--sql_mode=NO_ENGINE_SUBSTITUTION`](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode) to prevent tables being created with a different storage engine if there is an issue with the engine specified in the `ENGINE=` clause of [`CREATE TABLE`](https://dev.mysql.com/doc/refman/5.7/en/create-table.html).
<aname="14.1.3"></a>
### 14.1.3 Verifying that InnoDB is the Default Storage Engine
Issue the [`SHOW ENGINES`](https://dev.mysql.com/doc/refman/5.7/en/show-engines.html) statement to view the available MySQL storage engines. Look for `DEFAULT` in the `InnoDB` line.
```sql
mysql>SHOWENGINES;
```
Alternatively, query the [`INFORMATION_SCHEMA.ENGINES`](https://dev.mysql.com/doc/refman/5.7/en/information-schema-engines-table.html) table.
```sql
mysql>SELECT*FROMINFORMATION_SCHEMA.ENGINES;
```
<aname="14.1.4"></a>
### 14.1.4 Testing and Benchmarking with InnoDB
If `InnoDB` is not your default storage engine, you can determine if your database server or applications work correctly with `InnoDB` by restarting the server with [`--default-storage-engine=InnoDB`](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_default_storage_engine) defined on the command line or with [`default-storage-engine=innodb`](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_default_storage_engine) defined in the `[mysqld]` section of your MySQL server option file.
Since changing the default storage engine only affects new tables as they are created, run all your application installation and setup steps to confirm that everything installs properly. Then exercise all the application features to make sure all the data loading, editing, and querying features work. If a table relies on a feature that is specific to another storage engine, you receive an error; add the `ENGINE=*`other_engine_name`*` clause to the [`CREATE TABLE`](https://dev.mysql.com/doc/refman/5.7/en/create-table.html) statement to avoid the error.
If you did not make a deliberate decision about the storage engine, and you want to preview how certain tables work when created using `InnoDB`, issue the command [`ALTER TABLE table_name ENGINE=InnoDB;`](https://dev.mysql.com/doc/refman/5.7/en/alter-table.html) for each table. Or, to run test queries and other statements without disturbing the original table, make a copy:
To assess performance with a full application under a realistic workload, install the latest MySQL server and run benchmarks.
Test the full application lifecycle, from installation, through heavy usage, and server restart. Kill the server process while the database is busy to simulate a power failure, and verify that the data is recovered successfully when you restart the server.
Test any replication configurations, especially if you use different MySQL versions and options on the source server and replicas.
<aname="14.1.5"></a>
### 14.1.5 Turning Off InnoDB
Oracle recommends `InnoDB` as the preferred storage engine for typical database applications, from single-user wikis and blogs running on a local system, to high-end applications pushing the limits of performance. In MySQL 5.7, `InnoDB` is the default storage engine for new tables.
> Important
`InnoDB` cannot be disabled. The [`--skip-innodb`](https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#option_mysqld_innodb) option is deprecated and has no effect, and its use results in a warning. Expect it to be removed in a future MySQL release. This also applies to its synonyms (`--innodb=OFF`, `--disable-innodb`, and so forth).
