The query ran in seconds, but the schema was wrong. A new column was the only fix.
Adding a new column to a relational database table sounds simple. It is not. Done without planning, it can lock tables, block writes, and bring production to a crawl. In high-throughput systems, column migrations can impact replication lag, backups, and cache consistency. The goal is to extend the schema while keeping the system online.
The first step is to define the column name, data type, and constraints. Use ALTER TABLE with precision. On small tables, a blocking alter is fine. On large tables, use an online schema migration tool like pt-online-schema-change or gh-ost. These avoid downtime by creating a shadow table, syncing data, and swapping it in place.
When adding a new column to store computed or reference data, consider default values carefully. A non-null column with a default can cause a full-table write. If a default is needed, adding the column as nullable, backfilling in batches, then altering to non-null is often safer.