MySQL学习笔记（一）

1、mysql是什么？

MySQL是一个关系型数据库管理系统，由瑞典MySQL AB公司开发，目前属于Oracle旗下产品。MySQL是最流行的关系型数据库管理系统之一，MySQL所使用的SQL语言是用于访问数据库的最常用标准化语言。MySQL软件采用了双授权政策，分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择MySQL作为网站数据库。

与其它的数据库相比，MySQL具有以下优势：

1. MySQL是开源的，所以你不需要支付额外的费用。
2. MySQL支持大型的数据库。可以处理拥有上千万条记录的大型数据库。
3. MySQL使用标准的SQL数据语言形式。
4. MySQL服务器工作在客户端/服务器或嵌入系统中。
5. 有大量MySQL的开源工具，可以方便的对MySQL进行分析、设计和管理。

此外，MySQL还提供了一套独特的功能，如全文索引、跨平台支持、复制功能、强大的查询功能、数据类型支持等，使其成为众多数据库管理系统的优秀代表之一。

2、mysql默认存在的数据库有什么作用？

MySQL安装完成后，会默认创建一些系统库，这些库对于MySQL的运行和管理至关重要。以下是MySQL自带的一些默认库及其作用：

1. information_schema：这是一个信息数据库，保存了关于MySQL服务器所维护的所有其他数据库的信息。比如，数据库名、数据库的表、表的数据类型、访问权限等。当建立一个新的数据库或者在已有的数据库中增删改表时，这些信息都会记录在information_schema库中。
2. mysql：这是MySQL的核心数据库，主要存储了数据库用户、权限等信息。例如，用户账号、库级别权限、表级权限、列级别权限、存储过程与函数权限等都存储在这个库中。此外，一些系统级别的操作，如慢日志或通用日志（如果配置为表形式），也会存储在此库中。
3. performance_schema：这个库用于收集数据库服务器的性能数据，如SQL的执行次数、耗时、锁等信息。这些数据有助于DBA或开发者分析数据库的性能瓶颈。
4. sys：sys库是一个集合了performance_schema和information_schema中关于性能的视图，主要目的是方便DBA和开发者能够更加便捷地了解数据库的运行情况。这个库中的所有数据都来自performance_schema，并以更易读的方式展现出来。

这些默认库为MySQL的正常运行、管理和优化提供了基础支持。在使用MySQL时，了解这些库的作用和其中的表结构是非常有帮助的。

3、 MySQL中的DML、DDL、DQL、DCL和TCL简介

MySQL中的DML、DDL、DQL、DCL和TCL是SQL（结构化查询语言）的不同子集，用于执行特定的数据库操作。以下是这些类别的介绍及简单举例：

1. DML (数据操作语言)

* **作用**：用于操作数据库中的数据，如插入、更新、删除等。
* **主要语句**：INSERT、UPDATE、DELETE。
* **举例**：
	+ INSERT INTO students (id, name, age) VALUES (1, 'Alice', 20);
	+ UPDATE students SET age = 21 WHERE name = 'Alice';
	+ DELETE FROM students WHERE id = 1;

2. DDL (数据定义语言)

* **作用**：用于定义或修改数据库结构，如表、索引等。
* **主要语句**：CREATE、ALTER、DROP、TRUNCATE。
* **举例**：
	+ CREATE TABLE students (id INT PRIMARY KEY, name VARCHAR(50), age INT);
	+ ALTER TABLE students ADD COLUMN email VARCHAR(100);
	+ DROP TABLE students;
	+ TRUNCATE TABLE students; (注意：此操作会删除表中的所有数据，但保留表结构)

3. DQL (数据查询语言)

* **作用**：用于查询数据库中的数据。
* **主要语句**：SELECT。
* **举例**：
	+ SELECT * FROM students WHERE age > 18;
	+ SELECT name, age FROM students ORDER BY age DESC;

4. DCL (数据控制语言)

* **作用**：用于控制数据库的访问权限。
* **主要语句**：GRANT、REVOKE。
* **举例**：
	+ GRANT SELECT, INSERT ON database_name.table_name TO 'username'@'hostname';
	+ REVOKE INSERT ON database_name.table_name FROM 'username'@'hostname';

5. TCL (事务控制语言)

* **作用**：用于管理数据库事务，确保数据的完整性和一致性。
* **主要语句**：COMMIT、ROLLBACK、SAVEPOINT、SET TRANSACTION。
* **举例**：
	+ START TRANSACTION; (开始一个新事务)
	+ UPDATE students SET age = 22 WHERE name = 'Alice';
	+ COMMIT; (提交事务，使更改生效)
	+ 或者在发现问题时使用 ROLLBACK; (回滚事务，撤销未提交的更改)

这些SQL子集在数据库管理中起着至关重要的作用，使得开发者能够有效地定义、查询、修改和控制数据。

4、关系型数据库和非关系型数据库对比

关系型数据库（RDBMS）和非关系型数据库（NoSQL）在多个方面存在显著的差异。以下是对这两类数据库的主要对比：

1. 数据结构：

* **关系型数据库**：基于严格的表结构，数据存储在表和行中，表之间通过关系（如主键和外键）相互连接。具有固定的架构，要求事先定义数据的类型和关系。
* **非关系型数据库**：数据结构灵活，可以是键值对、文档、宽列存储或图形结构。不需要预定义架构，允许存储不同类型和结构的数据。

2. 扩展性：

* **关系型数据库**：通常通过增加更强大的服务器来提高性能，即垂直扩展。但在处理大量并发读写和海量数据时可能面临性能瓶颈。
* **非关系型数据库**：设计为易于水平扩展，即通过添加更多服务器来增加处理能力和存储容量。适合处理大量并发读写和海量数据。

3. 事务性：

* **关系型数据库**：提供强大的事务支持，确保数据的完整性和一致性。支持ACID（原子性、一致性、隔离性、持久性）属性。
* **非关系型数据库**：事务支持因类型而异。一些NoSQL数据库（如MongoDB）提供一定程度的事务支持，但通常不如关系型数据库强大。其他NoSQL数据库可能完全不支持事务。

4. 查询语言：

* **关系型数据库**：使用结构化查询语言（SQL）进行查询和操作。SQL是一种功能强大且通用的查询语言。
* **非关系型数据库**：查询语言因数据库类型而异。例如，键值存储可能使用简单的get和put操作，而文档存储可能使用类似SQL的查询语言（如MongoDB的MQL）。图形数据库使用图形查询语言（如Cypher或Gremlin）。

5. 一致性模型：

* **关系型数据库**：通常遵循强一致性模型，确保所有用户在同一时间点看到相同的数据。
* **非关系型数据库**：一致性模型因数据库类型和配置而异。一些NoSQL数据库可能提供最终一致性或弱一致性，这意味着在不同时间点或不同节点上查询的数据可能略有不同。这种一致性模型有助于提高性能和可扩展性，但可能增加数据处理的复杂性。

6. 应用场景：

* **关系型数据库**：适用于需要高度结构化数据和强大事务支持的应用，如金融系统、订单处理系统等。
* **非关系型数据库**：适用于需要高扩展性、灵活数据结构和快速响应的应用，如社交网络、实时分析、物联网等。

在选择使用关系型数据库还是非关系型数据库时，需要根据具体的应用需求、数据量、并发访问量以及数据一致性要求等因素进行综合考虑。

5、mysql关闭阻塞线程

在MySQL中，当一个线程正在执行某个操作时，可能会因为各种原因（如锁等待、资源争用等）而被阻塞。要关闭阻塞的线程，你可以首先尝试找出哪些线程正在阻塞，并理解为什么它们被阻塞。然后，你可以决定是否要杀死这些线程以解除阻塞。

以下是一些步骤和命令，可以帮助你处理阻塞的线程：

1. 查看当前的进程列表:

使用SHOW PROCESSLIST;命令可以查看当前MySQL服务器上的所有活动线程。

SHOW FULL PROCESSLIST;

FULL`关键字确保你可以看到完整的查询。

2. 找出阻塞的线程:

在SHOW PROCESSLIST的输出中，查找State列显示为“Waiting for lock”或其他表示阻塞状态的线程。同时，注意Time列，它显示线程已经运行了多长时间。长时间运行的线程可能是问题的原因。

3. 杀死阻塞的线程:

一旦你确定了要杀死的线程ID，可以使用KILL命令来结束它。

KILL thread_id;

其中thread_id是你在上一步中找到的线程ID。

6、MYSQL解析器、预处理、优化器、执行器

MySQL是一个复杂的关系型数据库管理系统，其查询处理过程涉及多个组件和步骤。当我们讨论查询的处理时，通常提到的四个主要组件是解析器（Parser）、预处理器（Preprocessor）、优化器（Optimizer）和执行器（Executor）。这些组件协同工作，将SQL查询转换为可执行的计划，并从数据库中检索或修改数据。

1. 解析器 (Parser)

* **作用**：解析器负责接收SQL查询并将其转换为抽象语法树（AST）。AST是查询的内部表示形式，它描述了查询的结构和语义。
* **过程**：解析器首先检查SQL查询的语法是否正确。如果查询包含语法错误，解析器将返回一个错误消息。如果语法正确，解析器将继续生成AST。

2. 预处理器 (Preprocessor)

* **作用**：预处理器对解析器生成的AST进行进一步处理。它解决名称解析和权限检查等问题。
* **过程**：在名称解析阶段，预处理器确定查询中引用的表、列和其他数据库对象的实际标识符。它还检查执行查询的用户是否具有必要的权限。

3. 优化器 (Optimizer)

* **作用**：优化器的任务是确定执行查询的最有效方法。对于给定的AST，可能存在多种可能的执行计划，优化器的目标是选择成本最低的计划。
* **过程**：优化器考虑多种因素，如表的存储引擎、索引、连接类型、排序方法等，来评估不同执行计划的成本。它使用统计信息和成本模型来做出决策。最终，优化器生成一个执行计划，该计划描述了如何检索或修改数据。

4. 执行器 (Executor)

* **作用**：执行器负责执行优化器生成的执行计划。它与存储引擎交互，检索或修改实际的数据。
* **过程**：执行器按照执行计划的指示，调用存储引擎的API来执行查询的各个部分。这可能涉及读取表数据、使用索引、执行连接操作、排序结果等。执行器还负责处理事务和并发控制等方面的问题。

这些组件和步骤共同确保了MySQL能够高效地处理SQL查询并返回正确的结果。通过优化查询和数据库设计，可以进一步提高查询的性能和效率。

7、mysql存储引擎简介

MySQL的存储引擎是数据库底层软件组件，数据库管理系统使用它来创建、查询、更新和删除数据。MySQL支持多种存储引擎，每种存储引擎都有其特定的优势和用途。以下是一些常见的MySQL存储引擎：

1. InnoDB：这是MySQL的默认存储引擎，从MySQL 5.5版本开始被设为默认。它支持事务安全（ACID兼容）和具有提交、回滚和崩溃恢复能力的事务。InnoDB支持外键完整性约束，且对数据行进行锁定以提高并发性。它还具有多版本并发控制（MVCC）功能，以支持高并发。InnoDB表的最大大小可以达到64TB。
2. MyISAM：这是早期版本的MySQL中的默认存储引擎。MyISAM提供了较高的插入和查询速度，但不支持事务。它使用表级锁定，因此在并发更新时性能可能会受到影响。MyISAM表对应三个文件：一个.frm表结构文件，一个MYD表数据文件，和一个.MYI索引文件。MyISAM表的大小限制取决于操作系统，但从MySQL 5.0开始，默认限制是256TB。
3. Memory：Memory存储引擎将所有数据存储在内存中，因此查询速度非常快。但是，如果MySQL服务器崩溃或重启，所有数据都会丢失。它主要用于创建临时表或存储不需要持久化的数据。

8、InnoDB数据存储概述

InnoDB是MySQL的默认存储引擎，以其事务支持、行级锁定和外键约束而闻名。InnoDB的数据存储方式涉及表空间的概念，表空间是InnoDB用来存储表数据和索引的逻辑结构。以下是关于InnoDB表空间的概述。

8.1 表空间

InnoDB表空间分为几种类型，每种类型都有其特定的用途和配置方式。

8.1.1 独立表空间

独立表空间（File-Per-Table Tablespace）是InnoDB的一个特性，允许每个表有自己的表空间文件。当启用innodb_file_per_table配置选项时，每个新创建的InnoDB表都会有一个独立的.ibd文件来存储其数据和索引。这种方式提供了更好的磁盘空间管理、备份和恢复灵活性。

8.1.2 系统表空间

系统表空间（System Tablespace）是InnoDB的默认表空间，通常包含在一个或多个名为ibdata1、ibdata2等的文件中。系统表空间存储了InnoDB的数据字典、回滚段、插入缓冲区和未分配的空间等信息。如果没有启用innodb_file_per_table，所有的表数据和索引也会存储在系统表空间中。

8.1.3 通用表空间

通用表空间（General Tablespace）是InnoDB为了支持多表空间而引入的一个特性。除了系统表空间和独立表空间外，InnoDB还允许创建额外的表空间，这些表空间可以包含多个表的数据和索引。通用表空间允许数据库管理员根据需要将表组织到不同的物理位置或磁盘上，以优化I/O性能。

8.1.4 临时表空间

临时表空间（Temporary Tablespace）用于存储InnoDB在执行查询时创建的临时表和临时索引。在MySQL 5.7及更高版本中，InnoDB引入了一个独立的临时表空间，以改善涉及大量临时数据的查询的性能。临时表空间可以配置为独立的磁盘文件或使用系统表空间的一部分。通过合理配置临时表空间，可以避免临时数据对系统性能的不必要影响。

了解和管理这些表空间对于优化InnoDB存储引擎的性能、磁盘空间使用以及备份和恢复策略至关重要。数据库管理员应该根据工作负载和存储需求来选择合适的表空间配置。

8.2 表空间的数据存储

InnoDB表空间的数据存储结构是层次化的，从大到小依次为：表空间（Tablespace）、段（Segment）、区（Extent）、页（Page）和行（Row）。以下是对这些存储单位的简要概述。

8.2.1 段（Segment）

在InnoDB中，段是表空间中的一个逻辑存储单位，用于存储表的数据或索引。每个InnoDB表至少有两个段：一个用于存储表数据，另一个用于存储主键索引。非主键索引也会有自己的段。段是由一系列连续的区组成的。

8.2.2 区（Extent）

区是InnoDB存储引擎中管理磁盘空间的基本单位，它是连续的页集合。每个区包含相同数量的页，通常是64个页。当InnoDB需要为表或索引分配新的存储空间时，它会以区的形式进行分配。这种分配方式减少了磁盘I/O操作的次数，提高了性能。

8.2.3 页（Page）

页是InnoDB中磁盘和内存之间数据交换的基本单位。每个页的大小通常是16KB（这可以通过配置选项进行调整，但16KB是默认值）。页中存储了行数据、索引数据或系统信息。InnoDB使用页来优化磁盘I/O操作，因为读取或写入整个页比单独读取或写入行更有效。

8.2.4 行（Rows）

行是InnoDB表中的最小数据单位。每个行包含了表中的一行数据。InnoDB支持四种不同的行格式：Redundant、Compact、Dynamic和Compressed。这些行格式决定了行数据的存储方式和空间效率。选择合适的行格式可以优化存储空间的使用和查询性能。

• Redundant行格式：是InnoDB最早支持的行格式，现在已经较少使用，因为它在空间利用率上不如其他格式高效。
• Compact行格式：MySQL 5.0版本后，是InnoDB的默认行格式，它提供了较好的空间效率和性能。
• Dynamic行格式：类似于Compact格式，但优化了BLOB和TEXT类型字段的存储，允许这些字段只存储部分数据在基本记录中，其余数据存储在外部。MySQL 5.7版本后，是InnoDB的默认行格式。
• Compressed行格式：是一种压缩的行格式，它可以减少存储空间的使用，但可能会增加CPU的使用率，因为需要进行压缩和解压缩操作。

了解这些存储单位对于理解InnoDB的数据存储和检索机制非常重要，也有助于优化数据库的性能和存储空间使用。

9、InnoDB内存加载及管理机制

InnoDB的内存加载及管理机制涉及多个方面，包括缓冲池（Buffer Pool）、LRU算法、Change Buffer等。以下是这些方面的简要概述：

1. 缓冲池（Buffer Pool）：

* InnoDB将数据和索引缓存在内存中，以提高访问速度。缓冲池是InnoDB用于缓存这些数据和索引的主要内存区域。
* 缓冲池的大小可以通过`innodb_buffer_pool_size`配置参数进行设置。这个参数对InnoDB的性能有很大影响，因为它决定了InnoDB可以缓存多少数据和索引。
* 缓冲池内部由多个页（Page）组成，每个页的大小通常为16KB。这些页通过LRU（Least Recently Used）算法进行管理。

2. LRU算法：

* InnoDB使用LRU算法来管理缓冲池中的页。当缓冲池满了，并且需要加载新的页时，InnoDB会淘汰最近最少使用的页，以便为新的页腾出空间。
* 然而，传统的LRU算法在数据库环境中可能不是最优的，因为某些查询可能会扫描大量的数据，导致这些数据被加载到缓冲池中并淘汰其他有用的页。为了解决这个问题，InnoDB对LRU算法进行了优化，引入了midpoint的概念。midpoint将LRU链表分为两部分：new区和old区。新加载的页不是放在LRU链表的头部，而是放在new区的头部。当页被访问时，如果它位于old区，它会被移动到new区。这样，经常访问的页会留在new区，而很少访问的页会被逐渐淘汰到old区并最终从缓冲池中移除。
* InnoDB还提供了`innodb_old_blocks_time`参数，用于控制页在old区存活的时间。只有存活时间超过这个值的页才有机会被移动到new区。

3. Change Buffer：

* 当需要更新一个数据页时，如果数据页不在内存中，InnoDB不会立即将其加载到内存中。相反，它会将这些更改缓存在Change Buffer中，并在稍后的某个时间点将数据页加载到内存中并应用这些更改。这样可以减少磁盘I/O操作，提高更新操作的性能。
* Change Buffer主要适用于非唯一索引页的更改。对于唯一索引页的更改，InnoDB需要立即加载数据页来确保唯一性约束不被违反。

4. 预热缓冲池：

* MySQL服务启动一段时间后，InnoDB会将经常访问的数据置入InnoDB缓冲池中。为了提高业务繁忙高并发时的效率，MySQL支持在关闭服务时将内存中的热数据保存到硬盘，并在重启服务时将这些数据加载到缓冲池中。这可以通过设置`innodb_buffer_pool_load_at_startup`和`innodb_buffer_pool_load_now`参数来实现。然而，这些参数在默认情况下是关闭的，需要手动开启。

请注意，以上信息是基于MySQL的InnoDB存储引擎的一般行为。具体的实现细节可能会因MySQL的版本和配置而有所不同。因此，在实际应用中，建议参考相关版本的MySQL官方文档以获取准确的信息。

10、InnoDB RedoLog简介

InnoDB的redo log是MySQL中非常重要的一个组成部分，它用于实现事务的持久性，确保在系统崩溃或其他故障发生时，已经提交的事务的数据不会丢失，并能够恢复到一致的状态。

具体来说，redo log中记录了事务中修改的任何数据的新值，即数据的最新备份存储的位置。当事务发生时，相关的修改并不会立即写入到磁盘的数据文件中，而是先写入到redo log中。然后，在适当的时候，如系统空闲或事务提交时，这些修改才会被异步地刷新（flush）到磁盘的数据文件中。

redo log的写入是顺序的，这意味着它的写入性能非常高。此外，redo log的大小是固定的，并且是以循环的方式写入。当redo log写满时，它会自动回滚到开头并继续写入。这种设计使得redo log能够快速地处理大量的写入操作，而不会受到磁盘I/O性能的限制。

在MySQL中，InnoDB引擎会创建一组redo log文件，通常包括ib_logfile0、ib_logfile1等多个文件。这些文件的大小和数量可以根据系统的需要进行配置。一般来说，较大的redo log文件可以提供更好的性能，但也会占用更多的磁盘空间。

总的来说，InnoDB的redo log是MySQL中确保事务持久性和数据一致性的重要机制之一。它通过顺序写入和循环写入的方式，高效地处理大量的写入操作，从而提高了系统的性能和可靠性。

11、mysql EXPLAIN关键字作用及简单使用方法

EXPLAIN 是 MySQL 数据库管理系统中的一个非常有用的关键字，它用于获取关于如何执行 SELECT 语句的信息。当你对一个查询使用 EXPLAIN 时，MySQL 会返回一个表格，展示它如何使用索引来处理该查询，以及查询执行过程中各步骤的详细信息。这对于性能调优和排查问题非常有帮助。

使用方法

使用 EXPLAIN 很简单，只需在你的 SELECT 查询前加上 EXPLAIN 关键字。例如：

EXPLAIN SELECT * FROM users WHERE id = 1;

结果解读

EXPLAIN 返回的结果包含多列，每一列都提供了查询执行的不同方面的信息。下面是一些常见的列和它们的含义：

• id: 查询的标识符。
• select_type: 查询的类型（如 SIMPLE, PRIMARY, SUBQUERY, DERIVED 等）。
• table: 输出结果集的表的名称。
• type: 这是连接类型。常见的有 system、const、eq_ref、ref、range、index 和 ALL。
• possible_keys: 显示可能应用在这个表中的索引。注意这不意味着这些索引实际上被用到了，MySQL 会从中选择一个来使用。
• key: 实际使用的索引。如果为 NULL，则没有使用索引。
• key_len: 使用的索引的最长的键的长度。在不使用全部索引的情况下，这个值可以帮助你判断实际使用了索引的哪些部分。
• ref: 显示了索引的哪一列被用在了查找中。
• rows: 估计要检查的行数。
• Extra: 不适合在其他列中显示但十分重要的额外信息。

注意事项

• 当你看到 type 是 ALL 时，这通常意味着 MySQL 进行了全表扫描，这通常不是高效的。你可能需要考虑添加索引来优化查询。
• possible_keys 和 key 的差异可以帮助你了解 MySQL 的索引选择策略。
• Extra 列中的信息也非常重要，比如 “Using filesort” 或 “Using temporary” 可能意味着查询不够高效。

进阶使用

你还可以使用 EXPLAIN FORMAT=JSON 来获取更详细的查询执行计划信息，这些信息以 JSON 格式返回，包含了更多的细节和嵌套的结构。

例如：

EXPLAIN FORMAT=JSON SELECT * FROM users WHERE id = 1;

这将返回一个详细的 JSON 对象，你可以查看和分析查询的每一个步骤和细节。这对于复杂的查询和深入的性能调优非常有用。

12、mysql索引是什么及基本认识

MySQL索引是一种数据结构，用于帮助数据库系统更快地查找、检索数据。它类似于书籍的目录，可以让我们不必翻阅整本书就能找到所需的信息。在数据库中，索引可以显著提高查询性能，特别是在处理大量数据时。

1. 提高查询速度：索引可以大大减少数据库服务器需要扫描的数据量，从而加快查询速度。
2. 排序和分组操作更快：除了基本的查找操作外，索引还可以加速ORDER BY和GROUP BY等排序和分组操作。
3. 索引类型：MySQL支持多种类型的索引，如B-Tree索引、哈希索引、全文索引、空间索引（用于地理空间数据）等。其中，B-Tree索引是最常用的索引类型。
4. 主键索引：每个表只能有一个主键索引。主键索引是唯一索引的一种特殊类型，它要求索引列的值必须唯一，并且不能为NULL。
5. 唯一索引：除了主键索引外，表还可以有多个唯一索引。唯一索引也要求索引列的值必须唯一，但与主键索引不同的是，唯一索引列的值可以为NULL。
6. 复合索引：复合索引包含多个列，查询时只有查询条件使用了复合索引中的第一个列时，索引才会被使用。但是，在某些情况下，即使查询条件没有使用复合索引的第一个列，索引仍然可能被使用，这取决于查询优化器的决策。
7. 索引维护成本：虽然索引可以提高查询性能，但它们也需要额外的磁盘空间和维护成本。每当对表进行插入、删除或更新操作时，索引也需要相应地更新。因此，在创建索引时需要权衡查询性能和维护成本。
8. 索引并非总是最佳选择：并非所有情况下都需要使用索引。对于小表或查询条件能够覆盖表中大部分数据的情况，全表扫描可能比使用索引更快。此外，过于复杂的索引可能会导致查询优化器做出不理想的决策，从而降低查询性能。
9. 使用EXPLAIN分析查询：可以使用EXPLAIN关键字来分析查询的执行计划，查看MySQL如何使用索引来处理查询。这对于性能调优和排查问题非常有帮助。

总之，MySQL索引是一种用于提高查询性能的重要工具。然而，在使用索引时需要谨慎考虑其优缺点，并根据具体情况做出最佳选择。

13、mysql B+树索引简述

MySQL中的B+树索引是一种数据结构，用于在数据库中快速查找、访问数据。它是基于B+树（B-Plus Tree）这种自平衡的多路搜索树实现的。在MySQL中，InnoDB存储引擎使用B+树作为索引结构，这也是最常见的情况，尽管其他存储引擎可能使用不同的索引类型。

B+树索引的特点：

1. 多路平衡树：与二叉树不同，B+树的每个节点可以有多个子节点，这允许每个节点存储更多的键值对，从而减少树的高度和磁盘I/O次数。

2. 所有值都在叶子节点：B+树中的所有数据值都存储在叶子节点中，而内部节点（非叶子节点）仅用于存储键值和指向子节点的指针。

3. 叶子节点通过指针相连：B+树的叶子节点之间通过指针相互连接，形成一个有序的链表结构，这使得范围查询和顺序访问非常高效。

4. 自平衡：B+树在插入和删除数据时会自动调整以保持平衡，确保查询性能的稳定。

MySQL中B+树索引的实现：

1. 索引结构：在MySQL的InnoDB存储引擎中，B+树索引由索引条目组成，每个索引条目包含一个键值对和一个指向对应数据记录或下一个索引条目的指针。索引存储在磁盘上，通常按照磁盘块（页）进行组织。

2. 主键索引与非主键索引：InnoDB表有一个主键索引，称为聚簇索引。如果表没有显式定义主键，InnoDB会选择一个唯一非空索引代替，如果这样的索引也不存在，InnoDB会生成一个隐藏的聚簇索引。除了主键索引外，表还可以有多个非主键索引，也称为二级索引或辅助索引。非主键索引的叶子节点存储的是主键的值，而不是实际的数据记录，这被称为回表操作。

3. 查找操作：当执行查找操作时，MySQL从根节点开始遍历B+树，根据查询条件在树中进行查找。查找过程类似于二分查找，根据当前节点的键值信息决定向左子树还是右子树移动，直到找到目标叶子节点。在叶子节点中，可以通过顺序链表结构快速进行范围查询。

4. 插入操作：当插入新的数据记录时，MySQL首先找到应该插入的叶子节点位置。如果叶子节点已满，则需要进行分裂操作，将部分键值对移动到一个新创建的叶子节点中，并更新父节点的键值信息。这个分裂过程可能递归地向上进行，直到根节点。

5. 删除操作：当删除某个数据记录时，MySQL首先找到对应的叶子节点并删除该键值对。如果删除操作导致叶子节点的键值对数量过少（低于某个阈值），则需要进行合并操作，将相邻的叶子节点合并成一个节点，并更新父节点的键值信息。同样地，合并操作可能递归地向上进行。

通过B+树索引的实现，MySQL可以高效地支持数据的查找、插入和删除操作，提高数据访问的性能。同时，B+树索引还可以支持范围查询和顺序访问等高级功能，满足各种复杂的应用需求。在设计数据库时，合理地创建和使用索引是提高查询性能的关键。

14、b+树索引叶子结点存储的是什么？

在MySQL的InnoDB存储引擎中，B+树索引的叶子节点存储的内容取决于索引的类型。

主键索引（聚簇索引）

对于主键索引，也称为聚簇索引，叶子节点存储的是表的实际数据记录。换句话说，主键索引的叶子节点包含了整行数据。因此，当我们通过主键索引查询数据时，可以直接在叶子节点中找到所需的数据，无需进行额外的磁盘I/O操作。

非主键索引（二级索引、辅助索引）

对于非主键索引，叶子节点存储的是主键的值以及一个指向对应数据记录在主键索引中的位置的指针（通常是一个磁盘地址或页号+偏移量的组合）。因此，当我们通过非主键索引查询数据时，首先需要在非主键索引的叶子节点中找到主键的值，然后再根据这个主键值去主键索引中查找实际的数据记录。这个过程被称为“回表”。

需要注意的是，由于非主键索引的叶子节点存储的是主键的值而不是实际的数据记录，所以非主键索引通常会比主键索引占用更多的磁盘空间。但是，通过合理地设计和使用非主键索引，我们可以大大提高查询性能，特别是在处理复杂查询和大数据量时。

另外，无论是主键索引还是非主键索引，B+树的叶子节点都是通过指针相互连接的，形成一个有序的链表结构。这使得范围查询和顺序访问非常高效，因为我们可以直接通过指针在叶子节点之间进行遍历，无需进行额外的磁盘I/O操作。

15、索引下推是什么？

索引下推（Index Condition Pushdown，简称ICP）是一种数据库优化技术，用更通俗的话来解释就是：数据库在查询时，会尽量利用索引来加速数据的检索速度。通常，数据库会先通过索引找到可能符合条件的记录，然后再根据查询条件进一步筛选这些记录。

在没有使用索引下推的情况下，数据库可能会先通过索引找到很多可能符合条件的记录，然后再逐条检查这些记录是否真正满足查询条件。这个过程中，数据库可能会做很多不必要的工作，因为它可能会检索并处理很多最终并不需要的数据。

而索引下推技术可以让数据库在检索索引的同时，就根据查询条件进行筛选。这样，数据库就可以跳过那些明显不符合条件的索引项，从而减少不必要的数据检索和处理工作。这就像是在图书馆里找书，如果你知道你要找的书在某个特定的书架上，你就可以直接走到那个书架前去找，而不是先把所有可能的书都拿下来，再一本一本地检查。

索引下推其实主要就是在联合索引中发挥作用，可以使用到所有的查询筛选条件（前提该条件是联合索引使用的字段）。什么是索引下推

16、索引是不是越多越好呢？

索引不是越多越好需要在适合的场景去建立索引，并且尽量使用联合索引如果无限制的添加索引，那么会占用很大的内存空间，所以索引是有 大小限制的 innoDB对限制的定义官网： 我们发现一个表最多1017列，二级索引（非聚簇索引）最多只能64个。 一个索引会对应一个索引树，数据变更是需要对树进行维护的，那么索引树越多，需要维护的树也就越多，操作数据也会越来越慢，这也是树的特性，可以提升数据检索性能，但是，会降低数据操作效率。 所以，索引不是越多越好，因为会占用内存空间，并且影响数据操作效 率。所以创建的索引一定是在业务中有用到，并且尽量使用联合索引

17、组合索引a,b,c 查询条件c=10 and a = 1 and b >= 30，是否用到索引？

联合索引abc，在索引树是先根据a排序，a相同的根据b排，b相同的再根据c排。

首先，最左匹配原则：a where条件中存在，满足，所以肯定能走到索引树，但是不确定是否所有条件都会走。

继续最左，bb在条件中也存在，所以b也能走到索引。

但是b是个范围查询，范围查询后，c就是无序的。

所以，C必须扫描b> =30的所有数据，c是不能走索引扫描的

18、为什么一般建议主键单调递增呢？

首先，我们知道我们每个表都会去有一个主键索引树，是根据主键进行排序的B+树，树的特性是会加快查询速度，但是在添加数据的时候，是要去维护这个树的，如果是递增的，我们只需要往树上添加节点，那么假如如果不是趋势递增的，那么我们会引发树的分裂与合并。然后索引树中的叶子节点的page里的数据也是排序好的，也会导致页的分裂与合并。

主键单调递增的建议主要基于以下几个原因：

1. 插入性能优化：在关系型数据库中，数据通常是按照主键的顺序存储在磁盘上的。当主键是单调递增时，新插入的数据会被追加到存储的末尾，这减少了磁盘I/O操作，因为不需要在磁盘中间位置寻找空闲空间或者移动已有的数据行。这种追加写入的方式比随机插入要快得多，尤其是对于高并发的插入操作。

2. 避免页分裂：在B+树索引结构中，如果主键不是单调递增的，频繁的插入操作可能会导致页分裂（page split），即当一个数据页满了并且需要为新数据腾出空间时，该页会被分裂成两个页，并且可能需要重新组织索引结构。页分裂是一个昂贵的操作，因为它涉及到数据的移动和索引的更新。单调递增的主键可以显著减少页分裂的频率。

3. 简化索引维护：当主键单调递增时，索引的维护变得相对简单，因为新插入的索引键总是比现有的键要大，所以它们总是被添加到索引的末尾。这减少了索引维护的复杂性，提高了写操作的性能。

4. 便于数据复制和备份：单调递增的主键可以使得数据在逻辑上是有序的，这有助于数据的复制、备份和恢复操作。有序的数据更容易进行增量备份和差异比较。

5. 查询优化：虽然主键的单调递增性对于非范围查询的性能影响较小，但在某些情况下，有序的数据可能使得范围查询、排序和分页等操作更加高效。

然而，也需要注意的是，在某些使用场景中，单调递增的主键可能不是最佳选择。例如，在高并发的分布式系统中，如果多个节点同时插入数据并且都使用单调递增的主键，可能会导致主键冲突。此外，如果主键的生成过于依赖时间戳或序列，可能会泄露系统的信息或容易受到预测攻击。因此，在选择主键生成策略时需要综合考虑系统的需求和安全性。

19、做InnoDB表结构设计的时候，一些大字段，比如 varchar(5000)，会独立成附表，为什么？

在设计InnoDB表结构时，将大字段（如VARCHAR(5000)）独立成附表的做法通常基于以下几个考虑：

1. 存储效率：InnoDB的存储引擎是基于聚簇索引的，这意味着表中的数据是按照主键的顺序存储的。如果表中包含大字段，尤其是可变长度的字段（如VARCHAR），那么这些字段可能会占用大量的空间，并且由于它们的大小不一，可能导致页（InnoDB的存储单位）的填充效率降低，从而产生更多的碎片和浪费的空间。
2. I/O性能：当查询或更新包含大字段的记录时，整个记录（包括大字段）都可能被加载到内存中。如果大字段不是经常需要访问的，那么将它们与主表分离可以减少不必要的I/O操作，提高查询性能。
3. 索引效率：如果在大字段上建立索引，那么索引本身可能会变得非常大，这不仅会占用更多的存储空间，还会降低索引的搜索效率。将大字段移至附表，并仅在必要时建立索引，可以优化索引的使用和大小。
4. 灵活性：将大字段放在附表中可以为主表提供更多的设计灵活性。例如，可以更容易地更改大字段的数据类型或大小，而无需对整个表进行重构。
5. 数据完整性：在某些情况下，大字段可能包含可选的数据或仅在特定情况下需要的数据。将它们与主表分离可以更好地控制数据的完整性和一致性。
6. 备份和恢复：如果大字段包含大量数据，将它们与主表分离可以简化备份和恢复过程。例如，可以选择只备份主表或只备份附表，从而减少备份的大小和所需的时间。

20、InnoDB中索引结构为啥选用B+树的结构？

InnoDB 存储引擎使用 B+ 树作为其索引结构的主要原因是 B+ 树在数据库环境中提供了高效的查询性能、插入性能和空间利用率。以下是 B+ 树在 InnoDB 中被选用的几个关键原因：

1. 多路搜索：与二叉搜索树相比，B+ 树是一种多路搜索树，这意味着每个节点可以拥有多个子节点。这使得 B+ 树在相同高度的情况下能够存储更多的键值对，从而减少了访问磁盘的次数，提高了查询效率。

2. 磁盘友好：由于磁盘 I/O 操作的开销远远大于内存操作，因此减少磁盘访问次数是数据库性能优化的关键。B+ 树的设计考虑了磁盘块（或称为页）的大小，使得每个节点的大小与磁盘块大小相匹配，从而最大限度地减少了读取一个节点所需的磁盘 I/O 操作次数。

3. 范围查询效率：B+ 树的所有叶子节点都位于同一层，并且按照键值顺序链接在一起。这种结构使得范围查询非常高效，因为一旦找到范围的起始点，就可以沿着叶子节点链表顺序访问范围内的所有键值对。

4. 插入和删除效率：由于 B+ 树是一种平衡树，插入和删除操作不会导致树的高度发生剧烈变化。这保证了查询性能的稳定性，即使在大量数据插入或删除后也是如此。

5. 空间利用率：B+ 树通过分裂和合并节点来维护树的平衡。当节点过满时，它会被分裂成两个节点；当节点过空时，它可能与相邻节点合并。这种动态调整保证了空间的高效利用。

6. 适合磁盘和内存：B+ 树的设计既考虑了磁盘存储的特点（如块读写、顺序访问快等），也适合内存中的数据结构和算法。这使得 B+ 树成为数据库索引的理想选择。

综上所述，B+ 树在数据库索引中的应用是基于其高效的查询性能、插入性能、空间利用率以及对磁盘和内存的适应性。这些特点使得 B+ 树成为 InnoDB 存储引擎索引结构的首选。

21、count()使用优化

推荐使用count(1) 或者count(*) ，差别不会太大。1 是扫描到数据扫描到了就固定返回一个1，肯定不为null，不会做null判断。 *是整条数据，也进行了优化，因为整条数据肯定不会为null。所以也不需 要去判断 然后，count(id）,主键id，肯定不为null，也不会去判断null,但是相对于 count(1)来讲，要去解析ID.稍微慢点，但是也可以忽略不计。

count(字段)，这个就有影响了，如果字段没有索引，就需要进行全表扫描，explain是all；如果字段支持非空则每条数据都要进行非空判断。

总结：count(1) ≈ count(*) > count(id) > count(字段) 字段是否有索引，是否是可为null，也会影响性能

22、limit使用优化

看下来优化基本都是基于索引的，如果业务中需要动态排序，这些优化方案并没有什么很明显的用处。

-- 无优化例句
SELECT * FROM product_new ORDER BY id LIMIT 300000,10 
-- 优化方案1 
/*
如果id是趋势递增的，那么每次查询都可以返回这次查询最大的ID，然后
下次查询，加上大于 上次最大id的条件，这样会通过主键索引去扫描，并
且扫描数量会少很多很多。因为只需要扫描where条件的数据
*/
SELECT * FROM product_new WHERE id > 300396 ORDER BY id LIMIT 10 
-- 优化方案2 
/*
先limit出来主键ID，然后用主表跟查询出来的ID进行inner join 内连接，
这样，也能一定上提速，因为减少了回表，查询ID只需要走聚集索引就
行。
*/
SELECT * FROM product_new INNER JOIN
(
SELECT id FROM product_new ORDER BY id LIMIT 300000,10
) a
ON product_new.id=a.id

23、order by使用优化

核心思想：尽可能让排序发生在索引树上

如果让orderby的字段走索引，那么排序流程直接可以在索引树完成，如果排序的字段不走索引，整个排序流程必须先把数据放到内存，在内存实现排序。这个内存的大小由sort_buffer_size配置,如果内存不够保存这个数据，那么就会启用磁盘的临时文件来进行排序。

SHOW variables LIKE '%max_length_for_sort_data%';
SHOW variables LIKE 'sort_buffer_size';

在内存排序也分为2种方式：

1.全字段排序模式

​ 需要查询的字段在max_length_for_sort_data放得下， 就拿出所有字段放到内存 ，排序后返回

2.row_id排序模式

​ 需要查询的字段在max_length_for_sort_data放不下， 只拿主键ID与排序字段，排序后多一次回表（回主键索引拿其他字段） 然 后返回

怎么判断是否orderby用到了索引？ 如果输出Extra的列 EXPLAIN不包含Using filesort，则使用索引如果输出Extra列EXPLAIN包含 Using filesort，则未使用索引。

25、慢日志查询

MySQL慢查询日志记录了查询执行时间超过指定阈值的SQL语句，帮助开发者识别和优化性能瓶颈。以下是打开和使用MySQL慢查询日志的步骤：

1. 打开慢查询日志

要打开慢查询日志，你需要在MySQL配置文件（通常是my.cnf或my.ini）中设置以下参数：

[mysqld]
slow_query_log = 1
slow_query_log_file = /path/to/your/logfile.log
long_query_time = 1
log_queries_not_using_indexes = 1

• slow_query_log = 1：启用慢查询日志。
• slow_query_log_file：指定慢查询日志文件的路径。
• long_query_time：查询执行时间超过这个值（秒）的SQL语句将被记录。这里设置为1秒，你可以根据需要调整。
• log_queries_not_using_indexes：记录没有使用索引的查询。这对于识别可以优化的查询很有用。

修改配置文件后，需要重启MySQL服务以应用更改。

2. 查看慢查询日志

你可以使用任何文本编辑器打开并查看慢查询日志文件。日志文件将包含执行时间超过阈值的SQL语句及其相关信息，如执行时间、是否使用了索引等。

3. 分析慢查询日志

分析慢查询日志可以帮助你识别性能瓶颈并进行优化。你可以手动查看日志文件，也可以使用工具如mysqldumpslow来分析日志。

mysqldumpslow是MySQL官方提供的一个用于分析慢查询日志的工具。它可以帮助你按查询时间、锁定时间等对慢查询进行排序，从而更容易地找到需要优化的查询。

使用mysqldumpslow的示例命令：

mysqldumpslow /path/to/your/logfile.log

你还可以添加各种选项来过滤和排序结果。例如，使用-s t_query选项按查询时间排序：

mysqldumpslow -s t_query /path/to/your/logfile.log

4. 优化查询

通过分析慢查询日志，你可以识别出执行时间较长的查询并进行优化。优化方法可能包括添加或修改索引、重写查询语句、调整数据库结构等。在进行任何更改之前，请确保备份数据库以防止数据丢失。

26、InnoDB存储引擎怎么做到ACID？

InnoDB存储引擎是MySQL数据库的一个存储引擎，它支持事务处理，并且遵循ACID（原子性、一致性、隔离性、持久性）原则。以下是InnoDB如何实现这四个特性的简要说明：

Atomicity（原子性）

原子性确保事务被视为一个单独的“单元”，即事务内的操作要么全部完成，要么全部不完成，不可能结束在中间某个环节。InnoDB通过undo日志来保证原子性。如果事务在执行过程中发生错误或者用户主动回滚，InnoDB可以利用undo日志中的信息将数据回滚到事务开始之前的状态。

Consistency（一致性）

一致性确保事务将数据库从一个一致的状态转变到另一个一致的状态。InnoDB通过一系列的内部机制（如锁、MVCC等）来维护数据的一致性。例如，当多个事务并发执行时，InnoDB使用锁来防止它们同时修改同一行数据，从而避免了数据的不一致。同时，InnoDB的MVCC（多版本并发控制）机制可以确保每个事务都看到一致的数据视图，即使在其执行过程中有其他事务修改了数据。

Isolation（隔离性）

隔离性确保并发执行的事务不会彼此干扰。InnoDB提供了多种隔离级别（如READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE），允许用户根据应用的需求选择合适的隔离级别。不同的隔离级别提供了不同程度的隔离性，但也可能导致不同的问题（如脏读、不可重复读、幻读等）。InnoDB的默认隔离级别是REPEATABLE READ。

Durability(持久性)

持久性确保一旦事务被提交，它对数据库中数据的改变就是永久性的。InnoDB通过redo日志和doublewrite buffer等技术来保证数据的持久性。当事务提交时，InnoDB会先将修改写入redo日志，然后再异步地刷新到磁盘上。这样，即使系统突然崩溃，重启后也可以利用redo日志来恢复数据。同时，doublewrite buffer机制可以在写磁盘前先将数据写入一个缓冲区，从而减少了因磁盘故障导致的数据损坏的风险。

综上所述，InnoDB存储引擎通过一系列复杂的内部机制和技术来实现ACID原则，保证了事务的原子性、一致性、隔离性和持久性。

27、redo log，undo log，bin log的作用

redo log、undo log和bin log都是数据库系统中重要的日志类型，它们在数据库事务处理和数据恢复中起着关键的作用。

1. redo log（重做日志）：

• 主要作用是确保事务的持久性，防止在发生故障的时间点，尚有脏页未写入磁盘。在重启数据库服务的时候，系统可以根据redo log进行重做，从而达到事务的持久性这一特性。
• redo log是InnoDB引擎级别的，用来记录该引擎中表的数据修改操作，不管事务是否提交都会记录下来。
• redo log是顺序写入的，因此其占用的存储空间非常小，且写入速度较快。

2. undo log（回滚日志）：

• 主要作用是保存事务发生之前的数据的一个版本，可以用于事务回滚。当事务执行失败或需要回滚时，系统可以利用undo log中的数据将数据库恢复到事务开始之前的状态。
• undo log还提供了多版本并发控制（MVCC）下的读操作，即非锁定读。通过undo log，事务可以看到一致的数据视图，即使在其执行过程中有其他事务修改了数据。
• undo log是实现事务原子性的重要手段之一。

3. bin log（二进制日志）：

• 主要作用是用于数据库的主从复制和恢复操作。在主从复制中，从库利用主库上的bin log进行重播，实现主从同步。同时，bin log也可以用于数据库的恢复操作，通过重播bin log中的事件，可以将数据库恢复到某个特定时间点的状态。
• bin log是MySQL数据库级别的文件，记录了对MySQL数据库执行修改的所有操作（不包括SELECT和SHOW等查询操作）。
• bin log是逻辑日志，记录的是SQL语句的原始逻辑，而不是物理数据页面的修改信息。这与redo log的物理日志性质有所不同。

综上所述，redo log、undo log和bin log在数据库系统中各自扮演着重要的角色，共同维护着数据库的数据完整性和一致性。

28、事务并发产生的一致性问题

事务并发执行时，可能会产生以下几种一致性问题：

1. 丢失修改（Lost Update）：
   当两个或多个事务同时读取同一数据并对其进行修改时，最后提交的事务的修改结果会覆盖其他事务的修改，导致其他事务的修改丢失。这种情况通常发生在没有采取任何并发控制措施的情况下。

2. 脏读（Dirty Read）：
   一个事务读取了另一个尚未提交的事务的修改结果。如果后续该事务发生了回滚，那么前一个事务读取到的数据就是脏数据，因为它反映了从未真正存在于数据库中的数据状态。

3. 不可重复读（Non-Repeatable Read）：
   在同一事务中，多次读取同一数据，但在读取过程中，其他事务对该数据进行了修改并提交，导致后续读取到的结果与之前的读取结果不一致。这种情况下的数据不一致是由于其他事务的修改造成的。

4. 幻读（Phantom Read）：
   一个事务在读取某个范围内的数据时，另一个事务向该范围内插入了新的数据，导致前一个事务再次读取该范围的数据时，发现出现了之前没有的数据行。幻读与不可重复读类似，但区别在于幻读是由于新插入的数据行造成的，而不可重复读是由于已有数据行的修改造成的。

为了解决这些并发一致性问题，数据库管理系统提供了不同的事务隔离级别（如读未提交、读已提交、可重复读和串行化），以允许开发者根据应用的需求选择合适的隔离级别。通过事务隔离级别，可以控制事务之间的可见性和并发性，从而避免或减少上述一致性问题的发生。

29、事务的隔离级别

事务隔离级别分为四种，由低到高分别为：

1. Read Uncommitted（读未提交）：这是最低的隔离级别，事务中的修改，即使没有提交，其他事务也可以看得到。这会导致“脏读”、“幻读”和“不可重复读取”。如无特殊情况，基本是不会使用这种隔离级别的。
2. Read Committed（读已提交）：大多数主流数据库的默认事务等级。它保证了一个事务不会读到另一个并行事务已修改但未提交的数据，避免了“脏读取”，但不能避免“幻读”和“不可重复读取”。该级别适用于大多数系统。
3. Repeatable Read（可重复读）：这是MySQL的默认隔离级别。它确保了在同一事务中多次读取同样记录的结果是一致的，避免了“脏读取”和“不可重复读取”，但可能出现“幻读”。（innodb中解决了幻读问题，通过mvcc，lbcc）
4. Serializable（串行化）：这是最高的隔离级别，也是最严格的级别。事务串行执行，资源消耗最大，但“脏读”、“不可重复读”和“幻读”都可以被避免。由于执行效率差，性能开销大，所以基本不会被使用。

30、MySQL中MVCC简述

MVCC，全称Multi-Version Concurrency Control，即多版本并发控制。在MySQL中，MVCC是一种并发控制的方法，主要用于InnoDB存储引擎中，以实现对数据库的并发访问。

MVCC的主要目的是提高数据库的并发性能，用更好的方式去处理读-写和写-写的冲突。在MVCC下，只有写写之间会阻塞，读读、读写、写读都可以并行操作，从而大大提高了数据库的并发处理能力。

在InnoDB中，MVCC是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了这个行的创建时间，一个保存的是行的删除时间（或称为过期时间）。这里的创建时间和删除时间并不是实际的时间值，而是系统版本号。每开始一个新的事务，系统版本号就会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。

此外，InnoDB的MVCC还使用一致性视图来实现不同的隔离级别。一致性视图是在事务开始时创建的，它包含了当前系统中所有活跃事务的列表。通过这个列表，InnoDB可以判断哪些事务的修改对当前事务是可见的，哪些是不可见的。

总的来说，MVCC是MySQL InnoDB存储引擎中一种非常重要的并发控制技术，它使得多个事务可以在同一时间对同一份数据进行读写操作而不会互相干扰，从而大大提高了数据库的并发处理能力。

31、MVCC如何解决不可重复读问题和幻读问题？

MVCC（多版本并发控制）是MySQL的InnoDB存储引擎中用于解决并发问题的一种技术。通过MVCC，InnoDB可以在高并发环境下提供一致的非锁定读，同时解决不可重复读和幻读问题。

1. 解决不可重复读问题：

不可重复读是指在同一事务中多次读取同一数据，但在读取过程中，由于其他事务的修改导致后续读取到的结果与之前的读取结果不一致。

MVCC通过为每个事务提供一个唯一的事务ID，并在每行数据上保存创建版本号和删除版本号（或过期版本号），来解决不可重复读问题。当事务读取数据时，它只读取版本号小于或等于当前事务ID的行，并且这些行没有被标记为删除（即删除版本号大于当前事务ID或没有删除版本号）。这样，即使其他事务修改了数据并提交，当前事务仍然只能看到它开始时的数据版本，从而保证了可重复读。

2. 解决幻读问题：

幻读是指在同一事务中执行相同的查询，但由于其他事务插入了新的数据，导致后续查询结果中出现了之前没有的数据行。

在MVCC中，通过一致性视图（Consistency View）来解决幻读问题。一致性视图是在事务开始时创建的，它包含了当前系统中所有活跃事务的列表。通过这个列表，InnoDB可以判断哪些事务的修改对当前事务是可见的，哪些是不可见的。当事务执行查询时，它只查看在一致性视图中创建版本号小于或等于当前事务ID的行。这样，即使其他事务插入了新的数据并提交，只要这些数据的创建版本号大于当前事务的一致性视图中的最小活跃事务ID，它们对当前事务就是不可见的。因此，当前事务的查询结果不会受到其他事务插入新数据的影响，从而避免了幻读问题。

需要注意的是，虽然MVCC可以解决不可重复读和幻读问题，但它并不能解决所有的并发问题。例如，它无法解决写-写冲突（即两个事务同时修改同一行数据）的问题。这种冲突需要通过锁机制来解决。在InnoDB中，除了MVCC外，还使用了行级锁和间隙锁等机制来进一步保证并发控制的一致性和隔离性。

32、LBCC（锁的并发控制）是什么

LBCC是Lock-Based Concurrent Control的简称，意思是基于锁的并发控制。InnoDB存储引擎使用LBCC来解决事务并发时可能出现的问题。

在InnoDB中，LBCC主要利用锁的机制来实现对并发事务的控制。这些锁包括共享锁（S）、排他锁（X）以及意向锁等。其中，共享锁允许多个事务同时读取同一资源，而排他锁则只允许一个事务对资源进行写操作。意向锁则用于在行级锁或表级锁上设置锁的意向，以便其他事务能够了解当前事务的锁需求。

此外，InnoDB还实现了记录锁、间隙锁和临键锁等锁算法。记录锁用于锁定单个行记录，间隙锁用于锁定一个范围但不包括记录本身，而临键锁则是记录锁和间隙锁的组合，锁定一条记录以及它前面的间隙。

通过这些锁机制和算法，LBCC能够在多个事务并发执行时保护数据的完整性和一致性。但需要注意的是，LBCC可能会导致一定的性能开销，因为锁的竞争和等待可能会增加事务的执行时间。因此，在实际应用中，需要根据具体的业务场景和需求来选择合适的并发控制策略。