问题描述
此应用程序正在使用RDS / MysqL（5.7）在AWS EC2上运行。
我们有一个审核脚本，该脚本正在访问MysqL用户表中的每个用户。 \
对于每个用户，我们
- 无条件开始交易，
- 可能会更改用户的记录和其他表。
- 无条件提交交易。
现在，在第2步中（很常见）没有对任何表进行任何更改。在代码检查期间，出现了一个问题，即在未进行任何更改的情况下，启动/提交许多记录的事务对性能的影响。
我在其他地方读到MysqL是针对提交而不是回滚进行优化的。但是我还没有找到关于在没有任何工作的情况下开始/提交交易的成本的讨论。
解决方法
请记住，一旦您读取InnoDB表，无论是否显式“开始交易”，InnoDB都会执行类似的工作。
启动事务的替代方法是依靠 autocommit 。但是自动提交并不意味着没有交易发生。自动提交意味着当您的查询接触到InnoDB表时，事务隐式启动，并且查询完成后，事务将自动提交。您不能运行多个语句，也不能回滚，但它与显式事务相同。
通过避免避免开始交易，您并没有真正节省任何东西。
,短期交易没有很大的成本。
当实际进行更改时，最小的交易成本开始出现。
仅当在回滚期间需要更改数据时，回滚才是昂贵的，否则它是相当空的操作。
在没有任何更改的情况下进行（可能回滚）不应造成任何惩罚。
,绝对有开销，这可能非常重要。我最近与一个恰好有此问题（由于ORM中的错误导致大量空提交）的客户端一起工作，并且他们的数据库在空提交时消耗了大约30％的CPU。
用long_query_time = 0（重要！）捕获一天的慢速日志，通过mysqldumpslow或pt-query-digest记录下来，看看是否有一个查询COMMIT;用光了CPU。