There can be only one auto column
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
In MySQL, the message “there can be only one auto column” usually refers to the rule around AUTO_INCREMENT: a table can have only one such column, and that column must be indexed. The fix is normally to redesign the key strategy rather than trying to force several independent auto-generated counters into the same table.
What the Error Actually Means
A typical failing table definition looks like this:
MySQL rejects this because only one AUTO_INCREMENT column is allowed per table.
Another common failure is this:
That fails for a different but related reason: the auto-increment column must be part of a key.
So the rule has two parts:
- only one
AUTO_INCREMENTcolumn per table - that column must be indexed
The Normal Correct Pattern
Most tables only need one generated surrogate key:
This is the common design because:
- it gives each row a unique identifier
- inserts remain simple
- joins can use a stable numeric key
If you need more than one unique field, the others should usually be regular columns with UNIQUE constraints, not extra auto-increment counters.
If You Need Another Unique Number
Suppose you want both:
- an internal row ID
- a public-facing ticket number
You still do not get two auto columns in one table. Better options include:
- keep one
AUTO_INCREMENTcolumn and derive the public identifier separately - use a
UNIQUEcolumn populated by application logic - use another table dedicated to sequence generation
- use UUID-style identifiers when sequential numbering is not required
Example with one auto key and one unique business key:
Here, MySQL generates only id, and the application or service layer takes responsibility for ticket_no.
Why MySQL Requires the Auto Column to Be a Key
An AUTO_INCREMENT column is not just a value generator. MySQL uses indexing to manage and retrieve the next sequence value efficiently. That is why the column must be part of an index, typically the primary key.
For InnoDB in particular, the safest and most common design is to make the auto-increment column the primary key:
This matches how MySQL expects the feature to be used in ordinary table design.
Composite Keys and Special Cases
There are advanced cases involving composite indexes, but those are not the right starting point when you hit this error. Most developers encountering the message are not dealing with a special engine feature. They simply need to:
- reduce the table to one auto-generated column
- make that column part of a key
Trying to outsmart the rule is usually a sign that the table design needs simplification.
A Better Database Design Question
When this error appears, the real design question is usually:
“What is the actual primary identity of a row, and which other columns need uniqueness rather than auto-generation?”
That leads to much better schema decisions than treating AUTO_INCREMENT as a general-purpose solution for every numbered field.
Common Pitfalls
- Declaring two different
AUTO_INCREMENTcolumns in the same table. - Forgetting to index the auto-increment column.
- Using
AUTO_INCREMENTfor business identifiers that really need their own domain-specific generation logic. - Confusing “must be unique” with “must be auto-increment.”
- Adding numeric sequence fields without first deciding which one is the actual row key.
Summary
- In MySQL, a table can have only one
AUTO_INCREMENTcolumn. - That column must be indexed, and it is usually the primary key.
- If you need other unique identifiers, use
UNIQUEconstraints or generate them separately. - Do not try to solve every numbering problem with extra auto-increment columns.
- The error is usually a schema-design prompt, not just a syntax issue.
Related reading
- Thinking of storing serialized java objects into cassandra as JSON. What is the catch?
- Thread safe Entity Framework 6
- Throw an error preventing a table update in a MySQL trigger
- TiDB CREATE FUNCTION returns error
- Timestamp comparison in cassandra
- TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT maximum storage sizes
- To what level does MongoDB lock on writes? or what does it mean by per connection
- Tool to create mongodb sharded cluster

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.