0

目前，我们的每个 MySQL 事务都在计算并将 100K+~百万行更新为一个 100K 到十亿行的表。有时此类交易由于不明原因而失败，我们正在尝试对其进行分类。有人建议限制每个事务中的行数（小于 100 Ks）是一个很好的做法。但是，我们希望更好地量化我们案例中的交易限制。此外，我们希望通过在事务失败期间包含更多系统状态来使事务错误消息更具信息性，以便我们可以
自信地知道当前硬件规范中的事务限制是多少。有两分钱吗？现在我们在事务失败时打印 MySQL“显示变量”，并且还使用 grafana 半手动比较系统资源。 https://grafana.com/ 这很费力，可能不准确，因为 grafana 可能有一些延迟等。

谢谢。

4

1 回答 1

1

与其试图分析一个太大的交易，让我们讨论一下消除它的选项。

是否可以一次将其分成 10K 行？也就是说，在每 10K 行之后，有一个COMMIT. 这会将一个事务分解为多个事务。从性能和崩溃的角度来看，这是一个绝对的胜利。从 ACID 的角度来看，你需要回答这个问题。

假设你可以把它分开，我推荐这里给出的技术作为一种有效执行查询的可能方法：http: //mysql.rjweb.org/doc.php/deletebig#deleting_in_chunks（是的，稍作改动，它适用于UPDATE.)

于 2017-09-12T18:52:34.870 回答