Observing When MySQL DDL Operations Are Killed Using GDB

The article investigates how quickly a MySQL DDL statement is terminated after issuing a KILL command by focusing on the moment the kill is detected, not the full rollback duration.

First, a MySQL instance is started in debug mode (using the --debug flag). A simple table with four rows is created, and a GDB script is prepared that sets a breakpoint on the InnoDB function trx_is_interrupted , which is responsible for checking whether the current thread has been killed.

When the breakpoint is hit, GDB prints the current stack trace, allowing the author to see which part of the DDL execution triggered the kill check. An ALTER statement is then executed, and the generated GDB log is examined.

The stack traces reveal several points where MySQL checks for a kill:

During the read of the clustered index from the old table.

While writing the index to the new table.

After flushing the rebuilt index to disk.

When replaying the online DDL log to the new table.

If a kill occurs during any of these phases, the DDL operation begins to roll back promptly.

Official MySQL documentation confirms that for large data operations MySQL performs periodic kill checks after processing a chunk of data, which aligns with the observed behavior in steps 1, 2, and 4.

The article notes that a kill may not be detected instantly if the processing of a chunk is slow or if the flush operation in step 3 is delayed; in such cases the kill is only recognized at the next check point.

Overall, the experiment provides a practical method to pinpoint where MySQL evaluates a kill request during DDL execution and highlights the factors that influence the responsiveness of the kill operation.