MySQL 5.0 indexes - Unique vs Non Unique
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Unique and non-unique indexes in MySQL both speed up lookups, but they serve different purposes. A non-unique index is purely about access performance, while a unique index also enforces a data rule: no two rows may share the same indexed value combination.
What Both Index Types Have in Common
In MySQL 5.0, both unique and non-unique indexes are typically implemented with B-tree structures. That means both can help the optimizer avoid full table scans for equality filters, range queries, joins, and ordered access patterns.
For example:
Both indexes improve search performance, but only idx_email_unique prevents duplicate emails.
What a Unique Index Adds
A unique index guarantees that the indexed column or column combination appears at most once in the table, subject to MySQL's handling of NULL values.
The second insert fails because it violates the unique index on email.
That makes unique indexes useful for business rules such as:
- usernames that must be distinct
- email addresses used as login identifiers
- composite uniqueness such as one order number per store
In other words, a unique index is both a performance feature and an integrity constraint.
What a Non-Unique Index Does Not Do
A non-unique index makes lookup faster but allows repeated values freely.
That is fine with idx_last_name because many users can share the same last name. The index helps MySQL find all Taylor rows quickly, but it does not restrict how many such rows may exist.
Composite Indexes and Uniqueness
Uniqueness can apply to multiple columns together.
This does not mean store_id must be unique and it does not mean order_number must be unique globally. It means the pair of values must be unique together.
That distinction matters in schema design. Many data models need local uniqueness inside a parent entity rather than global uniqueness across the entire database.
Performance Differences
Developers often ask whether unique indexes are faster than non-unique indexes. The answer is "sometimes slightly, but do not choose them for that reason alone."
Because MySQL knows a unique lookup can return at most one row, the optimizer may be able to reason more aggressively about access paths. But the main reason to create a unique index is correctness, not micro-optimization.
On writes, unique indexes can be a little more expensive because MySQL must check for duplicate key violations before accepting the new row. That cost is usually worth it when the data rule is real.
Common Pitfalls
The biggest mistake is using a non-unique index when the data model really requires uniqueness. That leaves data integrity to application code, which is fragile under concurrency and easy to bypass.
Another pitfall is adding a unique index only because you hope it will be faster. If duplicate values are valid, uniqueness is the wrong constraint even if the query pattern looks favorable.
Developers also forget that composite uniqueness applies to the full key, not to each column individually. A unique index on (a, b) still allows repeated a values as long as b differs.
Finally, remember that indexes are not free. Both unique and non-unique indexes consume storage and slow inserts and updates, so create them for real query patterns and real integrity rules.
Summary
- Both unique and non-unique indexes speed up data access in MySQL.
- A unique index also enforces that indexed values, or value combinations, cannot repeat.
- A non-unique index improves lookup performance without restricting duplicates.
- Choose a unique index when uniqueness is a true business rule, not as a guess at performance.
- Composite indexes apply uniqueness to the whole column combination, not each column separately.

