PHP mysqli::autocommit VS “开始事务”
在我们的数据库层对象中，我们始终使用通过 mysqli::query 执行的“START TRANSACTION”、“ROLLBACK”和“COMMIT”SQL 语句来管理事务。
今天做了一些研究，我发现MySQL手册中提到了这一点 关于使用 API 级调用来管理事务 VS 使用直接 SQL：
重要
许多用于编写MySQL的API 客户端应用程序（例如 JDBC） 提供自己的启动方法 交易可以（有时 应该）使用而不是发送 START TRANSACTION 语句来自 客户。请参阅第 20 章，连接器和 API，或您的文档 API，了解更多信息。
并且，仔细查看 mysqli 后，发现了用于管理事务的 mysqli::autocommit、mysqli::rollback 和 mysqli::commit 方法（http://us.php.net/manual/en/class.mysqli.php）。
我的问题：使用这些 mysqli 等效项是否更好？为什么？我找不到任何地方提到这些函数是否或为什么比直接的 SQL 函数性能更好。
In our database layer object, we have always managed transactions with "START TRANSACTION", "ROLLBACK" and "COMMIT" SQL statements executed via mysqli::query.
Doing some research today, I discovered this mention in the MySQL Manual regarding using API level calls to manage a transaction VS using straight SQL:
Important
Many APIs used for writing MySQL
client applications (such as JDBC)
provide their own methods for starting
transactions that can (and sometimes
should) be used instead of sending a
START TRANSACTION statement from the
client. See Chapter 20, Connectors and
APIs, or the documentation for your
API, for more information.
And, upon looking closer at mysqli, found the mysqli::autocommit, mysqli::rollback and mysqli::commit methods for managing a transaction (http://us.php.net/manual/en/class.mysqli.php).
My question: is it better to use these mysqli equivalents and why? I can find no mention anywhere that says if or why these functions perform better than their straight SQL counterparts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
数据访问包装器可能需要知道事务何时开始/结束，这可能是有原因的。例如，在我的脑海中，连接池方案必须知道先前使用的连接何时在事务中间完成，并且在这种情况下不将其返回到连接池以供重新使用。
我不知道
mysqli中存在任何需要您使用本机方法而不是 SQL 版本的问题，但这可能是在一般情况下......这就是为什么它只是“有时应该” 。无论如何，PHP 方法比 SQL 字符串版本更容易阅读，所以我还是建议采用该方法。It's possible there might be reasons why a data access wrapper would need to know when a transaction was started/ended. For example off the top of my head, a connection-pooling scheme would have to know when a previously-used connection was finished with in the middle of a transaction, and not return it to the connection pool for re-use in that case.
I'm not aware of any issues in
mysqlithat would require you to use the native method rather than the SQL version, but it's possibly in the general case... that's why it's only “sometimes should”. In any case, the PHP method is easier to read than the SQL-string version, so I'd say go with that anyway.