mysql 常见知识点总结

1、mysql 双1

2、组提交

3、半同步增强半同步

---

 

1、mysql 双1

innodb_flush_log_at_trx_commit：0, 1, 2

sync_binlog：0,1, N

0：binlog 不刷盘，依赖于操作系统的刷盘机制，在断电或者是操做系统崩溃的情况下，这些事务将全部丢失
1：这是最安全的方式，binlog 在 binlog 组提交的 sync 阶段都进行刷盘操作，在断电或操作系统崩溃的情况下，二进制日志中丢失的事务仅处于准备状态，在恢复的时候直接回滚掉
N：binlog 将在 N 次 sync 队列形成后进行 sync 刷盘

1： 当innodb_flush_log_at_trx_commit=1时，InnoDB将在每次事务提交时将log buffer的数据更新到文件系统os buffer中，并调用文件系统的flush操作将数据缓存更新至磁盘中。此种方式下，数据库完全遵守ACID特性，安全性较高
2：当innodb_flush_log_at_trx_commit=2时，InnoDB将在每次事务提交时将log buffer中的数据更新到文件系统缓存中，每秒钟将文件系统缓存中的数据更新到磁盘一次，该操作由操作系统调度。因为DDL变更或其他InnoDB内部原因会导致更新磁盘的操作独立于innodb_flush_log_at_trx_commit参数设置，不能完全保证每秒更新磁盘一次，没有被更新到磁盘中的事务可能会因宕机而丢失
0：当innodb_flush_log_at_trx_commit=0时，InnoDB会每秒钟将log buffer中的数据更新到磁盘中。因为DDL变更或其他InnoDB内部原因会导致更新磁盘的操作独立于innodb_flush_log_at_trx_commit参数设置，并不能完全保证每秒将数据更新到磁盘一次。因此，在实例崩溃恢复场景中，可能会出现丢失1秒钟的事务

---

2、组提交：

mysql组提交原理：

在MySQL中，组提交（Group Commit）是一种优化技术，它旨在减少数据库事务日志的写入次数，从而提高数据库的性能和吞吐量。组提交通常与二进制日志（binary log）和事务日志（redo log）相关联，尤其是在使用InnoDB存储引擎时更为常见。下面详细介绍组提交的工作原理及其对性能的影响

组提交的工作原理

事务执行：

当事务在数据库中执行时，它会生成一个或多个日志记录（例如，InnoDB的redo log）。

等待点：

在事务提交之前，它会等待其他事务完成其日志写入操作。这是通过一个全局的等待点来实现的，例如，在MySQL中，这通常是通过一个锁或者一个信号量机制来实现的。

组形成：

当第一个事务完成其日志写入后，它会“广播”一个信号，通知其他等待的事务可以继续执行它们的日志写入。这些等待的事务会立即开始写入它们自己的日志，形成一个“组”。

组提交：

一旦所有事务都完成了它们的日志写入，它们会再次聚集到一起，共同执行最终的磁盘写入操作。这意味着所有的日志写入操作会在磁盘上作为一个单独的、原子性的操作完成，而不是每个事务单独进行。

性能优化：

通过将多个事务的日志写入合并为一次磁盘写入操作，组提交显著减少了I/O操作的次数，从而提高了整体的性能和吞吐量。

配置和使用组提交

在MySQL中，可以通过调整innodb_flush_log_at_trx_commit参数来控制事务日志的写入策略，进而影响组提交的行为：

innodb_flush_log_at_trx_commit = 1（默认值）：每个事务提交时立即将日志写入磁盘。这通常会导致最少的延迟，但可能不是最高效的I/O模式。

innodb_flush_log_at_trx_commit = 2：每个事务提交时将日志写入日志缓冲区，每秒写入磁盘一次。这种方式提供了较好的性能和吞吐量，但可能会有轻微的延迟。

innodb_flush_log_at_trx_commit = 0：每个事务提交时将日志写入日志缓冲区，但不立即刷新到磁盘。这提供了最高的吞吐量，但可能会在系统崩溃时丢失最近的提交的事务。

注意事项

在使用innodb_flush_log_at_trx_commit = 0时，建议设置innodb_flush_log_at_timeout来控制日志缓冲区的刷新频率。

组提交的实现细节（如确切的同步点）可能会根据MySQL的版本和配置有所不同。确保查阅最新的官方文档以获取最准确的信息。

尽管组提交可以显著提高性能，但在某些情况下（如对数据一致性要求极高的场景），可能需要调整配置以确保数据的安全性和完整性。

 

通过合理配置和使用组提交，可以有效地提升MySQL数据库的性能和效率。

 

---

 

 

3、半同步增强半同步

‌半同步复制和增强半同步复制的主要区别在于数据同步的确认方式和数据一致性保障的不同。‌‌

半同步复制

半同步复制在MySQL5.5版本中引入，其基本原理是主库在事务提交后，等待从库接收并确认binlog后才返回响应给客户端。这种方式提高了数据的安全性，避免了异步复制中可能的数据丢失问题。然而，半同步复制也存在一些问题，例如幻读和数据不一致。具体来说：

 

‌幻读‌：在半同步复制中，当主库已经提交事务但从库尚未确认时，其他客户端可能读取到这条数据，导致幻读现象。

‌数据丢失‌：在网络波动或从库响应延迟的情况下，主库可能会在未收到从库确认的情况下继续处理其他事务，导致数据不一致。

增强半同步复制

为了解决半同步复制中的幻读和数据不一致问题，MySQL 5.7.2引入了增强半同步复制。其核心改进在于主库在事务提交前，必须等待从库确认接收并刷新到relay log后才进行提交。这样确保了即使主库崩溃，所有已提交的事务也能保证同步到从库的relay log中，从而避免了幻读和数据不一致的问题。具体来说：

 

‌数据一致性‌：增强半同步复制通过确保事务在从库完全接收并执行后才提交，大大提高了数据的一致性和完整性。

‌性能影响‌：由于每次事务都需要等待从库的确认，可能会对主库的性能产生一定影响，但这种影响在大多数情况下是可以接受的。

配置和使用场景

在实际应用中，增强半同步复制更适合对数据一致性要求较高的场景，如金融业务等。通过配置rpl_semi_sync_master_wait_point=after_sync可以启用增强半同步复制模式。这种模式通过牺牲一定的性能来换取更高的数据安全性和一致性。‌

 

 

 

 

 

 

 

 

 

半同步复制