This blog post aims to spotlight tables within a MySQL database that do not employ the InnoDB storage engine. The essence of the query is to filter out tables that do not utilize the InnoDB engine, thereby enabling a focused analysis or migration plan for database optimization. Below is the query:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
SELECT table_schema AS 'database_name', table_name, engine FROM information_schema.tables WHERE engine NOT LIKE 'InnoDB' AND table_type = 'BASE TABLE' AND table_schema NOT IN ( 'information_schema', 'sys', 'performance_schema', 'mysql' ) ORDER BY table_schema, table_name; |
Let’s dissect the query to understand its mechanics and objectives better:
- Column Selection: The query targets three specific columns:
table_schema
,table_name
, andengine
. For clarity,table_schema
is aliased asdatabase_name
. This trio of columns provides a concise yet comprehensive overview of each table’s database association, name, and the storage engine it employs. - Data Source: Information is fetched from the
information_schema.tables
table. This meta-database is a treasure trove of data about all other databases and tables within a MySQL environment. By querying this meta-database, users can gain insights into the structural metadata of their databases. - Filters Applied:
- Engine Filter: The primary condition
engine NOT LIKE 'InnoDB'
zeroes in on tables that do not use the InnoDB storage engine. This is crucial for identifying tables that might not be benefiting from the features and performance optimizations offered by InnoDB. - Table Type Filter: By specifying
table_type = 'BASE TABLE'
, the query ensures that only regular tables are considered, excluding views and other non-table database objects. - Schema Exclusion: The query excludes tables from system schemas such as
information_schema
,sys
,performance_schema
, andmysql
. This focus ensures that the analysis is limited to user-created tables, which are more relevant for most optimization and migration tasks.
- Engine Filter: The primary condition
- Sorting: Finally, the results are sorted by
table_schema
andtable_name
, facilitating an organized and readable output. This sorting aids in quickly identifying specific tables and their corresponding databases.
Why Focus on InnoDB?
InnoDB is renowned for its ACID compliance, support for foreign keys, and performance efficiency, especially in transaction-heavy applications. However, there are scenarios where other engines like MyISAM or MEMORY might be used for legacy reasons or specific use cases where these engines offer advantages. Identifying tables not using InnoDB can help assess potential optimizations, migrations, or adjustments needed to align with best practices or application requirements.
In conclusion, this MySQL query is a powerful tool for database professionals aiming to optimize their database environments. Identifying tables not leveraging InnoDB opens up avenues for enhancements, ensuring that databases are configured for optimal performance and reliability.
Thanks for this Vinicius, and totally agree. I just wanted to help others who might be migrating from non-mysql flavours to the latest mysql, as I am, and come across charset and collation issues here. It’s not directly related to the “migrate to innodb” issue at hand, but if anyone else if migrating from another charset like utf8 to utf8mb4, I came across the issue mentioned in https://stackoverflow.com/questions/42918231/getting-duplicate-entry-errors-when-converting-utf-8-database-to-utf8mb4 by getting duplicate key errors upon data loading. Basically changed the charset for the table to utf8 (or utf8mb3) so that the data didn’t get duplicated rows, and so the developers can now start to denormalize.
Hi Keith,
Thanks for sharing your experience! Indeed charset and collation is a very common issue for those who are migrating or upgrading their database. Maybe in near future I will write something about this.