1.数据库事务的基本特性。
原子性：
事务中的所有操作要么全部提交成功，要么全部失败回滚。
(资料图)
场景：UPDATE cs_user SET age = 18 , gender = "女" WHERE id = 4。要么全部更新要么更新失败，不会出现age更新成功，gender更新失败。
一致性：
据库总是从给一个一致性的状态转换到另一个一致性的状态。
场景：比如规定某个表的字段age大于等于12小于18时，字段type为青少年，而数据库中存在age=16的时候，type="儿童"。
隔离性：
一个事务所做的修改在提交之前对其它事务是不可见的。两个以上的事务不会出现交错执行的状态.因为这样可能会导致数据不一致。
持久性：
一旦事务提交，其所做的修改便会永久保存在数据库中。
事务在并发环境下出现的问题。
脏读（Dirty Read）：一个事务读取了另一个事务未提交的数据。如果另一个事务回滚，则读取的数据将是无效的。
不可重复读（Non-repeatable Read）：同一事务内，两次读取同一数据得到的结果不同。这是因为在两次读取之间，另一个事务修改了该数据。
幻读（Phantom Read）：同一事务内，两次查询得到的结果集不同。这是因为在两次查询之间，另一个事务插入或删除了一些数据。
丢失修改（Lost Update）：两个或多个事务同时修改同一数据，其中一个事务的修改被另一个事务覆盖，导致修改丢失。
不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表。
对于这些问题的解决方法一般是有：事务隔离级别，乐观锁和悲观锁，MVCC（多版本并发控制）。
事务隔离级别
数据库提供了多种事务隔离级别，不同的隔离级别提供了不同的并发控制机制，以解决并发问题。
以下是数据库的每一个事务隔离级别的详细介绍：
READ UNCOMMITTED（读未提交）：该隔离级别允许事务读取其他事务未提交的数据，可能会出现脏读、不可重复读和幻读的问题。
READ COMMITTED（读已提交）：该隔离级别只允许事务读取其他事务已提交的数据，可以避免脏读问题，但不可避免不可重复读和幻读的问题。
REPEATABLE READ（可重复读）：该隔离级别保证在同一事务中多次读取同一数据得到的结果是一致的，可以避免脏读和不可重复读的问题，但无法避免幻读。
SERIALIZABLE（串行化）：该隔离级别保证事务串行执行，避免了以上所有并发问题，但会影响并发性能。
READ UNCOMMITTED（读未提交）
在READ UNCOMMITTED级别下，事务可以读取未提交的数据，没有对数据进行加锁或版本控制。当一个事务读取数据时，即使另一个事务正在修改该数据，也不会阻塞读取操作。这种实现方式可以提高读取性能，但会导致脏读的问题。
优点：
读取性能高：由于不需要加锁或版本控制，因此读取性能较高。
无锁操作：该隔离级别不需要对数据进行加锁操作，因此可以避免锁的竞争问题。
缺点：
脏读问题：在READ UNCOMMITTED级别下，事务可以读取其他事务未提交的数据，因此可能会读取到无效数据，导致脏读的问题。
不可重复读问题：由于其他事务可以修改数据，因此同一事务内两次读取同一数据得到的结果可能不同。
幻读问题：由于其他事务可以插入或删除数据，因此同一事务内两次查询得到的结果集可能不同。可能导致数据不一致：由于读取的数据可能是未提交的数据，因此可能会导致数据不一致的问题。
对于这个隔离级别，几乎无法解决任何对于数据库并发环境下数据不一致的错误，但在一些对数据一致性要求不高，但读取性能要求较高的系统中，可以考虑使用该隔离级别。
READ COMMITTED（读已提交）
在READ COMMITTED级别下，事务只能读取已提交的数据，需要对数据进行加锁或版本控制。当一个事务读取数据时，如果另一个事务正在修改该数据，则需要等待该事务提交后才能读取。这种实现方式可以避免脏读的问题，但可能会无法避免不可重复读和幻读的问题。
优点：
避免脏读问题：由于只允许读取已提交的数据，因此可以避免脏读的问题。
数据一致性较高：由于只读取已提交的数据，因此数据一致性较高。
缺点：
不可重复读问题：由于其他事务可以修改数据，因此同一事务内两次读取同一数据得到的结果可能不同。
幻读问题：由于其他事务可以插入或删除数据，因此同一事务内两次查询得到的结果集可能不同。
锁的竞争问题：由于需要对数据进行加锁，因此可能会导致锁的竞争问题。
这个隔离级别解决了一部分并发问题，但是还有一部分问题没有解决，适合应用于对数据一致性要求较高的系统。如果需要更高的隔离级别，可以考虑使用REPEATABLE READ或SERIALIZABLE级别。
REPEATABLE READ（可重复读）
在InnoDB中是这样的：RR隔离级别保证对读取到的记录加锁 (记录锁)，同时保证对读取的范围加锁，新的满足查询条件的记录不能够插入 (间隙锁)，因此不存在幻读现象。但是标准的RR只能保证在同一事务中多次读取同样记录的结果是一致的，而无法解决幻读问题。InnoDB的幻读解决是依靠MVCC的实现机制做到的。Mysql默认的隔离级别是RR。
优点：
避免脏读和不可重复读问题：由于需要对数据进行版本控制，因此可以避免脏读和不可重复读的问题。
数据一致性较高：由于保证了同一事务内多次读取同一数据得到的结果一致，因此数据一致性较高。
缺点：
锁的竞争问题：由于需要对数据进行版本控制，因此可能会导致锁的竞争问题。
版本控制开销：由于需要对数据进行版本控制，因此可能会增加数据库的存储和计算开销。
幻读解决
InnoDB的幻读解决是依靠MVCC的实现机制： （增加系统版本号，每次事务操作，会比较系统版本号） InnoDB为每行记录添加了一个版本号（系统版本号），每当修改数据时，版本号加一。在读取事务开始时，系统会给事务一个当前版本号，事务会读取版本号<=当前版本号的数据，这时就算另一个事务插入一个数据，并立马提交，新插入这条数据的版本号会比读取事务的版本号高，因此读取事务读的数据还是不会变。例如：此时books表中有5条数据，版本号为1 事务A，系统版本号2：select * from books；因为1<=2所以此时会读取5条数据。 事务B，系统版本号3：insert into books ...，插入一条数据，新插入的数据版本号为3，而其他的数据的版本号仍然是2，插入完成之后commit，事务结束。 事务A，系统版本号2：再次select * from books；只能读取<=2的数据，事务B新插入的那条数据版本号为3，因此读不出来，解决了幻读的问题，而且两个事务同时修改同一数据，则会生成两个不同的版本，从而避免数据丢失的问题，解决了丢失修改问题。
mysql锁
在mysql中使用的锁一般是两种类型，乐观锁和悲观锁。
乐观锁概念
是由我们自己实现的一个版本控制。在表中的数据进行操作时(更新)，先给数据表加一个版本(version)字段，每操作一次，将那条记录的版本号加1。也就是先查询出那条记录，获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查询出来时的version的值相等，如果相等，则说明这段期间，没有其他程序对其进行操作，则可以执行更新，将version字段的值加1；如果更新时发现此刻的version值与刚刚获取出来的version的值不相等，则说明这段期间已经有其他程序对其进行操作了，则不进行更新操作
悲观锁概念
这个由数据库实现，对于悲观锁在操作数据时，认为此操作会出现数据冲突，所以在进行每次操作时都要通过获取锁才能进行对相同数据的操作。在悲观锁中又有两种类型，分别是共享锁与排它锁。
共享锁（读锁）
对于共享锁来说，他的作用是在一个事务对数据A加上共享锁后，其他的事务只能在对数据A加共享锁，无法加其他锁，只有全部共享锁释放后才能加其他锁（基本上就是排它锁）。这句话的意思其实就是，有一个事务正在读数据A,那么其他事务也只能读数据A,而无法修改数据A,只有在所有事务对数据A的访问都完成后，才能进行修改。
排它锁（写锁）
对于排它锁来说，作用是在一个事务对数据A加上排它锁后，只有这个事务可以对数据进行读取和修改，其他的事务都无法对这个数据进行读取和修改，当然也无法对这个数据加锁。
使用方式：在需要执行的语句后面加上for update就可以了
行锁和表锁
对于悲观锁来说
有行锁和表锁两种区别，
行锁是给某一行加上锁，也就是一条记录加上锁。
行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁（这也是为什么sql语句尽量保证走索引原因之一）
表锁：没有使用索引的情况是锁定全表的。
死锁
死锁（Deadlock） 所谓死锁：是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。
到此这篇关于浅谈一下mysql数据库底层原理的文章就介绍到这了,更多相关mysql数据库底层原理内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
