有時候我們會不小心對壹個大表進行了 update，比如說寫錯了 where 條件......
此時，如果 kill 掉 update 線程，那回滾 undo log 需要不少時間。如果放置不管，也不知道 update 會持續多久。
那我們能知道 update 的進度麽？
實驗
我們先創建壹個測試數據庫：
快速創建壹些數據：
連續執行同樣的 SQL 數次，就可以快速構造千萬級別的數據：
查看壹下總的行數：
我們來釋放壹個大的 update：
然後另起壹個 session，觀察 performance_schema 中的信息：
可以看到，performance_schema 會列出當前 SQL 從引擎獲取的行數。
等 SQL 結束後，我們看壹下 update 從引擎總***獲取了多少行：
可以看到該 update 從引擎總***獲取的行數是表大小的兩倍，那我們可以估算：update 的進度 = (rows_examined) / (2 * 表行數)
小貼士information_schema.tables 中，提供了對表行數的估算，比起使用 select count(1) 的成本低很多，幾乎可以忽略不計。
那麽是不是所有的 update，從引擎中獲取的行數都會是表大小的兩倍呢？這個還是要分情況討論的，上面的 SQL 更新了主鍵，如果只更新內容而不更新主鍵呢？我們來試驗壹下：
等待 update 結束，查看 row_examined，發現其剛好是表大小：
那我們怎麽準確的這個倍數呢？
壹種方法是靠經驗：update 語句的 where 中會掃描多少行，是否修改主鍵，是否修改唯壹鍵，以這些條件來估算系數。
另壹種方法就是在同樣結構的較小的表上試驗壹下，獲取倍數。
這樣，我們就能準確估算壹個大型 update 的進度了。