MySQL 5.6 adds an index without copying the table

Adding an index to a large InnoDB table on 5.5 rebuilds it into a copy and blocks writes for the whole operation, which is why the index that would fix the slow page gets scheduled for a Sunday night and then postponed. 5.6 went GA in February with in-place DDL for most index work, and the table stays writable.

-- 5.5: rebuilds the table, writes blocked until it finishes
ALTER TABLE order_lines
  ADD INDEX idx_customer_created (customer_id, created_at);

-- 5.6: in place, reads and writes continue
ALTER TABLE order_lines
  ADD INDEX idx_customer_created (customer_id, created_at),
  ALGORITHM=INPLACE, LOCK=NONE;

5.6 picks the in-place path on its own, so the two clauses look redundant. They are worth writing anyway, because naming them turns a silent fallback into an immediate error: an operation that cannot be done in place fails in a second instead of starting a four-hour table copy that nobody noticed beginning. Plenty still does not qualify — changing a column type, adding a primary key, converting the character set. And “online” is not “free”: concurrent changes accumulate in a log capped by innodb_online_alter_log_max_size, 128MB by default, and overflowing it aborts the ALTER at the end, after all the work. On a 5.5 server the answer remains pt-online-schema-change.