Changing a MySQL database default does not convert existing text columns. A safe utf8mb4 migration inventories current definitions, confirms how bytes are actually encoded, converts related tables together, and verifies indexes and application connections.
Last updated: September 26, 2026.
ALTER DATABASE appdb
CHARACTER SET utf8mb4
COLLATE utf8mb4_0900_ai_ci;
ALTER TABLE customers
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_0900_ai_ci;Choose a collation supported by the deployed MySQL version and consistent with the required case and accent rules. MySQL 5.7 installations commonly need an older utf8mb4 collation.
Inventory before conversion
Query information_schema.columns for character sets and collations, and inspect table defaults. Test representative values containing accents, non-Latin scripts, and emoji. If a column claims latin1 but actually stores UTF-8 bytes, CONVERT TO CHARACTER SET can transform the already-misinterpreted text again; repair that data separately.
Plan for locks, indexes, and foreign keys
Character-set conversion can rebuild a table and increase byte requirements. Check long indexed varchar columns, available disk space, replication lag, and maintenance-window requirements. Related foreign-key text columns must have compatible definitions. MySQL’s utf8mb3-to-utf8mb4 guidance highlights index-length and type considerations.
- Back up and verify a restore.
- Convert a staging copy first.
- Set connection character sets explicitly.
- Convert in dependency-aware batches.
- Run application and data-integrity tests.
Verify the application path
Confirm client drivers negotiate utf8mb4 and do not issue a later SET NAMES latin1. Insert, retrieve, search, sort, export, and re-import multilingual text. If comparisons fail after conversion, use the MySQL collation conflict checklist rather than applying arbitrary COLLATE clauses everywhere.
