When you add a new column to a production database, you change both storage and query plans. The impact can be small or catastrophic depending on size, type, and indexing. A careless ALTER TABLE can lock rows, slow writes, and cause unexpected replication lag. You must plan for the exact effect on reads, writes, and downstream systems.
Define the column with precise data types. Avoid overly wide fields—use INT instead of BIGINT when possible, and restrict text lengths to what's necessary. Set nullability rules early to prevent future schema drift. Apply indexes only when the query data supports them; every index adds storage cost and write overhead.
Run migrations in a controlled pipeline. Test on a full copy of production data to measure execution time. For large datasets, consider using online schema change tools like pt-online-schema-change or native engine features to avoid downtime. Always monitor the database during and after the migration. Check CPU, memory, and I/O metrics in real time.