事务具有ACID特性（atomicity原子性、consistency一致性、isolation隔离性、持久性durability）

原子性（atomicity）

每个事务都是一个整体，即最小的工作单元。整个事务中所有操作要么全部提交成功，要么全部失败回滚，不能只执行事务中的一部分操作，这就是事务的原子性。

一致性（consistency）

事务中每个操作的状态是一致的，即不会一部分执行成功，一部分执行失败，若其中有失败的操作，则会将前面成功的操作全部回滚，且事务不会提交，事务中之前执行成功的操作也不会保存到数据库中，这就是事务的一致性。

隔离性（isolation）

通常来说，事务所做的修改在最终提交以前，对其他事务来说是不可见的。例如一个事务A中有四个步骤，当前三步已经修改过数据，第四步还未执行时，另外一个事务B查询对应数据，得到的是事务A中前三步骤修改之前的数据。
另外，此特性与数据库的隔离级别有关，上述情况只能属于是通常情况，因为隔离级别可更改，详情请见《隔离级别》文章。

持久性（durability）

一旦事务提交，其所做的修改就会永久保存到数据库。此时若数据库系统崩溃，修改的数据也不会丢失。
但持久性也有不同级别的区分，并不是所有级别都能达到上述标准，而且实际情况中，也无法100%做到上述的情况，否则数据库备份就没有意义了。持久性策略详情请见《持久性策略》文章。

总结

事务的ACID特性可以确保资金流动时不会弄丢资金，但在实际应用中，要完全实现这一点非常难。一个兼容ACID的数据库系统，需要做很多复杂但用户无法察觉到的工作，才能确保ACID的实现。
类似锁粒度的升级会增加系统开销一样，这种事务处理过程中额外的安全性也会需要数据库系统做更多的额外工作，因此也需要更强的CPU处理能力、更大的内存和更多的磁盘空间。
MySQL的存储引擎架构（详情请见《存储引擎》文章）可以让使用者根据业务是否需要事务，来选择适合的存储引擎，比如一些不需要事务的查询类应用，可以选择非事务型的存储引擎，这样就可以拥有更高的性能。即使存储引擎不支持事务，也可以通过LOCK TABLES语句为应用提供一定程度的保护，这些选择用户都可以自主决定。