MySQL

MySQL utf8mb4 Collation Choices and Index Performance

4 min read by DebuggedIt

Quick answer

In MySQL, always use utf8mb4 for text, since the older utf8 alias supports only three bytes per character and cannot store all Unicode, including emoji. The...

In MySQL, always use utf8mb4 for text, since the older utf8 alias supports only three bytes per character and cannot store all Unicode, including emoji. The collation then decides how strings compare and sort, which affects unique constraints, search behavior, and index use. Pick one collation consistently across tables and connections, because mixing them can prevent index use and cause errors.

What Is the Difference Between Character Set and Collation?

A character set defines which characters can be stored and how they are encoded. A collation defines the rules for comparing and sorting them, including whether comparisons are case sensitive, accent sensitive, and how characters are ordered.

The historical utf8 character set in MySQL is a limited three-byte variant. The utf8mb4 character set uses up to four bytes and supports the full Unicode range. Modern MySQL versions use utf8mb4 as the default, and the utf8 name has been treated as an alias in some versions, so check the documentation for your version to avoid ambiguity.

Collation names describe their rules. A suffix of ci means case insensitive, cs means case sensitive, ai and as describe accent insensitivity and sensitivity, and bin means comparison by raw bytes. Newer collations based on recent Unicode standards, such as the 0900 family in MySQL 8, differ in behavior and performance from older general collations.

How Do Collations Affect Queries and Constraints?

The collation determines what counts as equal. With a case insensitive collation, Alice and alice are the same value. That affects unique indexes: inserting both would violate a unique constraint. Accent handling works similarly, so some collations treat e and its accented forms as equal.

  • Unique constraints: uniqueness follows the collation, so two values that look different can conflict.
  • Sorting: ORDER BY follows collation rules, which differ for languages and special characters.
  • Searching: equality and LIKE comparisons follow the collation unless you override it.
  • Case sensitivity needs: for tokens, hashes, or identifiers that must be exact, use a binary or case-sensitive collation on those columns.

Decide per column based on meaning. Email addresses and usernames often use a case insensitive collation, while API keys and hashes should compare exactly.

Why Can Mixed Collations Hurt Index Performance?

When you compare or join columns with different collations, MySQL may need to convert one side, and conversion can prevent the use of an index on that column. A join that should be a fast index lookup turns into a scan, and the problem is invisible in the query text.

Connection settings matter too. The client connection has its own character set and collation, and literals in queries use them. If the connection collation differs from the column collation, comparisons may raise a mixed collation error or silently use a less efficient plan, depending on the situation and version.

  • Use the same character set and collation for columns that are joined or compared with each other.
  • Set the connection character set explicitly in your driver or connection string.
  • Check EXPLAIN for unexpected scans on joins between tables created at different times.
  • Remember that utf8mb4 indexes can be larger than older encodings, so check index key length limits for long string columns.

How Do You Migrate and Choose Safely?

For new projects, choose a current utf8mb4 collation and apply it as a database default, so all tables and columns inherit it. Pick the collation that matches your language needs, and test sorting with real data.

For existing databases, convert carefully. Changing a table's character set rewrites it, which is a heavy operation on large tables and may require online schema change techniques. Also check for data that will not convert cleanly, and for unique indexes that may start failing because values that were distinct under the old collation become equal under the new one.

  • Audit current character sets and collations across tables, columns, and connections.
  • Test conversion on a copy, and look for duplicate key errors and index length errors.
  • Convert in stages, starting with the least critical tables.
  • Update application connection settings together with the schema changes.

Frequently Asked Questions

Should I still use the utf8 character set in MySQL?

No. Use utf8mb4, which stores the full Unicode range, including emoji.

Does collation affect index usage?

Yes. Comparing columns with different collations can force conversion and prevent an index from being used.

Is a case insensitive collation slower?

Differences exist between collations, but design and consistency usually matter more. Benchmark if it matters.

How do I make a column compare case sensitively?

Use a case sensitive or binary collation on that column, or apply a collation in the query where appropriate.

Summary

Use utf8mb4, choose collations deliberately, keep them consistent across joined columns and connections, and migrate carefully. Check the MySQL documentation for the collations available in your version.