The error arises when you create or alter a table using a storage engine that mandates a PRIMARY KEY but the table definition lacks one.
MySQL Error 1173 ER_REQUIRES_PRIMARY_KEY appears when you create or alter a table with an engine such as InnoDB or NDB that requires a PRIMARY KEY but none exists. Add a PRIMARY KEY column or mark an existing unique NOT NULL column as the PRIMARY KEY to resolve the issue.
This table type requires a primary key
Error 1173 triggers when MySQL processes a CREATE TABLE or ALTER TABLE statement that uses a storage engine demanding a PRIMARY KEY but finds none defined in the table.
InnoDB, NDB Cluster, and several third-party engines rely on a unique, non-null key to build clustered indexes and ensure row identity.
Lacking that key, the engine refuses the operation and MySQL returns ER_REQUIRES_PRIMARY_KEY.
Fixing the problem quickly matters because missing primary keys cause performance issues, replication failures, and broken ORM assumptions.
.
The primary cause is creating a new table without declaring a PRIMARY KEY while using InnoDB or NDB. MySQL validates the schema before execution and aborts when the requirement is unmet.
The same validation runs during ALTER TABLE when converting an existing MyISAM table to InnoDB, adding partitioning, or changing the storage engine in a replication setup.
Add a PRIMARY KEY column that uniquely identifies each row. An AUTO_INCREMENT integer is the simplest option and avoids NULLs.
If a suitable UNIQUE NOT NULL column already exists, mark it as the PRIMARY KEY instead. This avoids adding redundant columns and preserves existing data models.
Creating log tables in InnoDB without keys is common. Declare an id BIGINT AUTO_INCREMENT PRIMARY KEY to satisfy the engine.
Altering legacy MyISAM tables during migrations frequently raises 1173. Issue ALTER TABLE t ADD PRIMARY KEY(id); before switching the engine.
Enforce a design rule that every transactional table includes a single-column numeric primary key. Code reviews and linters can automate the check.
Use MySQL Workbench or Galaxy to visualize schemas and verify key definitions before deployment. Continuous integration can run CREATE DATABASE scripts to catch 1173 early.
Error 1503 (ER_PARSE_ERROR) surfaces if the PRIMARY KEY syntax is malformed. Error 1068 complains when multiple primary keys exist. Checking key definitions addresses both quickly.
InnoDB and NDB refuse tables without a PRIMARY KEY because they require a clustered index for row lookup.
Developers forget to append PRIMARY KEY(id) at the end of the column list when designing new tables.
Switching MyISAM tables to InnoDB without adding a primary key first immediately raises error 1173.
Dump files generated from engines that allow keyless tables fail on restore when the target server defaults to InnoDB.
.
Yes. InnoDB uses the primary key as its clustered index. Without it the engine refuses the table, resulting in error 1173.
Composite keys are valid as long as all columns are NOT NULL and guarantee uniqueness. Ensure they align with your query patterns.
Use pt-online-schema-change or gh-ost to add the key on a shadow table and swap it in place, avoiding locks on large tables.
The source database allowed keyless tables under MyISAM. The target defaults to InnoDB, which requires a primary key, so the import stops.
.avif)
.avif){kind=logo}
