问题
我们执行 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，不会耗太多电的。
关于 MySQL 的技术内容，你们还有什么想知道的吗？赶紧留言告诉小编吧！
