mysql面试题三（存储）

选择存储引擎时，应根据应用的实际需求，如数据一致性要求、并发读写特性、存储空间、查询性能、数据持久性、是否需要全文索引等，综合考虑各种存储引擎的特性，选择最适合的引擎。在MySQL 8.0及以后版本中，InnoDB已经成为默认且推荐的存储引擎，适用于大多数通用场景。其他存储引擎则在特定需求下提供补充或替代方案。

2.MyISAM 和 InnoDB 的区别

MyISAM和InnoDB是MySQL中两种常用的存储引擎，它们在数据存储方式、事务支持、锁定机制、性能特性等方面存在显著区别。以下是MyISAM与InnoDB的主要区别：

1. 事务支持

MyISAM：不支持事务，无法保证ACID（Atomicity, Consistency, Isolation, Durability）特性。一旦发生错误或异常中断，数据可能处于不一致状态。
InnoDB：支持完整的ACID事务，确保在并发环境下数据的一致性和完整性。适用于需要高可靠性和数据完整性的应用。

2. 锁定机制

MyISAM：采用表级锁定，无论是读操作还是写操作都会锁定整张表，同一时刻只能有一个写操作或多个读操作。在高并发写入或更新操作时，容易出现锁定竞争，导致性能下降。
InnoDB：支持行级锁定（包括Next-Key Locks），在同一时刻可以对不同的行进行并发读写，大大减少了锁定资源的竞争，提高了并发性能。在适当条件下，InnoDB还支持间隙锁定和意向锁，以处理并发插入和范围查询。

3. 数据存储与索引

MyISAM ：数据和索引分别存储在两个文件中（.MYD和.MYI），索引是非聚簇的，只包含索引键值和指向数据行的指针。
InnoDB：数据和聚簇索引（主键索引）存储在一起，形成一颗B+树，数据按照主键顺序存放。非聚簇索引（二级索引）同样为B+树结构，但叶子节点存储主键值而非数据行，查询时需要通过主键索引回表。

4. 数据恢复与崩溃安全性

MyISAM：不支持崩溃恢复，如果服务器意外停止或电源故障，可能导致数据损坏。需要定期进行表检查和修复。
InnoDB：具有自动崩溃恢复能力，通过重做日志（Redo Log）和回滚日志（Undo Log）确保在发生故障时数据的一致性和完整性。

5. 全文索引

MyISAM：原生支持全文索引，适用于需要进行全文搜索的场景。
InnoDB：在MySQL 5.6.4版本之后也支持全文索引，但在此之前需要使用其他解决方案（如Sphinx、Lucene等）。

6. 外键支持

MyISAM：不支持外键约束，无法自动保证数据引用完整性。
InnoDB：支持外键约束，可以设置外键关系，确保数据间的引用一致性。

7.主键支持

InnoDB 必须有唯一索引（如主键），如果没有指定，就会自动寻找或生产一个隐藏列 Row_id 来充当默认主键
Myisam 可以没有主键。

8. 性能与适用场景

MyISAM：读操作性能优秀，且内存占用较小，适合读密集型、对数据一致性要求不高的场景，如网站内容展示、数据分析报表等。
InnoDB：在并发写入、事务处理、数据完整性方面表现优异，适用于需要事务支持、高并发、数据完整性保障的OLTP（在线事务处理）系统，如电子商务、金融交易、内容管理系统等。

总结来说，MyISAM和InnoDB各有优劣，适用于不同的应用场景。在MySQL 5.5.5版本之后，InnoDB已成为默认存储引擎，其优秀的事务支持、行级锁定和崩溃恢复能力使其成为大多数场景的首选。而MyISAM在特定的读密集型、不需要事务和外键的场景中仍有一定的应用价值。在选择存储引擎时，应根据实际业务需求、数据量、并发程度、数据一致性要求等因素综合考虑。

3.InnoDB 的四大特性

插入缓冲insert buffer)

每次数据写到文件中去的时候，都是要通过一个io流的，我们可以把相同数据页的数据放在一个缓冲池当中然后一起写入，减少了IO流的时间。

二次写(double write)

是一种旨在提高数据持久性和系统崩溃后数据恢复能力的重要特性。

工作原理

缓冲池与数据页：InnoDB使用缓冲池（Buffer Pool）来缓存从磁盘读取的数据页，以减少对磁盘的直接访问。当数据发生更改时，先在缓冲池中修改数据页，随后将这些脏页（含有未写入磁盘的更改）异步地刷回到磁盘。
Double Write Buffer：为了防止在将脏页写回磁盘的过程中发生系统崩溃导致数据损坏，InnoDB引入了"二次写"机制。它在系统启动时预留一块连续的磁盘空间（Double Write Buffer），大小通常为2MB。
双重写入：当脏页需要被刷新到磁盘时，InnoDB首先将脏页的内容复制到Double Write Buffer中，然后一次性将Double Write Buffer的内容写入磁盘。接着，再将脏页本身直接写入对应的表空间（Tablespace）位置。
崩溃恢复：如果在写入脏页到表空间的过程中发生系统崩溃，由于Double Write Buffer中的数据已经安全写入磁盘，所以在系统重启后，InnoDB可以通过Double Write Buffer中的数据来恢复尚未完全写入表空间的脏页，避免了部分写入的数据页成为"幽灵页"（Half-written Pages）或损坏页。

自适应哈希索引(ahi)

我们都知道mysql的索引是根据B+树进行查询的，B+树的数据都是放在了叶子节点上，而热点数据的查询占据我们数据库请求中的很大一部分，所以其实我们在热点数据上只需要做到一个哈希索引，直接找到那个数据所在的叶子节点，这样节省了每次查询都从第一个叶子节点开始查的时间。

预读(read ahead)

InnoDB引擎的预读（Read-Ahead）机制是一种用于优化磁盘I/O性能的技术，其目的是通过预测未来可能需要的数据并提前将其加载到缓冲池（Buffer Pool），减少实际查询时的磁盘访问次数，提高数据读取效率。InnoDB引擎支持两种预读策略：

1. 线性预读（Linear Read-Ahead）

线性预读主要针对连续读取数据的场景，如范围查询或全表扫描。当InnoDB检测到查询正在连续读取数据页时，它会预测接下来可能需要读取的数据页，并提前发起异步的磁盘I/O请求，将这些数据页预加载到缓冲池中。这样，当查询实际需要这些数据时，它们已经在内存中可用，无需等待磁盘I/O，从而提高查询性能。

2. 随机预读（Random Read-Ahead）

随机预读主要针对非连续访问模式，如基于二级索引的查询。当InnoDB检测到二级索引访问模式呈现出一定的局部性时（如短时间内多次访问同一索引页附近的数据页），它会尝试预加载这些相关数据页到缓冲池，以减少未来的随机磁盘I/O。然而，由于随机预读的效果受数据分布和查询模式影响较大，且可能导致预读效率低下，因此在某些MySQL版本（如MySQL 5.5）中，随机预读功能可能默认关闭或被弃用。

4.InnoDB 为何推荐使用自增主键

数据组织与存储效率：

聚集索引 ：InnoDB 使用聚集索引来组织数据。这意味着表中的数据行实际上按照主键值的顺序存储在磁盘上。主键作为聚集索引的键，其值决定了数据行在物理存储上的位置。如果主键是自增的，新插入的记录将被添加到索引的末尾，只需要很少的页分裂操作（或者不需要），这样可以保持数据存储的紧凑性，减少I/O操作，提高写入性能。

插入性能：

连续插入：自增主键保证了每次插入的新记录都会在现有数据的逻辑末尾添加，避免了为了维持索引有序而进行的频繁的索引结构调整。特别是在高并发插入场景下，使用自增主键可以显著降低页分裂和数据移动的概率，减少锁竞争，提升整体的插入速度。

缓存利用率：

预读与缓存友好：现代数据库系统通常利用预读机制来提高数据访问速度。自增主键产生的连续的物理存储地址有利于数据库预读算法准确预测下一次要访问的数据位置，从而更有效地利用缓存（如：InnoDB buffer pool）。相比之下，非自增或随机分布的主键可能导致频繁的随机I/O，降低缓存命中率。

事务与锁定：

降低锁定开销：早期版本的InnoDB在处理自增主键时使用表锁，但随着技术的发展，现在通常采用行级锁或更细粒度的锁策略（如innodb_autoinc_lock_mode参数控制）。自增主键插入一般仅需要锁定少量的资源，有利于并发插入操作，减少锁冲突。

查询与JOIN效率：

简单且高效：自增主键通常是整型，较小的数据类型占用空间少，比较快。在进行范围查询、排序或JOIN操作时，基于数值大小的比较比基于复杂字符串或UUID等类型的比较更为高效。

易于理解和管理：

业务无关：自增主键是一个纯粹的技术性标识符，与业务逻辑解耦，简化了数据模型设计。它不需要考虑业务规则变化可能带来的影响，也不会因为业务数据的变化而导致主键值的变更。

综上所述，InnoDB推荐使用自增主键主要是出于对数据存储效率、插入性能、缓存利用率、事务处理效率、查询性能以及易管理性的综合考量。当然，具体应用中是否必须使用自增主键还需根据实际业务需求来决定，比如存在天然唯一且不易变动的业务键作为主键时，也可以考虑使用。但在没有这类合适业务键的情况下，自增主键是一个很好的默认选择。

5.什么是 InnoDB 的页、区、段

InnoDB是MySQL中一种广泛使用的存储引擎，其内部数据存储结构采用了分页、分区、分段的方式进行组织。以下是InnoDB中页、区、段的概念及其作用：

1. 页（Page）

基本单位：页是InnoDB存储引擎管理数据的基本单位，也是磁盘与内存之间进行数据交换的最小单位。每个页的大小通常是固定的（默认为16KB），并且在整个表空间中保持一致。
内容：页中可以存储各种类型的数据，如表数据、索引数据、事务日志等。对于数据页，其内部结构包括页头（Page Header）、记录区（Record Section）、空闲空间（Free Space）、页目录（Page Directory）和页尾（Page Trailer）等多个部分。记录区存放着实际的数据行，而页目录用于快速定位页内的记录。

2. 区（Extent）

磁盘空间分配单元：区是InnoDB用来分配和管理磁盘空间的中级单位，由一组连续的页组成。默认情况下，每个区包含64个连续的页（即1MB）。使用区作为分配单位，可以减少磁盘空间管理的复杂性，提高空间分配和回收的效率。
减少碎片：通过预先分配一定数量的连续页组成区，InnoDB在插入新数据或扩展表空间时，可以减少因单个页的分配而导致的磁盘空间碎片。

3. 段（Segment）

逻辑数据组织：段是InnoDB对不同类型数据进行逻辑组织的高级单位，包括数据段、索引段、回滚段等。每个段由一个或多个区组成，用于存储特定类型的数据。
- 数据段：存储表数据（即数据页），对应于表的聚簇索引（Clustered Index）。
- 索引段：存储表的二级索引（Secondary Indexes）数据。
- 回滚段：存储事务回滚信息，用于事务的撤销（Rollback）操作。
空间管理：每个段都有自己的空间管理机制，负责为所属类型的页分配和回收区。当需要为数据或索引分配新的页时，相应的段会从表空间中申请一个新的区。

整体结构与作用

页、区、段共同构成了InnoDB的多层次存储结构，实现了对磁盘空间的有效管理、数据的高效组织以及事务的可靠支持。这种结构具有以下优点：

高效空间管理：通过页、区、段的层次划分，InnoDB能够以较高的粒度进行磁盘空间的分配与回收，减少碎片，提高空间利用率。
快速数据访问：页作为最小的I/O单位，便于数据的缓存与传输。区的连续性有助于进行顺序I/O，提升读写性能。段则将不同类型的数据逻辑分组，便于针对性地进行查询优化。
事务支持：回滚段的存在使得InnoDB能够实现事务的原子性和回滚能力，确保数据的一致性。

综上所述，InnoDB的页、区、段分别对应数据存储的基本单位、磁盘空间分配单元以及逻辑数据组织单元，它们共同构成了一个层次化的存储体系，旨在实现高效的空间管理、快速的数据访问以及对事务的可靠支持。

6.什么是 Buffer Pool

Buffer Pool 是 MySQL 数据库管理系统（DBMS）中 InnoDB 存储引擎的一个核心内存区域，其主要作用是作为数据缓存，以提高数据库操作的性能。具体来说，Buffer Pool 具有以下特点和功能：

内存缓存：

作用：Buffer Pool 作为数据库与磁盘之间的中间层，缓存了从磁盘读取的热数据（经常访问的数据页），包括表数据、索引数据和其他内部元数据。当客户端发起对数据库的读请求时，InnoDB 首先尝试在 Buffer Pool 中查找所需的数据页。如果数据已经缓存，可以直接从内存返回结果，避免了昂贵的磁盘 I/O 操作。同样，对于写操作，数据首先被修改在 Buffer Pool 中的缓存页，随后在适当的时间点（如通过checkpoint机制）将更改同步回磁盘。

空间管理：

大小：Buffer Pool 的大小可通过配置参数 innodb_buffer_pool_size 进行设定，通常建议将其设置为服务器可用物理内存的 60%~80%，以充分利用内存资源并平衡与其他系统组件的需求。
内部结构：Buffer Pool 分割成多个大小固定的页（默认为 16KB），这些页与磁盘上的 InnoDB 数据页一一对应。Buffer Pool 中还包含描述数据页状态和元数据的额外信息，以及管理缓存页的各种数据结构（如LRU列表、flush列表、free列表等）。

缓存替换策略：

LRU（Least Recently Used）算法：Buffer Pool 使用 LRU 或其变种算法来管理缓存页的替换。当缓存满载时，最近最少使用的数据页会被替换以腾出空间给新的数据页。现代版本的 InnoDB 实现了改进的 LRU 算法，如"LRU+Clock"或"Adaptive Hash Index"，以更好地适应实际工作负载并减少缓存污染。

数据一致性与恢复：

事务支持：Buffer Pool 支持事务处理，缓存的数据页可能处于不同的事务状态。通过维护 undo 日志和 redo 日志，Buffer Pool 能够确保事务的原子性和持久性。
崩溃恢复：在数据库重启时，Buffer Pool 会利用 redo 日志来重新构建缓存中的数据页，恢复到崩溃前已提交事务的状态，保证数据一致性。同时，未提交的事务会被回滚。

缓存预热与监控：

预热：在数据库启动或某些维护操作后，可以主动对 Buffer Pool 进行预热，即预先加载预期会被频繁访问的数据页到缓存中，以缩短服务恢复到正常性能所需的时间。
监控：MySQL 提供了多种工具和命令（如 SHOW ENGINE INNODB STATUS、Performance Schema等）来监视 Buffer Pool 的使用情况，包括缓存命中率、数据页数量、LRU列表状态等，帮助 DBA 评估和调整缓存性能。

综上所述，MySQL 中的 Buffer Pool 是一个关键的性能优化组件，通过在内存中缓存数据页，极大地减少了对磁盘 I/O 的依赖，加速了数据库的读写操作，并通过有效的缓存管理策略和事务支持机制，确保了数据的一致性和系统的稳定性。合理配置和监控 Buffer Pool 对于优化 MySQL 性能至关重要。

7.什么是 Change Buffer

Change Buffer 是 InnoDB 存储引擎中的一项优化技术，专门针对非唯一二级索引（non-unique secondary indexes）的更新操作。它的主要目的是减少对非驻留（不在 Buffer Pool 中）索引页的随机磁盘 I/O，从而提升数据库性能。以下是 Change Buffer 的核心特性和工作原理：

作用与目标

延迟写入：当对非唯一二级索引进行 INSERT、UPDATE 或 DELETE 操作时，如果对应的索引页当前不在 Buffer Pool 中，Change Buffer 不会立即触发磁盘 I/O 将该页读入内存进行修改，而是将这些更改操作暂时缓存起来。
合并写入：这些缓存的更改会在后续某个时刻，当相应的索引页由于读取操作被自然地加载到 Buffer Pool 中时，与原索引页数据进行合并（merge），一次性完成所有待处理的更改。这种合并过程通常发生在页的第一次读取或者定期的 checkpoint 过程中。

适用场景

非唯一二级索引：Change Buffer 主要适用于非唯一二级索引，因为这类索引的插入顺序相对随机，更新操作引起的页分裂和数据移动较为频繁。而对于主键索引（聚集索引）或唯一二级索引，由于它们的唯一性约束，更新时通常需要立即定位到具体的索引页，无法通过 Change Buffer 延迟处理。

内存管理

位于 Buffer Pool 内 ：Change Buffer 是 Buffer Pool 中的一部分，其大小由配置参数 innodb_change_buffer_max_size 控制，通常以 Buffer Pool 总容量的百分比形式指定。这意味着 Change Buffer 占用的内存是有限的，且与主数据缓存共享内存资源。
数据结构：Change Buffer 使用特定的数据结构（如哈希表或B树）来存储待合并的更改记录，以便快速查找和合并对应的索引页。

合并过程

读取触发：当一个先前未在 Buffer Pool 中的非唯一二级索引页因查询需要被加载时，InnoDB 会检查 Change Buffer 是否有关于该页的待处理更改。如果有，则执行合并操作，将更改应用到内存中的索引页，并更新相应的数据结构。
checkpoint 引发：在 checkpoint 过程中，InnoDB 会将尚未合并的 Change Buffer 更改强制写入磁盘，确保数据的一致性和持久性。这通常发生在系统关闭、检查点间隔达到阈值或日志文件切换时。

性能影响

写密集型负载：在写操作远多于读操作，且非唯一二级索引更新频繁的场景下，Change Buffer 能显著减少不必要的磁盘 I/O，提高写入性能。
读密集型负载：然而，在读操作主导或数据分布均匀导致索引页频繁被读入内存的情况下，Change Buffer 的效果可能不明显，甚至可能增加合并成本，降低读取性能。因此，对于读取密集型工作负载或已知索引更新不频繁的情况，可能需要调整 Change Buffer 的大小或禁用该功能。

总结来说，MySQL 中的 Change Buffer 是 InnoDB 存储引擎用于优化非唯一二级索引更新的一种机制，通过延迟对非驻留索引页的写入操作，将多个分散的更改合并成一个批量操作，从而减少随机磁盘 I/O，提升数据库性能。然而，其效果取决于实际的工作负载特征，需根据应用场景适当调整配置和策略。

8.InnoDB 架构设计

InnoDB 存储引擎是 MySQL 数据库中广泛使用的事务型存储引擎，以其高并发、高可用和高可靠性著称。其架构设计旨在提供高效的事务处理、数据存储与检索能力，同时确保数据的一致性和完整性。以下是 InnoDB 架构设计的关键组成部分及其功能：

1. 内存结构（In-Memory Structures）

Buffer Pool

核心缓存：作为数据和索引的主要缓存区域，存储最近访问过的页，减少磁盘 I/O。
LRU 管理：采用 LRU（Least Recently Used）算法或其变种管理缓存页的替换。
预读与缓存友好：支持预读策略，优化数据预取，提高缓存命中率。

Change Buffer

索引更新优化：针对非唯一二级索引的更新操作进行延迟写入，减少随机磁盘 I/O。

Adaptive Hash Index

索引加速：自动为经常访问的索引构建哈希索引，加快查找速度。

Log Buffer

事务日志缓存：临时存储尚未写入磁盘的事务日志（redo log），减少直接磁盘写入次数。

2. 后台线程（Background Threads）

Master Thread

核心调度：负责调度和协调各种后台任务，如刷新脏页、合并 Change Buffer、检查点处理等。
I/O 操作：管理数据文件和日志文件的异步写入。

IO Thread

异步 I/O：处理与磁盘相关的读写请求，提高 I/O 并发能力。

Purge Thread

事务清理：负责清理已提交事务的 undo 信息，回收空间。

Page Cleaner Thread

脏页清理：专注于将脏页从 Buffer Pool 刷新到磁盘，减轻 Master Thread 负担。

3. 磁盘文件（Disk Files）

数据文件

表空间（Tablespaces）：包含 .ibd 文件，用于存储表数据和索引。
系统表空间（System Tablespace, ibdata1）：存放系统数据、全局临时表、未分区表等。

日志文件

Redo Log (重做日志)：记录对数据的物理修改，用于崩溃恢复和保证事务的持久性。
Undo Log (回滚日志)：存储事务的旧版本数据，支持事务回滚、MVCC（多版本并发控制）及一致性读。

4. 逻辑存储结构

聚集索引（Clustered Index）

数据组织：表数据按照主键顺序物理存储，主键同时也是数据行的存放位置。
辅助索引（Secondary Indexes）：非聚集索引指向主键值，而非直接指向数据行。

段（Segments）

数据段（Data Segments）：存储表数据。
索引段（Index Segments）：存储索引数据。
其他系统段：用于特殊用途，如回滚段等。

页（Pages）

基本存储单元：大小固定（默认 16KB），包含数据行、索引条目、页头信息等。

区（Extents）

连续页的集合：通常包含多个连续的页（如 64 个），便于空间分配和管理。

5. 事务与并发控制

事务支持

ACID：遵循 ACID（Atomicity, Consistency, Isolation, Durability）原则。
MVCC：通过多版本并发控制实现高并发下的读写隔离。

锁机制

行级锁：默认情况下对行进行加锁，支持高并发读写。
表级锁：在某些特定场景下使用，如全表扫描、DDL 操作等。

6. 其他特性

崩溃恢复

利用 redo log：在系统重启时，通过重放 redo log 恢复到崩溃前状态。

复制与备份

支持 binlog：用于复制和备份，记录数据更改的逻辑日志。

监控与诊断

内部统计信息：收集并暴露内部状态，用于性能分析和故障排查。

InnoDB 存储引擎的架构设计集成了内存管理、后台处理、磁盘存储、并发控制、事务管理等多种机制，旨在提供一个高效、稳定、可靠的数据库存储解决方案，满足现代数据库应用对数据一致性和高并发访问的需求。通过对各部分的精细调优和有效管理，InnoDB 能够在多种工作负载下展现出卓越的性能表现。