问题

我们执行 alter table 语句后，经常面临“跑又跑不完，杀又不敢杀”的窘境。

如果能评估 alter table 的进度就幸福多了。

实验

MySQL官方已经给出了文档：https://dev.mysql.com/doc/refman/5.7/en/monitor-alter-table-performance-schema.html，我们来实践一下：

先建个数据库：

我们设置了一些跟 performance_schema 相关的参数，开启了查看进度必要的功能。

还是按照之前实验 11 的技巧，快速造一些数据：

重复执行 insert，让表中有足够数据：

我们来跑一个alter table：

在另一个 session 中，执行 SQL 查看进度：

看起来 SQL 比较复杂，我们先来看看效果：

这里列出了正在执行的 DDL SQL，进度评估，当前运行语句的时间，和估算的剩余时间。

不断获取进度：

可以看到，估算的剩余时间不是完全精确，在整个过程中，进度在不停被评估。不过这种精确度对于我们也足够用了。

我们来看看评估的主要原理：

在这张表里，MySQL 提供了如下信息：

• DDL 语句运行的当前阶段

• 当前阶段的开始时间和结束时间，当前阶段未结束时，结束时间为当前时间

• 父事件 ID，语句运行的各个阶段，会具有相同的父事件 ID

• 工作量评估，MySQL 将 DDL 的运行过程拆成一个一个任务包，这里提供了已经完成的任务包数量和估算的任务包总数量，两者的比值即为当前进度

（注意：这里的时间是当前阶段的时间，而工作量评估是整个语句的工作量）

这下我们使用的评估 SQL 就不难看懂了：

附上评估语句的文字版：

select    stmt.SQL_TEXT as sql_text,    concat(WORK_COMPLETED, '/' , WORK_ESTIMATED) as progress,    (stage.TIMER_END - stmt.TIMER_START) / 1e12 as current_seconds,    (stage.TIMER_END - stmt.TIMER_START) / 1e12 * (WORK_ESTIMATED-WORK_COMPLETED) / WORK_COMPLETED as remaining_seconds    from events_stages_current stage, events_statements_current stmt    where stage.THREAD_ID = stmt.THREAD_ID      and stage.NESTING_EVENT_ID = stmt.EVENT_ID;

小贴士

肯定会有同学问：那开启 performance_schema 会不会影响性能呢？

答：在美好的生活面前，不要因噎废食，多用 1% 的 CPU，不会耗太多电的。