The query runs, but the report is wrong. You see it right there—one missing number, one broken sort. The cause is simple: the database needs a new column.
Adding a new column should be fast and safe, but in production systems it can trigger table locks, grow indexes, or break downstream services. The key is planning. Start with the schema design. Decide if the new column should be nullable or have a default value. Avoid defaults on large tables if they require rewriting the entire table. For boolean or small integer flags, a nullable column with application-level defaults can reduce migration time.
Use online schema change tools when updating large datasets. In MySQL, consider pt-online-schema-change or the native ALTER TABLE ... ALGORITHM=INPLACE where possible. In PostgreSQL, adding a nullable column without a default is instant, but setting non-null constraints later requires validation steps. Always measure the cost on a staging copy of production data before running in live systems.
Check every index. Adding a column to an index can bloat its size and slow write performance. Verify which queries will need the new column and create or adjust indexes only if the gains outweigh the cost. If the column is for analytics, avoid indexing in primary stores and push it to a dedicated read-optimized database or warehouse.