有时候我们会不小心对一个大表进行了update，比如说写错了where条件......
此时，如果kill掉update线程，那回滚undolog需要不少时间。如果放置不管，也不知道update会持续多久。
那我们能知道update的进度么？
实验
我们先创建一个测试数据库：
快速创建一些数据：
连续执行同样的SQL数次，就可以快速构造千万级别的数据：
查看一下总的行数：
我们来释放一个大的update：
然后另起一个session，观察performance_schema中的信息：
可以看到，performance_schema会列出当前SQL从引擎获取的行数。
等SQL结束后，我们看一下update从引擎总共获取了多少行：
可以看到该update从引擎总共获取的行数是表大小的两倍，那我们可以估算：update的进度=(rows_examined)/(2*表行数)
💡小贴士
information_schema.tables中，提供了对表行数的估算，比起使用selectcount(1)的成本低很多，几乎可以忽略不计。
那么是不是所有的update，从引擎中获取的行数都会是表大小的两倍呢？这个还是要分情况讨论的，上面的SQL更新了主键，如果只更新内容而不更新主键呢？我们来试验一下：
等待update结束，查看row_examined，发现其刚好是表大小：
那我们怎么准确的这个倍数呢？
一种方法是靠经验：update语句的where中会扫描多少行，是否修改主键，是否修改唯一键，以这些条件来估算系数。
另一种方法就是在同样结构的较小的表上试验一下，获取倍数。
这样，我们就能准确估算一个大型update的进度了。
