Difference Between Keys and Indexes in MySQL
In MySQL, the terms 'key' and 'index' are closely related but not identical. All keys create indexes, but not all indexes are keys. A key has a logical purpose (data integrity, uniqueness, relationships), while an index has a performance purpose (speeding up lookups).
A key is a constraint or rule applied to one or more columns.
Keys ensure data integrity and uniqueness.
Examples: PRIMARY KEY, UNIQUE KEY, FOREIGN KEY.
Every key automatically creates an index to enforce its rule.
An index is a physical data structure used to speed up data retrieval.
Indexes do not enforce rules; they only optimize query performance.
Indexes can be created manually without being a key.
Examples: BTREE index, FULLTEXT index, HASH index.
Purpose: Keys enforce constraints; indexes improve performance.
Logical vs Physical: Keys are logical constraints; indexes are physical structures.
Creation: Keys automatically create indexes; indexes can exist without keys.
Use Case: Keys guarantee correctness; indexes guarantee speed.
Here, idx_email speeds up searches on the email column but does not enforce uniqueness—because it is an index, not a key.
You have a users table with an id column as AUTO_INCREMENT. You also need each email to be unique and queries by email to be fast. How would you use keys and indexes to satisfy both requirements?
If you create a PRIMARY KEY on column id and then add a separate INDEX on id, what does MySQL actually store? Is there any redundancy?
What happens when you query a column that has a UNIQUE KEY but no explicit INDEX—does MySQL still use an index?
We added an INDEX on a status column, but queries filtering by status are still slow. How would you verify whether the index is being used, and why might the distinction between a key and an index matter here?
During a rollout a query that used to be fast started timing out after we added a composite index. Explain how MySQL treats primary keys versus secondary indexes and why that change could affect the query plan.
A developer removed a PRIMARY KEY from a table and replaced it with a UNIQUE KEY on the same column. What differences should you expect in storage and query performance?
Our service stores billions of rows. Should we use a natural primary key (clustered) or a surrogate key with a separate secondary index for lookups? Discuss trade‑offs in storage, write amplification, and range scans.
We need to partition a large table but also enforce uniqueness across partitions. How does the difference between a clustered primary key and non‑clustered secondary indexes influence our partitioning strategy?
A high‑write workload is suffering from index contention. Explain how the fact that secondary indexes store the primary key as a pointer can impact write latency.
The company is migrating from MySQL InnoDB to a distributed SQL system. How would you map the concepts of primary keys and secondary indexes to ensure data consistency and query performance across shards?
Multiple microservices have created overlapping indexes on the same columns, leading to maintenance overhead. Propose a governance model that leverages the distinction between keys and indexes to standardize schema design across teams.
We are planning a long‑term schema evolution that will replace several primary keys with UUIDs. What architectural considerations around index size, replication, and query patterns should guide this migration?