Q:

Throttle DDL statement to avoid impacting performance of other queries

In MySQL, is there any way that I can make an ALTER TABLE or other DDL statement run more slowly, to mitigate its impact on the performance of other queries against the same database? I have found that a long-running DDL statement can cripple the performance of other queries against the database, and I'd like to be able to ALTER huge tables without suffering this impact.
To be clear, this question isn't about locks - online DDL solves most of our locking issues and allows us to run DDL commands on big tables without outright blocking writes to the table. It's purely about mitigating the performance impact that the heavy CPU and IO load imposed by running a DDL statement against a large table can have on the MySQL server. Nor am I interested in strategies that involve setting up a replicating slave on another computer and running the DDL statement there; I know that this is possible, but would prefer the more lightweight approach of just throttling the DDL if that is possible.
MySQL has the LOW_PRIORITY keyword for DML statements to mitigate their performance impact, and there's some discussion on Stack Overflow about the similar-in-principle problem of mitigating the performance impact of mysqldump, but I can't find anything similar for ALTER TABLE statements.

A:

I hope your tables are InnoDB, not MyISAM.  Some of the following will not work well with MyISAM.
Plan A:  Use Percona's pt-online-schema-change.  It is self-throttling.
Plan B:  (You don't like this.)  Many ALTERs can, especially in 5.6 or 5.7, run ALGORITHM=INPLACE, making it much less invasive than the way (ALGORITHM=COPY).
Plan C:  (You don't like this.)  Play replication games.  This leads to virtually zero impact on other queries.
Plan D:  Galera-based replication (PXC, MaraiDB+Galera, etc).  This is also a replication game, but the tools probably make it less effort for the DBA.
Plan E:  If you are adding a column, build a parallel table for the extra column(s).  This has zero impact to set up.
Plan F:  Have a layer of code to hide the original table from the modified table.  Write some extra code to handle, with zero downtime, the transition, regardless of how long it take.
Plan G:  Pay for MEB - it plays some nifty games to make backup faster.

