Introduction

Changing a MySQL table’s default character set is not just a metadata tweak. In practice, you usually care about two related but different things: the table default for future columns and the conversion of existing textual data to a new character set and collation.

The Usual Command

The most common operation is:

ALTER TABLE users
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

This does two important things:

• changes the table default character set and collation
• converts existing character columns to the new encoding rules

If your goal is to move old latin1 or utf8 tables to full utf8mb4, this is usually the command you want.

Table Default vs Existing Columns

This distinction matters:

• 'DEFAULT CHARACTER SET changes defaults for new columns'
• 'CONVERT TO CHARACTER SET changes existing textual columns as well'

For example:

ALTER TABLE users
DEFAULT CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

This updates the table default, but it does not necessarily rewrite existing text columns. If the current data must be converted too, use CONVERT TO CHARACTER SET.

Check the Current State First

Before altering anything, inspect the current definition:

SHOW CREATE TABLE users;

Also inspect column-level settings if needed:

SHOW FULL COLUMNS FROM users;

This helps you see whether the table default, individual columns, or both are using the old charset.

Why utf8mb4 Is Usually the Right Target

In modern MySQL systems, utf8mb4 is usually the practical default because it supports the full UTF-8 range, including supplementary characters such as emoji.

Older MySQL usage of utf8 is historically misleading because it is not full UTF-8 coverage. If you are modernizing schema encoding, utf8mb4 is normally the better destination.

Watch for Index and Size Impacts

Changing charset is not always a free schema operation. Wider encodings can affect:

• index size limits
• row size
• storage usage
• sort and comparison behavior through collation changes

That means you should test on a copy of production data before changing a large or heavily indexed table.

Connection and Application Settings Still Matter

Even after the table is converted correctly, bad connection settings can still cause corrupted text on insert or read. Make sure the application connection charset also matches your intended encoding.

A correctly encoded table does not protect you if the client sends bytes under the wrong character-set assumptions.

Column-Specific Overrides

Sometimes a table default is not enough because specific columns were created with explicit charset declarations. In that case, change the columns directly:

1ALTER TABLE users
2MODIFY nickname VARCHAR(100)
3CHARACTER SET utf8mb4
4COLLATE utf8mb4_unicode_ci;

This is useful when only some columns need correction or when you want precise control during migration.

Migration Strategy

For important systems, a safer workflow is:

1. inspect current table and column definitions
2. back up the data
3. test conversion on staging
4. verify indexes and application behavior
5. run the production migration during an appropriate window

Charset migrations are often easy in development and surprisingly disruptive in production if not tested carefully.

Common Pitfalls

The biggest mistake is changing only the table default and assuming existing columns were converted automatically. That depends on the exact ALTER TABLE form you used.

Another issue is ignoring collation. Character set and collation are related but different, and string comparison behavior may change after migration.

Teams also forget the application connection settings, then blame MySQL when newly inserted text is still garbled.

Finally, do not run a charset conversion blindly on large tables without considering index length, downtime, and rollback planning.

Summary

• Use CONVERT TO CHARACTER SET when you want to change both the table default and existing text columns.
• Use DEFAULT CHARACTER SET only when you want future defaults changed.
• 'utf8mb4 is usually the right modern target in MySQL.'
• Inspect current definitions with SHOW CREATE TABLE before migrating.
• Test schema, indexes, and client connection settings together, not in isolation.