MySQL（下）

1、事务与存储引擎的关系？

事务是由 MySQL 的引擎来实现的，我们常见的 InnoDB 引擎它是支持事务的。

不过并不是所有的引擎都能支持事务，比如 MySQL 原生的 MyISAM 引擎就不支持事务，也正是这样，所以大多数 MySQL 的引擎都是用 InnoDB。

2、InnoDB和MyISAM的区别？

InnoDB支持事务，支持外键约束，支持行级锁（因此在进行读写操作时，只会锁定需要的行。这提高了并发性，允许多个事务同时处理不同的行。）；MyISAM不支持事务，不支持外键约束，支持表级锁（因此在进行读写操作时，会锁定整个表。这意味着在高并发的情况下，可能会导致性能瓶颈）。

原理上的区别和联系：

MyISAM 和 InnoDB 两种引擎所使用的索引的数据结构是什么？

MyISAM 和 InnoDB 两种引擎所使用的索引的数据结构都是B+树，但是区别在于：

• MyISAM 中 B+ 树的数据结构存储的内容是实际数据的地址值，它的索引和实际数据是分开的，只不过使用索引指向了实际数据。这种索引的模式被称为非聚集索引。

• InnoDB 中 B+ 树的数据结构中存储的都是实际的数据，这种索引有被称为聚集索引。

3、事务的特性是什么？详细说一下。

事务的特性是ACID，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。例如，A向B转账500元，这个操作要么都成功，要么都失败，体现了原子性。转账过程中数据要保持一致，A扣除了500元，B必须增加500元。隔离性体现在A向B转账时，不受其他事务干扰。持久性体现在事务提交后，数据要被持久化存储。

4、事务特性的实现方式？

（1）持久性是通过 redo log （重做日志）来保证的； （2）原子性是通过 undo log（回滚日志） 来保证的； （3）隔离性是通过 MVCC（多版本并发控制） 或锁机制来保证的； （4）一致性则是通过持久性+原子性+隔离性来保证。

5、并发事务会引起什么问题？

并发事务可能导致脏读、不可重复读和幻读。脏读是指：一个事务读到了另一个事务未提交的“脏数据”；不可重复读是指：在一个事务内多次读取同一数据，出现前后两次读取到的数据不一样的现象；幻读是指：在一个事务内多次查询某个符合查询条件的「记录数量」，出现前后两次查询到的记录数量不一样的情况。

6、如何解决并发事务带来的问题？事务的隔离级别有哪些？MySQL默认的隔离级别是哪个？

并发事务可能导致脏读、不可重复读和幻读，可以通过事务隔离来解决上述问题。事物的隔离级别分为：未提交读，读已提交，可重复读，串行化。其中未提交读指的是一个事务还没提交时，它做的变更就能被其他事务看到，读已提交指的是一个事务提交之后，它做的变更才能被其他事务看到；可重复读指的是一个事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的；串行化指的是会对记录加上读写锁，在多个事务对这条记录进行读写操作时，如果发生了读写冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。未提交读解决不了所有问题；读已提交解决了脏读，不能解决幻读，可重复读；可重复读解决了脏读和可重复读，不能解决幻读；串行化解决了所有问题但是性能较低。MySQL默认的隔离级别上可重复读。

7、MySQL主从同步目的，原理，实现方式？常见的主从架构模式？

• 主从同步的目的：数据备份、读写分离、高可用性。

数据备份，将主服务器的数据复制到从服务器，实现数据备份；

读写分离，缓解主服务器负载压力；

高可用性体现在，如果主服务器发生故障，可以将从服务器提升为主服务器，从而保证数据库的高可用性。

• 原理：

MySQL主从复制的核心是二进制日志（Binlog）。步骤如下：

1. 主库在事务提交时记录数据变更到Binlog。

2. 从库读取主库的Binlog并写入中继日志（Relay Log）。

3. 从库重做中继日志中的事件，反映到自己的数据中。

• 实现方式：

实现方式	定义	优缺点
基于语句的复制	主服务器将所有数据变更语句（例如INSERT、UPDATE、DELETE等）复制到从服务器，从服务器再执行这些语句来实现数据同步	优点：实现简单；缺点：会导致更新时间与原库不一致。 比如 update_time=now()
基于行的复制	主服务器将数据变更记录的二进制日志以行的形式复制到从服务器，从服务器再应用这些变更来实现数据同步。	优点：好处是可以正确的复制每一行，一些语句可以被更加有效的复制；缺点：数据量较大，开销比较大，会给主库增加额外的负载。
混合模式	以上两种模式的混合使用，一般的复制使用 STATEMENT 模式保存 binlog，对于 STATEMENT 模式无法复制的操作使用 ROW 模式保存 binlog，MySQL 会根据执行的 SQL 语句选择日志保存方式。	Statement和Row的混合模式，默认采用Statement模式，涉及日期、函数相关的时候采用Row模式，既减少了数据量，又保证了数据一致性。

MySQL8.0 默认使用基于行复制的方式，理论上基于行的复制模式在整体上更优，且在实际应用中适用于大多数场景,当然也可以使用参数 binlog_format 手动指定复制的模式。

• 常见的主从架构：

7.1 一主一从 一主一从模式是最简单的主从架构模式，它由一个主节点和一个从节点组成。主节点负责处理所有写操作，并将其变更同步到从节点。从节点负责处理所有读操作，并从主节点获取最新数据。

优点:

结构简单，易于理解和实现。 成本低，只需两台服务器即可。 性能提升，读操作可以分流到从节点。 缺点:

可用性较低，如果主节点故障，则整个系统不可用。 -扩展性较差，只能通过增加主节点的性能来提升读写能力。 适用场景: 对读写性能要求不高，对可用性要求较高的场景，例如小型网站、数据库等。

7.2 一主多从 一主多从模式由一个主节点和多个从节点组成。主节点负责处理所有写操作，并将其变更同步到所有从节点。从节点负责处理所有读操作，并从主节点获取最新数据。

优点:

性能提升，读操作可以分流到多个从节点。 可用性提升，如果主节点故障，可以将其中一个从节点提升为主节点。 扩展性较好，可以通过添加从节点来提升读能力。 缺点:

成本较高，需要多台服务器来部署从节点。 数据一致性问题，当主节点发生故障时，从节点的数据可能不一致。 适用场景: 对读写性能要求较高，对可用性要求较高的场景，例如大型网站、数据库等。

7.3 双M 双M模式由两个主节点和多个从节点组成。两个主节点之间相互同步数据，并各自负责一部分写操作。从节点从两个主节点获取最新数据，并负责处理所有读操作。

优点:

可用性更高，即使一个主节点故障，另一个主节点也可以继续提供服务。 数据一致性更好，两个主节点之间相互同步数据，可以保证数据一致性。 缺点:

成本较高，需要多台服务器来部署主节点和从节点。 复杂度较高，需要维护两个主节点之间的同步。 适用场景: 对读写性能要求较高，对可用性和数据一致性要求较高的场景，例如金融系统、电商系统等。

7.4 联级复制 联级复制模式是一种特殊的一主多从模式，它将从节点组织成一个链条，每个从节点只与相邻的两个节点同步数据。

优点:

节省带宽，每个从节点只需要与相邻的两个节点同步数据。 提高扩展性，可以很容易地添加新的从节点。 缺点:

数据一致性问题，如果某个从节点故障，可能会导致数据不一致。 复杂度较高，需要维护从节点之间的同步链条。 适用场景: 对读写性能要求不高，对扩展性要求较高的场景，例如大型分布式系统等。

7.5 多主一从 多主一从模式由多个主节点和一个从节点组成。每个主节点都负责处理一部分写操作，并将其变更同步到从节点。从节点负责处理所有读操作，并从所有主节点获取最新数据。

优点:

读性能高，可以并行从多个主节点读取数据。 扩展性好，可以很容易地添加新的主节点。 缺点:

数据一致性问题，当主节点之间存在冲突时，从节点的数据可能不一致。 复杂度较高，需要维护主节点之间的数据一致性。 适用场景: 对读性能要求较高，对数据一致性要求不严格的场景，例如数据分析系统、报表系统等。

• 主从同步延迟问题：

主从同步最常遇到的问题就是主从同步延迟，可以通过在从库上执行show slave status命令查看延迟时间，Seconds_Behind_Master表示延迟的秒数。

主从同步延迟的原因有哪些？

1. 从库机器性能较差 主库负责所有读写请求，从库只用来备份，会用性能较差的机器，执行时间自然较慢。

2. 从库压力更大 读写分离后，主库负责写请求，从库负责读请求。 互联网应用一般读请求更多，所以从库读压力更大，占用更多CPU资源。

3. 网络延迟 当主库的Bin Log文件往从库上发送时，可能产生网络延迟，也会导致从库数据跟不上。

4. 主库有大事务 当主库上有个大事务需要执行5分钟，把Bin Log文件发送到从库，从库至少也需要执行5分钟，所以这时候从库就出现了5分钟的延迟。

主从同步延迟的解决方案？

1. 从库机器性能较差 把从库换成跟主库同等规格的机器。

2. 从库压力更大 多搞几台从库，分担读请求压力。

3. 网络延迟 联系运维或者云服务提供商解决。

4. 主库有大事务 把大事务分割成小事务执行，大事务不但会产生从库延迟，还可能产生死锁，降低数据库并发性能，所以尽量少用大事务。

• 如何提升主从同步性能？解决方案。

1、从库开启多线程复制；

就是在主从同步的最后两步使用多线程，修改配置 slave_parallel_workers=4，代表开启4个复制线程。

2、修改同步模式，改为异步；

**主从同步共有三种复制方式：**
​
1. 全同步复制
   当主库执行完一个事务，并且所有从库都执行完该事务后，才给客户端返回成功。
2. 半同步复制
   至少有一个从库执行完成后，就给客户端返回成功。
3. 异步复制
   主库执行完后，立即返回成功，不关心从库是否执行完成。
    
如果对数据安全性要求没那么高，可以把同步模式改成半同步复制或者异步复制。

3、修改从库Bin Log配置

**修改sync_binlog配置：**
​
> sync_binlog=0 ，表示写binlog不立即刷新磁盘，由系统决定什么时候刷新磁盘。
> sync_binlog=1，每次写binlog都刷新磁盘，安全性高，性能差。
> sync_binlog=N，写N次binlog才刷新磁盘。
​
从库对数据安全性要求没那么高，可以设置sync_binlog=0。
​
**修改innodb_flush_log_at_trx_commit配置：**
​
> innodb_flush_log_at_trx_commit=0，每隔一秒钟，把事务日志刷新到磁盘。
> innodb_flush_log_at_trx_commit=1，每次事务都刷新到磁盘。
> innodb_flush_log_at_trx_commit=2，每次事务都不主动刷新磁盘，由系统决定什么时候刷新磁盘。
​
从库对数据安全性要求没那么高，可以设置innodb_flush_log_at_trx_commit=2。

原文地址：https://blog.csdn.net/m0_46479109/article/details/143480766

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！