CURD加控制
模拟一个买票系统的场景如下所示：
MySQL注定会被多个客户端进行访问的，这个是肯定的，存储的都是数据，数据在上层可能有一个线程在用，另一个线程也想从数据库中获取，还有其他的客户端也想获取数据，数据被所有人共享，所以mysqld服务会有多个请求过来让我们进行数据的CURD操作，MySQL内部是采用多线程的方式实现数据的存储的相关操作，所以会有对数据的并发访问的场景。所以关系型数据库提供了事务，MySQL一般设置的更完善一些。
实际场景：
在一个卖票系统中，包含了票的id，name,以及数量nums,客户端A检查还有一张票时，把票卖掉，还没执行更新数据库时，客户端B检查了票数，发现大于0，于是又卖了一次票，然后A将票数更新会数据库，这是同一张票被卖了两次,这是不符合正常的业务逻辑的。
CURD需要满足以下属性，解决上面所出现的问题：
买票的过程得是原子的、买票应该不能互相影响、买完票应该要永久有效、买前与买后都要是确定的状态
什么是事物
事务就是一组DML语句组成，这些语句在逻辑上存在相关性，这一组DML语句要么全部成功，要么全部失败，是一个整体。MySQL提供一种机制，保证我们达到这样的效果。事务还规定不同的客户端看到的数据是不相同的
事务就是要做的或所做的事情，主要用于处理操作量大，复杂度高的数据。比如：当你毕业了，对于教务系统后台 MySQL 中，就不需要你的数据了，那么要删除你的基本信息(如姓名，电话，籍贯等等这些)的同时，也会删除和你有关的其他信息，比如：各科的成绩，在校表现，甚至你在论坛发过的文章等。这样，就需要多条 MySQL 语句构成，那么所有这些操作合起来，就构成了一个事务。
对于一个MuSQL数据库，可不止一个事务在运行，同一时刻，甚至会有大量的请求被包装成事务，在向MySQL服务器发起事务处理请求时，而每条事务至少有一条SQL，最后很多条SQL，这样如果大家都访问同样的表数据，不加保护的情况下，就会出现问题。甚至可能因为事务由多条SQL构成，那么也会存在执行到一半出错或者不想在执行的情况，所以已经执行的应该这样做：
一个完整的事务，绝对不是简单的SQL集合，还要满足如下四个属性：
原子性：一个事务中的苏我又操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始 前的状态，就像这个事务从来没有执行过一样。
一致性：在事务开始之前和结束之后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
隔离性：数据库允许多个并发事务同时对数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）,读提交、可重复度（repeatable read）和串行化（Serializable）
持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
上面四个属性，可以简称为 ACID 。
原子性（Atomicity，或称不可分割性）
一致性（Consistency）
隔离性（Isolation，又称独立性）
持久性（Durability）。
为什么会出现事务
事务被MySQL编写者设计出来，本质是为了当应用程序访问数据库的时候，事务能够简化我们的编程模型，不需要我们去考虑各种各样的潜在错误和并发问题，当我们使用事务时，要么提交，要么回滚，我们不会再去考虑网络异常、服务器宕机了，同时更改一个数据。
所以事务本质上是为了应用层服务的，而不是伴随着数据库系统天生就有的。
我们后面把MySQL中的一行信息，称为一行记录。
事务的版本支持
在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务， MyISAM 不支持
我们来查看一下：查看命令如下
show engines \G
可以清楚地看到MyISAM是不支持事务的。
事务的提交方式
事务的提交方式常见的有两种：自动提交、手动提交
查看事务提交方式:
show variables like 'autocommit';
用 SET 来改变 MySQL 的自动提交模式:
-- 关闭自动提交
set autocommit=0;
-- 打开自动提交
set autocommit=1;
mysql就是服务端进程，本质是网络服务，底层采用tcp协议，默认端口是3306：
对于端口号，可以把mysql的端口号改一下，不要特别常见的端口号，可以前往/etc/my.cnf文件中进行修改。