Skip to content

MySQL - Storage Engines

A storage engine is the underlying software component that a database management system, like MySQL, uses to create, read, update, and delete (CRUD) data from a database. MySQL features a pluggable storage engine architecture, allowing you to choose the most suitable engine for your specific needs. Each engine has unique features, performance characteristics, and trade-offs.

Storage engines can be broadly categorized as transactional (supporting ACID properties) and non-transactional. Since MySQL 5.5, InnoDB has been the default and most recommended storage engine for general-purpose use.

Here are some of the most important storage engines available in modern MySQL versions:

  • Default & General Purpose: The default engine for a reason. It’s the best choice for the vast majority of applications.
  • ACID Compliant: Provides full support for transactions (COMMIT, ROLLBACK, SAVEPOINT), ensuring data integrity.
  • Row-Level Locking: Allows for high concurrency by locking only the rows being modified, not the entire table. This is crucial for applications with many simultaneous writers.
  • Crash Recovery: Features automatic crash recovery mechanisms to protect user data from server failures.
  • Foreign Key Constraints: Enforces referential integrity between tables.
  • Legacy Engine: Was the default engine before MySQL 5.5. Its usage in new applications is now rare.
  • Non-Transactional: Does not support transactions, making it unsuitable for applications requiring data integrity guarantees.
  • Table-Level Locking: Locks the entire table during write operations, which can cause significant performance bottlenecks in high-concurrency environments.
  • Specific Use Cases: May still be found in legacy systems or very specific read-mostly scenarios. For full-text search, InnoDB’s capabilities are now on par or superior.
  • In-Memory Storage: Stores all data in RAM for extremely fast access. Ideal for temporary tables, caches, or session management.
  • Volatile: All data is lost when the MySQL server restarts. Not for permanent data storage.
  • Table-Level Locking: Like MyISAM, it uses table-level locking.
  • Data Exchange: Stores data in comma-separated values (.csv) text files. Useful for easily importing or exporting data to be used by other applications like spreadsheets.
  • No Indexing: Does not support indexes, making it unsuitable for general database use.
  • High-Compression Storage: Designed for storing large amounts of un-indexed historical or archival data with a very small footprint. It’s an append-only engine (supports INSERT and SELECT, but not DELETE or UPDATE).
  • Data Sink: The BLACKHOLE engine accepts data but does not store it. It acts like /dev/null. Its primary use is in replication setups to forward SQL statements to replicas without storing the data on the source server.

You can list all available storage engines and check their status with the SHOW ENGINES statement.

SHOW ENGINES;

The output will show a list of engines. The Support column indicates the engine’s status: DEFAULT for the default engine, YES for available, NO for unavailable. The Transactions column is crucial for identifying ACID-compliant engines.

You can specify the storage engine for a new table using the ENGINE clause. If omitted, the server’s default engine (InnoDB) will be used.

-- Creating a temporary table for caching using the MEMORY engine
CREATE TABLE session_data (
session_id VARCHAR(128) PRIMARY KEY,
session_data TEXT,
last_access TIMESTAMP
) ENGINE = MEMORY;

You can convert an existing table to a different storage engine using ALTER TABLE. This operation will rebuild the table and its indexes, which can be time-consuming for large tables.

-- Converting a legacy MyISAM table to InnoDB
ALTER TABLE legacy_table ENGINE = InnoDB;

To check the storage engine of a specific table, you can query the information_schema.

SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME = 'your_table_name';

Working with Storage Engines in Client Programs

Section titled “Working with Storage Engines in Client Programs”

While storage engine management is typically an administrative task done via a SQL client, you can execute these commands from any programming language. Below are examples of how to verify a table’s engine.

import mysql.connector
def get_table_engine(db_config, db_name, table_name):
query = """
SELECT ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA = %s AND TABLE_NAME = %s
"""
try:
with mysql.connector.connect(**db_config) as cnx:
with cnx.cursor() as cursor:
cursor.execute(query, (db_name, table_name))
result = cursor.fetchone()
if result:
print(f"The engine for table '{table_name}' is: {result[0]}")
else:
print(f"Table '{table_name}' not found.")
except mysql.connector.Error as err:
print(f"Database Error: {err}")
# Example usage
db_config = {'user': 'root', 'password': 'password', 'host': '127.0.0.1'}
get_table_engine(db_config, 'your_database_name', 'users')
const mysql = require('mysql2/promise');
async function getTableEngine(dbConfig, dbName, tableName) {
let connection;
try {
connection = await mysql.createConnection(dbConfig);
const query = `
SELECT ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA = ? AND TABLE_NAME = ?
`;
const [rows, fields] = await connection.execute(query, [dbName, tableName]);
if (rows.length > 0) {
console.log(`The engine for table '${tableName}' is: ${rows[0].ENGINE}`);
} else {
console.log(`Table '${tableName}' not found.`);
}
} catch (err) {
console.error(`Database Error: ${err.message}`);
} finally {
if (connection) await connection.end();
}
}
// Example usage
const dbConfig = { host: 'localhost', user: 'root', password: 'password' };
getTableEngine(dbConfig, 'your_database_name', 'users');