1. Innodb引擎和Myisam引擎区别
- Innodb支持事务，具有ACID（原子性、一致性、隔离性、持久性）特性，而Myisam不支持事务。
- Innodb使用行级锁，Myisam使用表级锁。
- Innodb支持外键，Myisam不支持外键。
2.Checkpoint
1、Checkpoint机制的核心职责是将内存中的脏页（即那些已被修改但尚未写入磁盘的数据页）刷新到磁盘上，并确保在Checkpoint点之前的所有数据更改都已安全持久化。这样设计的好处是，即使在Checkpoint点之后系统发生崩溃，也只有该点之后的更改可能会丢失，从而显著减少了数据库恢复时所需处理的数据量。
- Fuzzy checkpoint：这种类型的Checkpoint会进行部分脏页的刷新，有助于有效循环利用Redo日志空间，减少对系统性能的影响。
-
Sharp checkpoint：通常发生在数据库关闭时，此时会将所有脏页刷回磁盘，以确保数据的完整性。
2、Checkpoint的触发时机多种多样，具体包括： - 重做日志空间不足时触发。
- 缓冲池中的脏页数量达到设定的阈值（由
innodb_max_dirty_pages_pct参数控制）时触发。 - 缓冲池空间不足，需要为新的数据页腾出空间时触发。
- 由周期性的线程定时触发，这些线程负责清理和刷新脏页（与
innodb_page_cleaners参数相关）。 - 数据库执行关机操作时触发。
3、可以通过执行SHOW ENGINE INNODB STATUS\G命令来查看当前Checkpoint的LSN号，这是衡量数据库恢复进度的重要指标。
4、innodb_fast_shutdown参数设置为0时，表示在InnoDB存储引擎关闭时，需要进行全面的清理工作。这包括： - purge all：清除不再需要的undo日志页，以释放空间并减少恢复时的负担。
- merge insert buffer：将插入缓冲区中的更改合并到数据文件中，确保数据的完整性。
-
flush dirty pages：将所有脏页刷新到磁盘上，以确保数据的持久化。
这是最慢的一种关闭方式，因为它需要执行大量的磁盘I/O操作。然而，这种关闭方式在数据库重新启动时能够提供最快的恢复速度，因为所有的数据都已经是最新的，无需进行额外的恢复工作。
3.事务隔离级别
隔离级别的实现通常是通过加锁方式实现的，不同的隔离级别对应不同的锁策略和可见性规则。
MVCC（多版本并发控制）机制是通过undo日志和read view来实现的，它允许事务在读取数据时访问数据的旧版本，从而提高了并发性能并减少了锁的需求。
- RU (读未提交)**：事务可以读取尚未提交的数据，这可能导致脏读、不可重复读和幻读。
- RC (读已提交)**：事务只能读取已提交的数据，从而避免了脏读。不能避免幻读和不可重复读。RC模式下也存在MVCC机制，只不过每次读取都会生成新的read view。
- RR (可重复性读)**：在此级别下，同一事务中的多次读取将看到相同的数据行，从而避免了脏读和不可重复读（这是通过MVCC机制实现的）。通过间隙锁机制避免大部分场景的幻读。
- SERIALIZABLE (串行化执行)**：这是最高的隔离级别，通过强制事务串行执行来防止脏读、不可重复读和幻读。它确保了事务的完全隔离，但可能降低并发性能。
- 幻读：指的是同一个查询在不同的时间产生不同的结果集时，出现幻象问题。这通常是由于其他事务插入了新的行或删除了行导致的。
-
不可重复性读：指的是在同一事务内两次查询同一个数据集合时，可能得到不同的结果。这通常是由于其他事务更新了这些数据导致的。
您描述的“crash recovery”（崩溃恢复）过程大体上是正确的，但可以进行一些细化和补充，以确保涵盖所有关键步骤和考虑因素。以下是一个更详细的版本：
4. Crash Recovery（崩溃恢复）
-
一致性恢复
- 获取数据库最新的checkpoint点，从checkpoint点之后开始，顺序扫描redo log，应用已经提交的redo log到数据页上，以恢复崩溃前的数据库状态。
-
事务重做/回滚
- 使用redo log中的事务ID（xid）来获取对应的binlog记录并判断事务记录的完整性。如果事务记录完整（即包含了所有必要的操作和xid），则进行事务重做，将事务中的操作应用到数据库上。如果事务记录不完整，则利用undo log（回滚日志）进行回滚。undo log记录了事务执行前的数据状态，可以用于将数据恢复到事务开始之前的状态。
5. DML具体流程
- 语法语义解析，权限验证
- 生成执行计划树
- 读取所需要数据页到内存中
- 在数据页修改之前生成对应的undo log
- 数据页修改并生成具体的redo log，binlog
- 事务在存储引擎层提交
- 返回客户端commit ok
- 将脏页定期刷新到磁盘上，到达数据的一致性
6. 二阶段提交
Prepare阶段：事务修改首先生成redo log，随后被标记为prepare状态。接着，事务的修改也会被记录到binlog中。
Commit阶段：在存储引擎层，事务被提交，并且redo log的记录被标记为commit状态。
7.组提交技术
目的：合并多个事务的redo log/binlog刷盘动作，以减少磁盘顺序写的次数。
背景：
-
未开启binlog时：
- Redo log的刷盘操作是影响MySQL TPS的瓶颈。
- 为缓解此问题，MySQL采用组提交技术，将多个刷盘操作合并为一个。
-
开启binlog时：
- 为保证Redo log和binlog的数据一致性，MySQL使用二阶段提交，并引入binlog的组提交技术，分为flush、sync、commit三个阶段。
- 每个阶段设有队列，先进先出，且每个队列由锁保护。
- 队列中的第一个事务成为leader，负责整队的操作，并在完成后通知其他事务。
阶段描述：
-
Flush阶段：
- 获取队列中的事务组。
- 将redo log中prepare阶段的数据刷盘。
- 将binlog数据写入文件系统缓存。
-
Sync阶段：
- 将binlog数据从文件系统缓冲刷入磁盘，以确保事务的持久性。
- 为提高刷盘收益，MySQL使用
binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count两个参数控制事务组的获取时机。
-
Commit阶段：
- 获取队列中的事务组。
- 依次将redo log中已经prepare的事务在引擎层提交。
8. UUID作为主键的影响
UUID是无序的，因此，当使用UUID作为主键时，新插入的数据有很大的可能性会被插入到已有数据的中间位置。这种情况会导致索引树频繁地进行重新平衡和节点分裂操作。这些操作不仅会引起数据页的频繁分裂和合并，从而产生额外的I/O消耗，而且还可能增加磁盘碎片，影响数据库的整体性能。
9. B+树的优势
B+树具有以下显著优势：
- 高效的范围查找和排序操作：B+树的所有叶子节点通过指针相互连接，形成了一个有序链表。这种结构使得范围查询、顺序扫描以及排序操作都可以在这个有序链表上高效地进行，从而大大提高了这些操作的效率。
- 减少磁盘I/O操作：B+树的高度相对较低，因此在查找数据时所需的I/O操作次数也相应减少。此外，B+树的每个节点都可以包含多个子节点，这使得在树的相同层级下能够容纳更多的数据。这种设计不仅提高了查询效率，还使得B+树在数据库和文件系统中得到了广泛应用，特别是在需要进行大量数据读取和查询的场景中。
