关于sql:第17问如何评估-alter-table-的进度

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

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

MySQL 官网曾经给出了文档：https://dev.mysql.com/doc/ref…，咱们来实际一下：

先建个数据库：

咱们设置了一些跟 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 的技术内容，你们还有什么想晓得的吗？连忙留言通知小编吧！

问题

试验