The 5.6 ALTERs that still copy the whole table

5.6’s online DDL gets summarised as “ALTER TABLE no longer locks”, and adding an index really is online now. Several other alterations are not, they are the ones people reach for, and the statement gives no warning whatsoever — it takes the copying path silently and holds a write lock for as long as that takes.

-- in place: writes continue while it runs
ALTER TABLE orders ADD INDEX idx_placed_at (placed_at),
  ALGORITHM=INPLACE, LOCK=NONE;

-- these rebuild by copy, whatever you were expecting:
ALTER TABLE orders MODIFY reference VARCHAR(64) NOT NULL;  -- type change
ALTER TABLE orders DROP PRIMARY KEY;
ALTER TABLE orders CONVERT TO CHARACTER SET utf8mb4;

-- naming the algorithm turns a silent 40-minute lock into an error
ALTER TABLE orders MODIFY reference VARCHAR(64) NOT NULL,
  ALGORITHM=INPLACE, LOCK=NONE;
-- ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason:
--   Cannot change column type INPLACE. Try ALGORITHM=COPY.

The habit worth forming is to name ALGORITHM=INPLACE, LOCK=NONE on every ALTER in a migration. It costs nothing when the operation supports it and fails immediately when it does not, which turns a production incident into a rejected migration on a laptop. What is left is the list that genuinely cannot be done in place — a column type change, dropping a primary key on its own, a character set conversion — and for those the answer is a shadow table with triggers, or pt-online-schema-change, which is that pattern packaged and tested. Note also that in place is not the same as instant: ADD COLUMN is in place and still rebuilds the table, so it is online but not quick, and either way the disk needs room for a second copy.