MySQL Glossary

A

.ARM file

ARCHIVE 表的元数据。与 .ARZ 文件 相比。具有此扩展名的文件始终包含在由 mysqlbackup 命令生成的备份中，该命令是 MySQL Enterprise Backup 产品的一部分。

另见 .ARZ 文件, MySQL Enterprise Backup, mysqlbackup 命令。

.ARZ file

ARCHIVE 表的数据。与 .ARM 文件 相比。具有此扩展名的文件始终包含在由 mysqlbackup 命令生成的备份中，该命令是 MySQL Enterprise Backup 产品的一部分。

另见 .ARM 文件, MySQL Enterprise Backup, mysqlbackup 命令。

ACID

atomicity、consistency、isolation 和 durability 的缩写。这些属性都是数据库系统中所需的，并且都与事务概念紧密相关。InnoDB 的事务功能遵循 ACID 原则。

事务是原子工作单元，可以 提交 或 回滚。当事务对数据库进行多个更改时，或者所有更改在提交时成功，或者所有更改在回滚时撤销。

数据库始终保持一致状态 —— 在每个提交或回滚后，以及事务进行中。如果相关数据跨多个表进行更新，查询将看到所有旧值或所有新值，而不是旧值和新值的混合。

事务在进行中受到保护（隔离），以免相互干扰或看到未提交的数据。这种隔离是通过 锁定 机制实现的。经验丰富的用户可以调整 隔离级别，以换取更高的性能和 并发性，只要他们可以确保事务真的不相互干扰。

事务的结果是持久的：一旦提交操作成功，事务所做的更改就安全了，不会受到电源故障、系统崩溃、竞争条件或其他潜在危险的影响。（在 InnoDB 中，双写缓冲区 有助于持久性。）

另见 原子, 提交, 并发性, 双写缓冲区, 隔离级别, 锁定, 回滚, 事务。

adaptive flushing

一个用于 InnoDB 表的算法，用于平滑 检查点 引入的 I/O 开销。相比于从 缓冲池 中刷新所有修改的 页 到 数据文件，MySQL 定期刷新小批量修改的页。自适应刷新算法通过估算最佳刷新速率来扩展此过程，基于刷新速率和 重做 信息的生成速度。

另见 缓冲池, 检查点, 数据文件, 刷新, InnoDB, 页, 重做日志。

adaptive hash index

对于 InnoDB 表的优化，可以使用 = 和 IN 运算符加速查找，通过在内存中构建 哈希索引。MySQL 监控 InnoDB 表的索引搜索，如果查询可以从哈希索引中受益，它将自动构建一个哈希索引，以便频繁访问的索引 页。从某种意义上说，自适应哈希索引使 MySQL 在运行时更接近主内存数据库的架构。这项功能由 innodb_adaptive_hash_index 配置选项控制。由于这项功能对某些工作负载有益，而对其他工作负载无益，并且哈希索引所使用的内存是从 缓冲池 中保留的，因此通常应该在启用和禁用这项功能时进行基准测试。

哈希索引总是基于现有的 B 树 索引构建的。MySQL 可以根据索引的模式构建哈希索引，哈希索引可以是部分的，不需要将整个 B 树索引缓存在缓冲池中。

另见 B 树、缓冲池、哈希索引、页、次要索引。

ADO.NET

对于使用 .NET 技术（如 ASP.NET）构建的应用程序的对象关系映射（ORM）框架。这些应用程序可以通过 Connector/NET 组件与 MySQL 进行接口。

另见 .NET、ASP.NET、Connector/NET、Mono、Visual Studio。

AIO

缩写为 异步 I/O。您可能在 InnoDB 消息或关键字中看到这个缩写。

另见 异步 I/O。

ANSI

在 ODBC 中，支持字符集和其他国际化方面的替代方法。与 Unicode 相比。Connector/ODBC 3.51 是 ANSI 驱动程序，而 Connector/ODBC 5.1 是 Unicode 驱动程序。

另见 Connector/ODBC、ODBC、Unicode。

API

API 提供了对 MySQL 协议和 MySQL 资源的低级访问，从 客户端 程序中。与提供高级访问的 Connector 相比。

另见 C API、客户端、Connector、native C API、Perl API、PHP API、Python API、Ruby API。

application programming interface (API)

一组函数或过程。API 提供了一组稳定的函数和过程名称、类型、参数和返回值。

apply

当由 MySQL Enterprise Backup 产品生成的备份不包括最新的更改时，更新备份文件以包括这些更改的过程称为 应用 步骤。它是通过 mysqlbackup 命令的 apply-log 选项指定的。

在更改应用之前，我们将文件称为 原始备份。在更改应用之后，我们将文件称为 准备备份。这些更改记录在 ibbackup_logfile 文件中；一旦应用步骤完成，这个文件就不再需要了。

另见 热备份、ibbackup_logfile、MySQL Enterprise Backup、预备备份、原始备份。

AS

Kerberos身份验证服务器。AS也可以指身份验证服务器提供的身份验证服务。

另见 身份验证服务器。

ASP.net

使用.NET技术和语言开发Web应用程序的框架。这些应用程序可以通过 Connector/NET 组件与MySQL接口。

使用MySQL的另一种服务器端网页技术是 PHP。

另见 .NET、ADO.NET、Connector/NET、Mono、PHP、Visual Studio。

assembly

.NET系统中编译代码库，通过 Connector/NET 访问。存储在 GAC 中，以避免命名冲突。

另见 .NET、GAC。

asynchronous I/O

允许其他处理继续进行的I/O操作。也称为 非阻塞I/O，缩写为 AIO。 InnoDB 使用这种I/O类型来执行某些可以并行运行的操作，而不会影响数据库的可靠性，例如读取尚未实际请求的页面到 缓冲池 中，但可能很快需要这些页面。

历史上，InnoDB 只在Windows系统上使用异步I/O。从InnoDB插件1.1和MySQL 5.5开始，InnoDB 在Linux系统上使用异步I/O。这引入了对 libaio 的依赖关系。在Linux系统上，异步I/O通过 innodb_use_native_aio 选项配置，默认启用。在其他类Unix系统上，InnoDB 只使用同步I/O。

另见 缓冲池、非阻塞I/O。

atomic

在SQL上下文中，事务 是要么完全成功（当 提交 时）要么完全无效（当 回滚 时）。事务的不可分割性是 ACID 首字母的“A”。

另见 ACID、提交、回滚、事务。

atomic DDL

原子 DDL 语句是将 数据字典 更新、存储引擎 操作和 二进制日志 写入组合成单个原子事务的DDL语句。事务要么完全提交要么完全回滚，即使服务器在操作过程中停止。原子DDL支持从MySQL 8.0开始。更多信息，请参阅 第15.1.1节，“原子数据定义语句支持”。

另见 二进制日志、数据字典、DDL、存储引擎。

atomic instruction

CPU提供的特殊指令，以确保关键的低级操作不能被中断。

authentication server

在 Kerberos 中，提供初始票据所需的服务，以获取票据授予服务器（TGS）颁发的其他票据。身份验证服务器（AS）与 TGS 组合成密钥分配中心（KDC）。

另见 密钥分配中心，票据授予服务器。

auto-increment

表列的属性（由 AUTO_INCREMENT 关键字指定），自动添加升序序列值到该列中。

这为开发者节省了工作，不需要在插入新行时生成唯一值。它为查询优化器提供了有用的信息，因为该列是非空的且具有唯一值。该列的值可以在各种上下文中用作查找键，因为它们是自动生成的，所以没有理由更改它们；因此，主键列通常指定为自动递增。

自动递增列可能会在基于语句的复制中出现问题，因为在副本上重放语句可能不会生成与源相同的列值，due to timing issues。当您拥有自动递增的主键时，可以使用基于语句的复制，只需将 innodb_autoinc_lock_mode=1 设置。如果您拥有 innodb_autoinc_lock_mode=2，允许插入操作的更高并发性，请使用 基于行的复制 而不是 基于语句的复制。设置 innodb_autoinc_lock_mode=0 不应用于除兼容性目的以外的任何情况。

连续锁模式（innodb_autoinc_lock_mode=1）是 MySQL 8.0.3 之前的默认设置。从 MySQL 8.0.3 开始，交叉锁模式（innodb_autoinc_lock_mode=2）是默认设置，这反映了从基于语句的复制到基于行的复制的默认复制类型的变化。

另见 自动递增锁定，innodb_autoinc_lock_mode，主键，基于行的复制，基于语句的复制。

auto-increment locking

自动递增主键的便捷性与并发性之间存在一些tradeoff。在最简单的情况下，如果一个事务正在将值插入表中，任何其他事务都必须等待执行自己的插入，以便第一个事务插入的行可以获得连续的主键值。InnoDB 包括优化和 innodb_autoinc_lock_mode 选项，以便您可以配置最佳的自动递增值序列和最大 并发性 的平衡。

另见 自动递增，并发性，innodb_autoinc_lock_mode。

autocommit

一个设置，导致每个 SQL 语句后执行 提交 操作。此模式不建议用于处理 InnoDB 表的跨多个语句的事务中。它可以提高 只读事务 的性能，特别是在 MySQL 5.6.4 及更高版本中，减少了锁定和撤销数据的开销。它也适用于处理 MyISAM 表，其中事务不可用。

另见 提交，锁定，只读事务，SQL，事务，撤销。

availability

能力来cope with，并在必要时从主机故障中恢复，包括MySQL、操作系统或硬件故障，以及可能导致停机的维护活动。通常与可扩展性一起作为大规模部署的关键方面。

另见 可扩展性。

B

B-tree

一种流行的树形数据结构，用于数据库索引。该结构始终保持排序状态，启用快速查找exact matches（等于操作符）和范围（例如大于、小于和BETWEEN操作符）。这种类型的索引可用于大多数存储引擎，例如InnoDB和MyISAM。

因为B树节点可以有许多子节点，因此B树不同于二叉树，每个节点最多只有2个子节点。

与哈希索引形成对比，哈希索引仅在MEMORY存储引擎中可用。MEMORY存储引擎也可以使用B树索引，并且您应该为MEMORY表选择B树索引，如果某些查询使用范围操作符。

使用B树术语是指一般的索引设计类别。MySQL存储引擎使用的B树结构可以被视为经典B树设计的变体。有关信息，请参阅InnoDB页结构Fil Header部分的MySQL Internals Manual。

另见 哈希索引。

backticks

在MySQL SQL语句中，标识符必须使用反引号字符（`）括起来，如果它们包含特殊字符或保留字。例如，要引用名为FOO#BAR的表或名为SELECT的列，您将指定标识符为`FOO#BAR`和`SELECT`。由于反引号提供了额外的安全级别，因此它们广泛应用于程序生成的SQL语句中，其中标识符名称可能不提前知道。

许多其他数据库系统使用双引号（"）括起这些特殊名称。为了可移植性，您可以在MySQL中启用ANSI_QUOTES模式，并使用双引号而不是反引号来限定标识符名称。

另见 SQL。

backup

将MySQL实例中的某些或所有表数据和元数据复制到安全位置，以便保存。这也是DBA的关键任务。该过程的逆操作是恢复操作。

使用MySQL，可以使用MySQL Enterprise Backup产品执行物理备份，使用mysqldump命令执行逻辑备份。这些技术在备份数据的大小和表示形式、速度（特别是恢复操作的速度）方面有所不同。

备份还可以根据对正常数据库操作的干扰程度分类为热备份、温备份或冷备份。（热备份对正常数据库操作的干扰最小，冷备份干扰最大。）

另见 冷备份、热备份、逻辑备份、MySQL Enterprise Backup、mysqldump、物理备份、温备份。

base column

基础列是指存储生成列或虚拟生成列所基于的非生成表列。换言之，基础列是生成列定义的一部分的非生成表列。

另见 生成列、存储生成列、虚拟生成列。

beta

软件产品生命周期的早期阶段，当它仅供评估时，通常没有明确的版本号或小于1的版本号。InnoDB 不使用 beta 标志，宁愿使用 早期采用者 阶段，该阶段可能跨越多个点版本，直到 GA 版本的发布。

另见 早期采用者, GA。

binary log

一个包含所有语句或行更改的记录文件，以便在 复制 场景中将副本更新到最新状态，或者在从备份中恢复表数据时将数据库更新到最新状态。二进制日志记录功能可以打开和关闭，尽管 Oracle 建议如果您使用复制或执行备份时总是启用它。

您可以使用 mysqlbinlog 命令检查二进制日志的内容或在复制或恢复期间重放它。有关二进制日志的完整信息，请参阅 第 7.4.4 节，“二进制日志”。有关 MySQL 配置选项的二进制日志，请参阅 第 19.1.6.4 节，“二进制日志记录选项和变量”。

对于 MySQL 企业备份 产品，二进制日志文件的文件名和当前位置在文件中的重要细节。在复制上下文中拍摄备份时，您可以指定 --slave-info 选项来记录源的这些信息。

在 MySQL 5.0 之前，有一个类似的功能，称为更新日志。在 MySQL 5.0 及更高版本中，二进制日志取代了更新日志。

另见 binlog, MySQL 企业备份, 复制。

binlog

二进制日志文件的非正式名称。例如，您可能在电子邮件或论坛讨论中看到这个缩写。

另见 二进制日志。

blind query expansion

全文搜索 的特殊模式，通过 WITH QUERY EXPANSION 子句启用。它执行两次搜索，其中第二次搜索的搜索短语是原始搜索短语与第一次搜索结果中最相关的几份文档的连接。这项技术主要适用于短搜索短语，可能只有一个单词。它可以发现相关匹配项，其中精确的搜索词语不在文档中出现。

另见 全文搜索。

BLOB

SQL 数据类型 (TINYBLOB, BLOB, MEDIUMBLOB, 和 LONGBLOB)，用于存储任意二进制数据的对象，大小不限。用于存储文档、图像、音频文件和其他无法轻松分解到 MySQL 表中的行和列中的信息。处理 BLOB 的技术因 Connector 和 API 而异。MySQL Connector/ODBC 将 BLOB 值定义为 LONGVARBINARY。对于大型、自由形式的字符数据集合，行业术语是 CLOB，由 MySQL TEXT 数据类型表示。

另见 API, CLOB, Connector, Connector/ODBC。

bottleneck

系统中的一部分，大小或容量受到限制，从而限制了整体吞吐量。例如，内存区域可能小于所需大小；访问单个必需资源可能会阻止多个 CPU 核心同时运行；或等待磁盘 I/O 完成可能会阻止 CPU 以满负荷运行。消除瓶颈往往会提高 并发性。例如，拥有多个 InnoDB 缓冲池 实例可以减少同时从缓冲池读取和写入时的争用。

另见 缓冲池, 并发性。

bounce

shutdown 操作紧接着重新启动。理想情况下，伴随着相对较短的 热身 期间，以便性能和吞吐量快速恢复到高水平。

另见 shutdown。

buddy allocator

InnoDB 缓冲池 中管理不同大小的 页 的机制。

另见 缓冲池, 页, 页大小。

buffer

用于临时存储的内存或磁盘区域。数据在内存中缓存，以便高效地写入磁盘，使用少量的大型 I/O 操作，而不是许多小型操作。数据在磁盘上缓存，以提高可靠性，以便在最坏情况下崩溃或其他故障时恢复。InnoDB 使用的主要缓冲类型是 缓冲池、双写缓冲 和 更改缓冲。

另见 缓冲池, 更改缓冲, 崩溃, 双写缓冲。

buffer pool

保存缓存的 InnoDB 数据的内存区域，用于表和索引。为了高效地执行大量读取操作，缓冲池被分成可以容纳多行的 页。为了高效地管理缓存，缓冲池被实现为一个链表的页；很少使用的数据将被从缓存中删除，使用一种 LRU 算法的变体。在大内存系统上，您可以通过将缓冲池分成多个 缓冲池实例 来提高并发性。

多个 InnoDB 状态变量、INFORMATION_SCHEMA 表和 performance_schema 表有助于监控缓冲池的内部工作。从 MySQL 5.6 开始，您可以通过在服务器关闭时保存缓冲池状态并在服务器启动时恢复缓冲池状态来避免长时间的热身期，特别是在大缓冲池实例的情况下。见 第 17.8.3.6 节，“保存和恢复缓冲池状态”。

另见 缓冲池实例, LRU, 页, 热身。

buffer pool instance

缓冲池 可以被分成多个区域，由 innodb_buffer_pool_instances 配置选项控制。总的内存大小由 innodb_buffer_pool_size 指定，并在所有缓冲池实例之间分配。通常，对于分配多个 gigabyte 到 InnoDB 缓冲池的系统，拥有多个缓冲池实例是合适的，每个实例为一个 gigabyte 或更大。在系统加载或从缓冲池中查找大量数据的同时，从多个并发会话中减少了对数据结构的争用。

另见 缓冲池。

built-in

MySQL 中的内置 InnoDB 存储引擎是存储引擎的原始形式。与 InnoDB 插件 相比。从 MySQL 5.5 开始，InnoDB 插件被合并回 MySQL 代码库作为内置的 InnoDB 存储引擎（也称为 InnoDB 1.1）。

这种区别主要在 MySQL 5.1 中很重要，其中一个功能或 bug 修复可能适用于 InnoDB 插件但不适用于内置的 InnoDB，反之亦然。

另见 InnoDB。

business rules

商业软件的基础规则和操作序列，用于运行商业公司。有时这些规则是由法律规定的，有时是由公司政策规定的。精心的规划确保数据库中编码和执行的关系，以及应用逻辑执行的操作，准确地反映公司的真实政策，并能够处理真实情况。

例如，员工离开公司可能会触发人力资源部门的一系列操作。人力资源数据库也需要灵活地表示关于某人被雇佣但尚未开始工作的数据。关闭在线服务的账户可能会导致数据库中的数据被删除，或者数据可能被移动或标记，以便在账户重新打开时恢复。公司可能会制定薪资最大值、最小值和调整政策，以及基本的合理性检查，例如薪资不能是负数。零售数据库可能不允许使用相同的序列号返回多次，或者不允许信用卡购买超过一定的值，而欺诈检测数据库可能允许这些事情。

另见 关系型。

C

.cfg file

使用 InnoDB 可移植表空间 功能的元数据文件。它是由命令 FLUSH TABLES ... FOR EXPORT 生成的，将一个或多个表置于一致的状态，以便复制到另一个服务器。该 .cfg 文件与相应的 .ibd 文件 一起被复制，并在 ALTER TABLE ... IMPORT TABLESPACE 步骤中用于调整 .ibd 文件的内部值，例如 space ID。

另见 .ibd 文件、space ID、可移植表空间。

C

一种编程语言，结合了可移植性、性能和对低级硬件特性的访问，成为编写操作系统、驱动程序和其他系统软件的流行选择。许多复杂的应用程序、语言和可重用模块都包含用 C 编写的部分，连接到高级组件上。其核心语法与 C++、Java 和 C# 开发者熟悉。

另见 C API、C++、C#、Java。

C API

C API 代码与 MySQL 一起分发。它包含在 libmysqlclient 库中，启用 C 程序访问数据库。

另见 API、C、libmysqlclient。

C#

一种编程语言，结合了强类型和面向对象特性，在 Microsoft .NET 框架或其开源对应项 Mono 中运行。经常用于创建使用 ASP.net 框架的应用程序。其语法与 C、C++ 和 Java 开发者熟悉。

另见 .NET、ASP.net、C、Connector/NET、C++、Java、Mono。

C++

一个面向 C 开发者熟悉的核心语法编程语言。提供了低级操作的访问权限，以提高性能，结合了高级数据类型、面向对象特性和垃圾回收。要编写 MySQL 的 C++ 应用程序，您使用 Connector/C++ 组件。

另见 C, Connector/C++。

cache

任意存储频繁或高速检索数据的内存区域。在 InnoDB 中，主要的缓存结构是 缓冲池。

另见 缓冲, 缓冲池。

cardinality

表中的不同值的数量。当查询引用具有关联 索引 的列时，每列的基数会影响哪种访问方法最有效。例如，对于具有 唯一约束 的列，基数等于表中的行数。如果表有百万行，但某列只有 10 个不同的值，每个值平均出现 10 万次。查询如 SELECT c1 FROM t1 WHERE c1 = 50; 可能返回 1 行或大量行，数据库服务器可能根据 c1 的基数以不同的方式处理查询。

如果列中的值分布非常不均匀，基数可能不是确定最佳查询计划的好方法。例如，SELECT c1 FROM t1 WHERE c1 = x; 可能返回 1 行当 x=50，返回大量行当 x=30。在这种情况下，您可能需要使用 索引提示 来传递关于哪种查找方法对特定查询更有效的建议。

基数也可以应用于多个列中的不同值，如在 复合索引 中。

另见 列, 复合索引, 索引, 索引提示, 持久统计信息, 随机潜水, 选择性, 唯一约束。

change buffer

记录 页 在 次要索引 中的更改的特殊数据结构。这些值可能来自 SQL INSERT、UPDATE 或 DELETE 语句（DML）。这些功能的集合被称为 更改缓冲，包括 插入缓冲、删除缓冲 和 清除缓冲。

只有当次要索引的相关页不在 缓冲池 中时，才会在更改缓冲中记录更改。当相关索引页被带入缓冲池时，相关更改将被应用（合并）到缓冲池中，使用更改缓冲中的数据。定期，清除 操作在系统空闲或慢速关闭时运行，将新的索引页写入磁盘。清除操作可以更高效地将一系列索引值写入磁盘，而不是每个值都写入磁盘。

物理上，更改缓冲是 系统表空间 的一部分，因此索引更改可以跨数据库重启保持缓冲。只有当页被带入缓冲池时，才会应用（合并）更改。

存储在更改缓冲区中的数据种类和数量由 innodb_change_buffering 和 innodb_change_buffer_max_size 配置选项所控制。要查看当前更改缓冲区中的数据信息，请发出 SHOW ENGINE INNODB STATUS 命令。

以前称为 插入缓冲区。

另见 缓冲池、更改缓冲、删除缓冲、DML、插入缓冲区、插入缓冲、合并、页、清除、清除缓冲、次要索引、系统表空间。

change buffering

一般来说，涉及 更改缓冲区 的功能，包括 插入缓冲、删除缓冲 和 清除缓冲。索引更改来自 SQL 语句，这些操作可能涉及随机 I/O 操作，但它们被延迟并由后台 线程 定期执行。该序列操作可以更高效地将磁盘块写入磁盘，而不是每个值都立即写入磁盘。由 innodb_change_buffering 和 innodb_change_buffer_max_size 配置选项控制。

另见 更改缓冲区、删除缓冲、插入缓冲、清除缓冲。

checkpoint

当对缓存在 缓冲池 中的数据页进行更改时，这些更改将在稍后写入 数据文件，这称为 刷新。检查点是记录最新更改（由 LSN 值表示）的记录，这些更改已经成功写入数据文件。

另见 缓冲池、数据文件、刷新、模糊检查点、LSN。

checksum

在 InnoDB 中，用于检测从磁盘读取到 InnoDB 缓冲池 的 页 中的 corruption 的验证机制。该功能由 innodb_checksums 配置选项在 MySQL 5.5 中控制。innodb_checksums 在 MySQL 5.6.3 中已弃用，取而代之的是 innodb_checksum_algorithm。

命令 innochecksum 帮助诊断 corruption 问题，通过测试指定的 表空间 文件的 checksum 值，而 MySQL 服务器关闭时。

MySQL 也使用 checksums 用于复制目的。有关详细信息，请参阅配置选项 binlog_checksum、source_verify_checksum 或 master_verify_checksum，以及 replica_sql_verify_checksum 或 slave_sql_verify_checksum。

另请参阅 缓冲池、页、表空间。

child table

在外键关系中，子表是一种其行引用（或指向）另一个表的行的表，该表包含 FOREIGN KEY ... REFERENCES 子句和可选的 ON UPDATE 和 ON DELETE 子句。相应的行在父表中必须存在，然后才能在子表中创建该行。子表中的值可以防止父表的删除或更新操作，或者根据创建外键时使用的 ON CASCADE 选项，自动删除或更新子表。

另请参阅 外键、父表。

clean page

在 InnoDB 缓冲池 中的一 页，其中所有在内存中的更改也已写入（flushed)到 数据文件 中。与 脏页 相反。

另请参阅 缓冲池、数据文件、脏页、flush、页。

clean shutdown

一个 关闭，它在完成时不出错，并在完成前将所有更改应用于 InnoDB 表，相比之下是一个 崩溃 或 快速关闭。同义词为 慢关闭。

另请参阅 崩溃、快速关闭、关闭、慢关闭。

client

一个在数据库服务器外运行的程序，通过发送请求通过 连接器 或通过 API made available 通过 客户端库 与数据库通信。它可以在与数据库服务器相同的物理机器上运行，也可以在远程机器上通过网络连接。它可以是一个特殊目的数据库应用程序，也可以是一个通用程序，如 mysql 命令行处理器。

另请参阅 API、客户端库、连接器、mysql、服务器。

client libraries

包含数据库函数集合的文件。通过编译程序与这些库，或者在同一系统上安装它们，您可以在没有 MySQL 服务器安装的机器上运行数据库应用程序（也称为 客户端）; 应用程序通过网络访问数据库。使用 MySQL，您可以使用来自 MySQL 服务器的 libmysqlclient 库。

另请参阅 客户端、libmysqlclient。

client-side prepared statement

一种 预备语句，其中缓存和重用是本地管理的，模拟 服务器端预备语句 的功能。历史上，一些 Connector/J、Connector/ODBC 和 Connector/PHP 开发者使用它来解决服务器端存储过程的问题。随着 MySQL 服务器版本的更新，服务器端预备语句现在推荐用于性能、可扩展性和内存效率。

另见 Connector/J、Connector/ODBC、Connector/PHP、预备语句。

CLOB

一个 SQL 数据类型 (TINYTEXT、TEXT、MEDIUMTEXT 或 LONGTEXT)，用于存储任意大小的字符数据，具有关联的字符集和排序顺序。处理 CLOBs 的技术因 Connector 和 API 而异。MySQL Connector/ODBC 将 TEXT 值定义为 LONGVARCHAR。对于存储二进制数据，等效类型是 BLOB。

另见 API、BLOB、Connector、Connector/ODBC。

clustered index

InnoDB 术语中的 主键 索引。InnoDB 表存储基于主键列的值，以加速查询和排序涉及主键列的操作。为获得最佳性能，请根据最重要的查询选择主键列，因为修改聚簇索引的列是昂贵的操作。

在 Oracle Database 产品中，这种表类型称为 索引组织表。

另见 索引、主键、次要索引。

cold backup

在数据库关闭时进行的 备份。对于繁忙的应用程序和网站，这可能不可行，您可能需要 温备份 或 热备份。

另见 备份、热备份、温备份。

column

行 中的一个数据项，其存储和语义由数据类型定义。每个 表 和 索引 都是由其包含的列定义的。

每个列都有一个 基数 值。一个列可以是其表的 主键，或是主键的一部分。一个列可以受到 唯一约束 或 非空约束 的限制，或者两者都有。不同列的值，甚至跨越不同的表，可以通过 外键 关系链接。

在 MySQL 内部操作的讨论中，有时 字段 被用作同义词。

另见 基数、外键、索引、非空约束、主键、行、表、唯一约束。

column index

一个 索引 在单个列上。

另请参阅 复合索引, 索引。

column prefix

当创建索引时指定长度，例如 CREATE INDEX idx ON t1 (c1(N)), 只有列值的前 N 个字符被存储在索引中。保持索引前缀小可以使索引紧凑，节省内存和磁盘 I/O，从而提高性能。（尽管使索引前缀太小可能会阻碍查询优化器，因为具有不同值的行可能被视为重复项。）

对于包含二进制值或长文本字符串的列，排序不是主要考虑因素，而存储整个值在索引中将浪费空间，索引自动使用值的前 N（通常为 768）个字符进行查找和排序。

另请参阅 索引。

command interceptor

语句拦截器 的同义词。它是 Connector/NET 和 Connector/J 都可用的拦截器设计模式的一方面。Connector/NET 称之为命令，而 Connector/J 称之为语句。与 异常拦截器 相比。

另请参阅 Connector/J, Connector/NET, 异常拦截器, 拦截器, 语句拦截器。

commit

一个 SQL 语句，结束 事务，使事务中的所有更改永久生效。它是 回滚 的反义词，回滚撤销事务中的所有更改。

InnoDB 使用 乐观 机制来提交事务，以便在提交之前将更改写入数据文件。这项技术使提交速度更快，但在回滚时需要更多工作。

默认情况下，MySQL 使用 自动提交 设置，自动在每个 SQL 语句后提交。

另请参阅 自动提交, 乐观, 回滚, SQL, 事务。

compact row format

行格式 的一种类型，用于 InnoDB 表。从 MySQL 5.0.3 到 MySQL 5.7.8，它是默认的行格式。在 MySQL 8.0 中，默认的行格式由 innodb_default_row_format 配置选项定义，默认设置为 DYNAMIC。 COMPACT 行格式提供了比 REDUNDANT 行格式更紧凑的表示形式，用于 null 和可变长度列。

有关 InnoDB COMPACT 行格式的更多信息，请参阅 第 17.10 节，“InnoDB 行格式”。

另请参阅 动态行格式, 文件格式, 冗余行格式, 行格式。

composite index

包含多个列的 索引。

另请参阅 索引。

compressed backup

MySQL Enterprise Backup 产品的压缩功能，它将每个表空间的副本压缩，文件扩展名从 .ibd 更改为 .ibz。压缩备份数据使您可以保留更多的备份，并减少将备份传输到不同服务器的时间。在还原操作期间，数据将被解压缩。当压缩备份操作处理已经压缩的表时，它将跳过压缩步骤，因为再次压缩将不会节省太多空间。

由 MySQL Enterprise Backup 产品生成的一组文件，其中每个 表空间 都被压缩。压缩文件的扩展名将从 .ibd 更改为 .ibz。

在备份过程开始时应用压缩有助于避免存储开销和网络开销，当将备份文件传输到另一个服务器时。应用二进制日志的过程需要更长时间，并需要解压缩备份文件。

另请参阅：应用、二进制日志、压缩、热备份、MySQL Enterprise Backup、表空间。

compressed row format

一种行格式，启用了数据和索引压缩，用于InnoDB表。大字段存储在行数据的其他页面上，如动态行格式。索引页面和大字段都被压缩，从而节省内存和磁盘空间。根据数据结构，内存和磁盘使用的减少可能会或不会超过解压缩数据时的性能开销。请参阅第 17.9 节，“InnoDB 表和页面压缩”，了解使用详细信息。

关于InnoDB COMPRESSED行格式的更多信息，请参阅DYNAMIC 行格式。

另请参阅：压缩、动态行格式、行格式。

compressed table

一个表，其中数据以压缩形式存储。对于InnoDB，它是一个使用ROW_FORMAT=COMPRESSED创建的表。请参阅第 17.9 节，“InnoDB 表和页面压缩”，了解更多信息。

另请参阅：压缩行格式、压缩。

compression

一个具有广泛益处的功能，包括减少磁盘空间、减少 I/O 操作和减少缓存内存的使用。

InnoDB支持表级和页面级压缩。InnoDB页面压缩也称为透明页面压缩。关于InnoDB压缩的更多信息，请参阅第 17.9 节，“InnoDB 表和页面压缩”。

另一种压缩类型是压缩备份功能，属于MySQL Enterprise Backup产品。

另请参阅：缓冲池、压缩备份、压缩行格式、DML、透明页面压缩。

compression failure

并不是错误，而是一种昂贵的操作，可能在使用压缩与DML操作结合时发生。当更新压缩页面时，溢出页面保留区域，导致页面被重新压缩，所有更改被应用于表数据；重新压缩的数据不适合原始页面，需要 MySQL 将数据分割成两个新页面并分别压缩它们。要检查这种情况的频率，请查询INFORMATION_SCHEMA.INNODB_CMP表，并检查COMPRESS_OPS列的值是否超过COMPRESS_OPS_OK列的值。理想情况下，压缩失败不常发生；当它们发生时，可以调整innodb_compression_level、innodb_compression_failure_threshold_pct和innodb_compression_pad_pct_max配置选项。

另请参阅 压缩、DML、页。

concatenated index

另请参阅 复合索引。

concurrency

多个操作（在数据库术语中，事务）可以同时运行，不会相互干扰。并发也涉及性能，因为理想情况下，多个事务的保护机制应该具有最小的性能开销，使用高效的锁定机制。

另请参阅 ACID、锁定、事务。

configuration file

该文件保存了 MySQL 启动时使用的 选项 值。传统上，在 Linux 和 Unix 中该文件名为 my.cnf，在 Windows 中该文件名为 my.ini。您可以在文件的 [mysqld] 部分设置多个与 InnoDB 相关的选项。

另请参阅 第 6.2.2.2 节，“使用选项文件”，了解 MySQL 搜索配置文件的位置。

当您使用 MySQL Enterprise Backup 产品时，通常使用两个配置文件：一个指定数据来自哪里和如何结构化（可能是原始服务器配置文件），另一个包含少量选项，指定备份数据的去向和结构。使用 MySQL Enterprise Backup 产品的配置文件必须包含一些通常在常规配置文件中省略的选项，因此您可能需要将选项添加到现有的配置文件中以便使用 MySQL Enterprise Backup。

另请参阅 my.cnf、MySQL Enterprise Backup、选项、选项文件。

connection

应用程序与 MySQL 服务器之间的通信通道。数据库应用程序的性能和可扩展性受到建立连接速度、同时连接数和连接持久时间的影响。参数如 主机、端口 等在 Connector/NET 中表示为 连接字符串，在 Connector/ODBC 中表示为 DSN。高流量系统使用一种称为 连接池 的优化技术。

另请参阅 连接池、连接字符串、Connector/NET、Connector/ODBC、DSN、主机、端口。

connection pool

一个缓存区域，允许在同一个应用程序或跨多个应用程序中重用数据库 连接，而不是为每个数据库操作设置和拆除新的连接。这项技术在 J2EE 应用服务器中很常见。Java 应用程序使用 Connector/J 可以使用 Tomcat 和其他应用服务器的连接池功能。重用对应用程序是透明的；应用程序仍然像通常那样打开和关闭连接。

另请参阅 连接、Connector/J、J2EE、Tomcat。

connection string

数据库 连接 的参数表示，编码为字符串文字，以便在程序代码中使用。该字符串的各部分表示连接参数，如 主机 和 端口。连接字符串包含多个键值对，以分号分隔。每个键值对用等号连接。常用于 Connector/NET 应用程序；详见 创建 Connector/NET 连接字符串。

另见 连接, Connector/NET, 主机, 端口。

connector

MySQL 连接器为 客户端 程序提供了对 MySQL 服务器的连接性。每种编程语言和框架都有其自己的关联连接器。与使用 API 的低级访问相比。

另见 API, 客户端, Connector/C++, Connector/J, Connector/NET, Connector/ODBC。

Connector/C++

Connector/C++ 8.0 可以用于访问实现文档存储的 MySQL 服务器，也可以使用 SQL 查询在传统方式下使用。它使得使用 X DevAPI 开发 C++ 应用程序或使用 X DevAPI for C 开发普通 C 应用程序成为可能。它还使得使用 Connector/C++ 1.1 的 JDBC-based API 开发 C++ 应用程序成为可能。详见 MySQL Connector/C++ 8.3 开发者指南。

另见 客户端, 连接器, JDBC。

Connector/J

一个 JDBC 驱动程序，为 客户端 应用程序开发在 Java 编程语言中提供连接性。MySQL Connector/J 是一个 JDBC Type 4 驱动程序：一个纯 Java 实现的 MySQL 协议，不依赖于 MySQL 客户端库。详见 MySQL Connector/J 8.1 开发者指南。

另见 客户端, 客户端库, 连接器, Java, JDBC。

Connector/NET

一个 MySQL 连接器，为使用语言、技术和框架如 C#、.NET、Mono、Visual Studio、ASP.net 和 ADO.net 的开发者提供连接性。

另见 ADO.NET, ASP.net, 连接器, C#, Mono, Visual Studio。

Connector/ODBC

MySQL ODBC 驱动程序家族，为使用行业标准开放数据库连接 (ODBC) API 访问 MySQL 数据库提供连接性。以前称为 MyODBC 驱动程序。详见 MySQL Connector/ODBC 开发者指南。

另见 连接器, ODBC。

Connector/PHP

一个版本的 mysql 和 mysqli API，为 PHP 优化，适用于 Windows 操作系统。

查看 连接器、PHP、PHP API。

consistent read

使用快照信息来呈现查询结果的读操作，基于某个时间点，不管其他事务同时运行的更改。如果查询的数据被其他事务更改，原始数据将根据撤销日志的内容重建。这项技术避免了一些可能减少并发性的锁定问题，迫使事务等待其他事务完成。

使用 可重复读 隔离级别，快照基于第一次读操作的时间。使用 已提交读 隔离级别，快照将重置为每个一致读操作的时间。

一致读是 InnoDB 处理 SELECT 语句的默认模式，在 已提交读 和 可重复读 隔离级别中。因为一致读不锁定访问的表，其他会话可以在一致读执行时修改这些表。

有关适用隔离级别的技术细节，请参阅 第 17.7.2.3 节，“一致非锁定读取”。

查看 并发性、隔离级别、锁定、已提交读、可重复读、快照、事务、撤销日志。

constraint

自动测试，可以阻止数据库更改，以防止数据变得不一致。（在计算机科学术语中，关于不变条件的断言。）约束是 ACID 哲学的关键组件，以维护数据一致性。MySQL 支持的约束包括 外键约束 和 唯一约束。

查看 ACID、外键、唯一约束。

counter

特定 InnoDB 操作递增的值。有助于衡量服务器的繁忙程度、排除性能问题的来源，并测试是否对配置设置或查询使用的索引进行了所需的低级别更改。不同的计数器可通过 性能架构 表和 INFORMATION_SCHEMA 表获得，特别是 INFORMATION_SCHEMA.INNODB_METRICS。

查看 INFORMATION_SCHEMA、度量计数器、性能架构。

covering index

包括所有查询检索列的 索引。而不是使用索引值作为指针来找到完整的表行，查询将从索引结构中返回值，节省磁盘 I/O。InnoDB 可以将此优化技术应用于更多的索引，而不是 MyISAM，因为 InnoDB 次要索引 也包括 主键 列。InnoDB 不能将此技术应用于事务修改的表，直到事务结束。

任何 列索引 或 复合索引 都可以作为覆盖索引，给定正确的查询。请设计索引和查询，以便尽可能地利用此优化技术。

查看 列索引、复合索引、索引、主键、次要索引。

CPU-bound

一种类型的 工作负载，其中主要的 瓶颈 是 CPU 操作在内存中。通常涉及读取密集型操作，其中的结果都可以缓存在 缓冲池 中。

另见 瓶颈, 缓冲池, 工作负载。

crash

MySQL 使用术语 “崩溃” 来泛指任何意外的 关闭 操作，其中服务器无法执行正常的清洁工作。例如，崩溃可能是由于数据库服务器机器或存储设备上的硬件故障；电源故障；潜在的数据不匹配导致 MySQL 服务器停止；DBA 发起的 快速关闭 ；或许多其他原因。InnoDB 表的强大、自动 崩溃恢复 确保了在服务器重新启动时数据的一致性，不需要 DBA 进行额外的工作。

另见 崩溃恢复, 快速关闭, InnoDB, 关闭。

crash recovery

MySQL 在崩溃后重新启动时的清洁活动。对于 InnoDB 表，使用 重做日志 中的数据来重放未完成的事务更改。在崩溃前提交但尚未写入 数据文件 的更改，从 双写缓冲区 中重建。

在正常操作期间，已提交的数据可以存储在 更改缓冲区 中一段时间，然后写入数据文件。这之间总是存在一个权衡，即保持数据文件最新，引入了正常操作期间的性能开销，或者缓冲数据，使崩溃恢复时间更长。

另见 更改缓冲区, 提交, 崩溃, 数据文件, 双写缓冲区, InnoDB, 清洁, 重做日志。

CRUD

缩写为““创建、读取、更新、删除””，是数据库应用程序中的一般操作序列。通常表示具有相对简单数据库使用（基本 DDL、DML 和 查询 语句在 SQL 中）的应用程序，可以快速在任何语言中实现。

另见 DDL, DML, 查询, SQL。

cursor

MySQL 的内部数据结构，表示 SQL 语句的结果集。通常与 预备语句 和 动态 SQL 一起使用。它像其他高级语言中的迭代器一样，根据请求产生结果集中的每个值。

尽管 SQL 通常为您处理游标的处理，但是在处理性能关键代码时，您可能需要深入了解其内部工作机制。

另见 动态 SQL, 预备语句, 查询。

D

data definition language

另见 DDL。

data dictionary

跟踪数据库对象的元数据，如 表、 索引 和表 列。对于 MySQL 数据字典，从 MySQL 8.0 开始，元数据物理位于 InnoDB 每表文件 表空间文件中，在 mysql 数据库目录中。对于 InnoDB 数据字典，元数据物理位于 InnoDB 系统表空间 中。

因为 MySQL Enterprise Backup 产品总是备份 InnoDB 系统表空间，因此所有备份都包括 InnoDB 数据字典的内容。

另见 列、 每表文件、 .frm 文件、 索引、 MySQL Enterprise Backup、 系统表空间、 表。

data directory

每个 MySQL 实例 都将 数据文件 保留在 InnoDB 中，并将单个数据库表示为目录。由 datadir 配置选项控制。

另见 数据文件、 实例。

data files

实际包含 表 和 索引 数据的文件。

InnoDB 系统表空间，它持有 InnoDB 数据字典，并且可以容纳多个 InnoDB 表的数据，表示为一个或多个 .ibdata 数据文件。

每表表空间，它们持有单个 InnoDB 表的数据，表示为一个 .ibd 数据文件。

通用表空间（从 MySQL 5.7.6 开始），它们可以容纳多个 InnoDB 表的数据，也表示为一个 .ibd 数据文件。

另见 数据字典、 每表文件、 通用表空间、 .ibd 文件、 ibdata 文件、 索引、 系统表空间、 表、 表空间。

data manipulation language

另见 DML。

data warehouse

主要运行大型 查询 的数据库系统或应用程序。只读或主要读取数据可能以 非规范化 形式组织，以提高查询效率。可以从 MySQL 5.6 及更高版本中的只读事务优化中受益。与 OLTP 相比。

另见 非规范化、 OLTP、 查询、 只读事务。

database

在 MySQL 的 数据目录 中，每个数据库由单独的目录表示。InnoDB 系统表空间，可以存储来自多个数据库的表数据，在 MySQL 实例 中，位于单独的数据文件中。当 每表文件 模式启用时，InnoDB 表的 .ibd 文件 将存储在数据库目录中，除非使用 DATA DIRECTORY 子句创建在其他位置。通用表空间，引入于 MySQL 5.7.6，也将表数据存储在 .ibd 文件 中。与每表文件 .ibd 文件 不同，通用表空间 .ibd 文件 可以存储来自多个数据库的表数据，并可以分配到相对于或独立于 MySQL 数据目录的目录中。

对于长期使用 MySQL 的用户，数据库是一个熟悉的概念。来自 Oracle Database 背景的用户可能会发现 MySQL 中的数据库概念更接近于 Oracle Database 中的 模式。

另见 数据文件、每表文件、.ibd 文件、实例、模式、系统表空间。

DCL

数据控制语言，一组用于管理权限的 SQL 语句。在 MySQL 中，包括 GRANT 和 REVOKE 语句。与 DDL 和 DML 相比。

另见 DDL、DML、SQL。

DDEX provider

允许您使用 Visual Studio 中的数据设计工具来操作 MySQL 数据库中的模式和对象。对于使用 Connector/NET 的 MySQL 应用程序，MySQL Visual Studio 插件充当 MySQL 5.0 及更高版本的 DDEX 提供程序。

另见 Visual Studio。

DDL

数据定义语言，一组用于操作数据库本身而不是单个表行的 SQL 语句。包括所有形式的 CREATE、ALTER 和 DROP 语句。还包括 TRUNCATE 语句，因为它的工作方式不同于 DELETE FROM table_name 语句，尽管最终效果相似。

DDL 语句自动 提交 当前 事务；它们不能被 回滚。

InnoDB 的 在线 DDL 功能提高了 CREATE INDEX、DROP INDEX 和许多类型的 ALTER TABLE 操作的性能。见 第 17.12 节，“InnoDB 和在线 DDL” 了解更多信息。此外，InnoDB 的 file-per-table 设置可以影响 DROP TABLE 和 TRUNCATE TABLE 操作的行为。

与 DML 和 DCL 相比。

另请参阅：提交、DCL、DML、每个表文件、回滚、SQL、事务。

deadlock

在不同的 事务 无法继续进行，因为每个事务都持有锁，另一个事务需要该锁。由于两个事务都在等待资源可用，因此它们都不会释放它们持有的锁。

死锁可能发生在事务锁定多个表中的行（通过语句如 UPDATE 或 SELECT ... FOR UPDATE），但顺序相反。死锁也可能发生在锁定索引记录和 间隙 时，每个事务获取一些锁，但由于计时问题而不获取其他锁。

有关死锁自动检测和处理的背景信息，请参阅 第 17.7.5.2 节，“死锁检测”。有关避免和恢复死锁条件的提示，请参阅 第 17.7.5.3 节，“如何最小化和处理死锁”。

另请参阅：间隙、锁、事务。

deadlock detection

一种机制，自动检测死锁的发生，并自动 回滚 其中一个参与的事务（受害者）。死锁检测可以使用 innodb_deadlock_detect 配置选项禁用。

另请参阅：死锁、回滚、事务、受害者。

delete

当 InnoDB 处理 DELETE 语句时，行将被标记为删除，并且不再被查询返回。存储空间稍后在周期性垃圾回收操作中被回收，称为 清洁 操作。对于删除大量数据，相关操作具有其性能特征的是 TRUNCATE 和 DROP。

另请参阅：DROP、清洁、TRUNCATE。

delete buffering

将 DELETE 操作的更改存储在 更改缓冲区 中，而不是立即写入，以便将物理写入最小化为随机 I/O。（因为删除操作是一个两步过程，这个操作将写入通常标记索引记录以供删除缓冲。）这是 更改缓冲 的一种类型；其他类型是 插入缓冲 和 清洁缓冲。

另请参阅：更改缓冲区、更改缓冲、插入缓冲区、插入缓冲、清洁缓冲。

denormalized

一种数据存储策略，跨多个表复制数据，而不是使用 外键 和 连接 查询。通常用于 数据仓库 应用程序中，其中数据在加载后不再更新。在这些应用程序中，查询性能比维护更新时的一致性更重要。与 标准化 相比。

另请参阅：数据仓库、外键、连接、标准化。

descending index

一种 索引，其中索引存储被优化以处理 ORDER BY 列 DESC 子句。

另见 索引。

dictionary object cache

字典对象缓存将以前访问的 数据字典 对象存储在内存中，以启用对象重用和最小化磁盘 I/O。使用基于 LRU 的驱逐策略来驱逐内存中最近最少使用的对象。缓存由存储不同对象类型的多个分区组成。

有关更多信息，请参阅 第 16.4 节，“字典对象缓存”。

另见 数据字典、 LRU。

dirty page

在 InnoDB 缓冲池 中的一页，该页在内存中已更新，但尚未写入 (刷新) 到 数据文件 中。与 干净页 相反。

另见 缓冲池、 干净页、 数据文件、 刷新、 页。

dirty read

一个操作，检索不可靠的数据，即由另一个事务更新但尚未 提交 的数据。仅在 隔离级别 称为 读未提交 时可能。

这种操作不遵守数据库设计的 ACID 原则。它被认为非常危险，因为数据可能会 回滚，或在提交前进一步更新；然后，执行脏读的事务将使用从未确认的数据。

其对立面是 一致读，其中 InnoDB 确保事务不读取其他事务更新的信息，即使其他事务在此期间提交。

另见 ACID、 提交、 一致读、 隔离级别、 读未提交、 回滚。

disk-based

一种主要在磁盘存储（硬盘或等效）上组织数据的数据库。数据在磁盘和内存之间来回传输以进行操作。它是 内存数据库 的对立面。虽然 InnoDB 是基于磁盘的，但它也包含了诸如 缓冲池、多个缓冲池实例和 自适应哈希索引 等功能，这些功能使某些工作负载可以主要从内存中工作。

另见 自适应哈希索引、 缓冲池、 内存数据库。

disk-bound

一种 工作负载，其中主要的 瓶颈 是磁盘 I/O。（也称为 I/O 绑定。）通常涉及频繁的磁盘写入或超出 缓冲池 容量的随机读取。

另见 瓶颈、 缓冲池、 工作负载。

DML

数据操作语言，一组 SQL 语句，用于执行 INSERT、UPDATE 和 DELETE 操作。 SELECT 语句有时被认为是 DML 语句，因为 SELECT ... FOR UPDATE 形式受到与 INSERT、UPDATE 和 DELETE 相同的锁定考虑。

DML 语句对于 InnoDB 表操作在事务的上下文中，因此它们的效果可以作为单个单位提交或回滚。

与 DDL 和 DCL 相比。

另见 提交、DCL、DDL、锁定、回滚、SQL、事务。

document id

在 InnoDB 全文搜索功能中，表中的特殊列，包含 FULLTEXT 索引，以唯一标识每个 ilist 值关联的文档。其名称是 FTS_DOC_ID（大写必需）。该列必须是 BIGINT UNSIGNED NOT NULL 类型，具有唯一索引 FTS_DOC_ID_INDEX。最好是在创建表时定义该列。如果 InnoDB 必须在创建 FULLTEXT 索引时将该列添加到表中，则索引操作将变得非常昂贵。

另见 全文搜索、FULLTEXT 索引、ilist。

doublewrite buffer

InnoDB 使用一种称为双写的文件刷新技术。在将 页 写入 数据文件 之前，InnoDB 首先将其写入一个名为双写缓冲区的存储区域。只有在写入和刷新双写缓冲区完成后，InnoDB 才将页写入其在数据文件中的适当位置。如果在写入页期间操作系统、存储子系统或 mysqld 进程崩溃，InnoDB 可以在崩溃恢复期间从双写缓冲区中找到页的良好副本。

尽管数据总是写入两次，但双写缓冲区并不需要两倍的 I/O 开销或两倍的 I/O 操作。数据被写入缓冲区本身作为一个大型顺序块，以单个 fsync() 调用操作系统。

另见 崩溃恢复、数据文件、页、purge。

drop

一种 DDL 操作，通过语句如 DROP TABLE 或 DROP INDEX 删除模式对象。它在内部映射到 ALTER TABLE 语句。从 InnoDB 的角度来看，这类操作的性能考虑涉及到锁定 数据字典 的时间，以确保相关对象都被更新，以及更新内存结构如 缓冲池 的时间。对于 表，删除操作的特征与 截断 操作 (TRUNCATE TABLE 语句) 略有不同。

另见 缓冲池, 数据字典, DDL, 表, 截断。

DSN

“数据库源名称”的缩写。它是 连接 信息在 Connector/ODBC 中的编码。请参阅 在 Windows 上配置 Connector/ODBC DSN 以获取详细信息。这相当于 连接字符串 用于 Connector/NET。

另见 连接, 连接字符串, Connector/NET, Connector/ODBC。

dynamic cursor

一种 光标 类型，支持 ODBC，可以在读取行时获取新的和更改的结果。这些更改何时可见于光标取决于表类型（事务或非事务）和事务表的隔离级别。动态光标支持必须被明确启用。

另见 光标, ODBC。

dynamic row format

一种 InnoDB 行格式。由于长变长列值存储在行数据所在的页面之外，因此对于包含大对象的行非常高效。由于大字段通常不被访问以评估查询条件，因此它们不太可能被带入 缓冲池，从而减少 I/O 操作和缓存内存的利用率。

从 MySQL 5.7.9 开始，默认行格式由 innodb_default_row_format 定义，默认值为 DYNAMIC。

有关 InnoDB DYNAMIC 行格式的更多信息，请参阅 DYNAMIC 行格式。

另见 缓冲池, 文件格式, 行格式。

dynamic SQL

允许您使用更健壮、安全和高效的方法创建和执行 预备语句，以代替简单地将语句部分连接到字符串变量中。

另见 预备语句。

dynamic statement

通过 动态 SQL 创建和执行的 预备语句。

另见 动态 SQL, 预备语句。

E

early adopter

软件产品测试阶段，类似于 beta 阶段，在非关键任务设置中评估性能、功能和兼容性。

另见 beta。

Eiffel

一个包含许多面向对象特性的编程语言。一些概念熟悉于 Java 和 C# 开发者。对于开源 Eiffel API for MySQL，请参阅 第 31.13 节，“MySQL Eiffel Wrapper”。

另见 API, C#, Java。

embedded

嵌入式 MySQL 服务器库 (libmysqld) 使得可以在客户端应用程序中运行完整的 MySQL 服务器。主要优点是增加速度和更简单的管理嵌入式应用程序。

另见 客户端, libmysqld。

error log

一种类型的 日志，显示 MySQL 启动和关键运行时错误以及 崩溃 信息。详细信息，请参阅 第 7.4.2 节，“错误日志”。

另见 崩溃, 日志。

eviction

从缓存或其他临时存储区域中删除项目的过程，例如 InnoDB 缓冲池。通常，但不总是，使用 LRU 算法来确定要删除的项目。当 脏页 被驱逐时，其内容将被 刷新 到磁盘，任何脏 邻近页 也可能被刷新。

另见 缓冲池, 脏页, 刷新, LRU, 邻近页。

exception interceptor

一种类型的 拦截器，用于跟踪、调试或增强数据库应用程序遇到的 SQL 错误。例如，拦截器代码可能会发出 SHOW WARNINGS 语句以检索附加信息，并添加描述性文本或甚至更改返回给应用程序的异常类型。因为拦截器代码仅在 SQL 语句返回错误时被调用，因此它不会对应用程序的正常（错误免费）操作产生任何性能损失。

在使用 Java 的应用程序中，设置这种类型的拦截器涉及实现 com.mysql.jdbc.ExceptionInterceptor 接口，并将 exceptionInterceptors 属性添加到 连接字符串 中。

在使用 Visual Studio 的应用程序中，设置这种类型的拦截器涉及定义继承自 BaseExceptionInterceptor 类的类，并将该类名称指定为连接字符串的一部分。

另见 Connector/J, Connector/NET, 拦截器, Java, Visual Studio。

exclusive lock

一种类型的 锁，防止其他 事务 锁定同一行。根据事务 隔离级别，这种锁可能阻止其他事务写入同一行，或者也可能阻止其他事务读取同一行。默认的 InnoDB 隔离级别 可重复读，通过允许事务读取具有排他锁的行来提高并发性，这种技术称为 一致读取。

查看 并发、 一致读取、 隔离级别、 锁、 可重复读取、 共享锁、 事务。

extent

在 表空间 中的一组 页。对于默认的 16KB 页大小，一个 extent 包含 64 页。在 MySQL 5.6 中，InnoDB 实例的页大小可以是 4KB、8KB 或 16KB，由 innodb_page_size 配置选项控制。对于 4KB、8KB 和 16KB 页大小，extent 大小始终是 1MB（或 1048576 字节）。

从 MySQL 5.7.6 开始，添加了对 32KB 和 64KB InnoDB 页大小的支持。对于 32KB 页大小，extent 大小是 2MB。对于 64KB 页大小，extent 大小是 4MB。

InnoDB 特性，如 段、预读 请求和 双写缓冲区，使用 I/O 操作来读取、写入、分配或释放数据，一次一个 extent。

查看 双写缓冲区、 页、 页大小、 预读、 段、 表空间。

F

.frm file

一个包含 MySQL 表元数据，如表定义的文件。.frm 文件在 MySQL 8.0 中被删除，但是在早期 MySQL 版本中仍然使用。在 MySQL 8.0 中，之前存储在 .frm 文件中的数据现在存储在 数据词典 表中。

查看 数据词典、 MySQL Enterprise Backup、 系统表空间。

failover

在故障事件中自动切换到备用服务器的能力。在 MySQL 上下文中，failover 涉及备用数据库服务器。通常在 J2EE 环境中由应用程序服务器或框架支持。

查看 Connector/J、 J2EE。

Fast Index Creation

InnoDB 插件中引入的一项功能，现在是 MySQL 5.5 及更高版本的一部分，该功能可以加速创建 InnoDB 次要索引，避免了完全重写关联表的需要。该加速也适用于删除次要索引。

由于索引维护可能会增加数据传输操作的性能开销，因此考虑在没有次要索引的情况下执行操作，如 ALTER TABLE ... ENGINE=INNODB 或 INSERT INTO ... SELECT * FROM ...，然后创建索引。

在 MySQL 5.6 中，该功能变得更加通用。您可以在创建索引时读取和写入表，而许多其他类型的 ALTER TABLE 操作可以在不复制表、不阻塞 DML 操作或同时执行的情况下执行。因此，在 MySQL 5.6 及更高版本中，该功能集被称为 在线 DDL 而不是快速索引创建。

有关信息，请参阅 第 17.12 节，“InnoDB 和在线 DDL”。

查看 DML、 索引、 在线 DDL、 次要索引。

fast shutdown

默认的 shutdown 程序为 InnoDB，基于配置设置 innodb_fast_shutdown=1。为了节省时间，一些 flush 操作被跳过。这种shutdown 在正常使用中是安全的，因为 flush 操作将在下一次启动时执行，使用与 崩溃恢复 相同的机制。在数据库关闭以升级或降级时，请执行 慢速shutdown，以确保所有相关更改都应用于 数据文件 中。

另见 崩溃恢复、数据文件、flush、shutdown、慢速shutdown。

file format

InnoDB 表的文件格式。

另见 每个表文件、.ibd 文件、ibdata 文件、行格式。

file-per-table

通用名称为由 innodb_file_per_table 选项控制的设置，该选项对 InnoDB 文件存储、功能可用性和 I/O 特性产生重要影响。从 MySQL 5.6.7 开始，innodb_file_per_table 默认启用。

启用 innodb_file_per_table 选项后，可以在自己的 .ibd 文件 中创建表，而不是在 系统表空间 的共享 ibdata 文件 中。当表数据存储在单个 .ibd 文件 中时，您可以选择 行格式，以便使用功能，如数据 压缩。 TRUNCATE TABLE 操作也更快，释放的空间可以被操作系统使用，而不是保留给 InnoDB。

MySQL Enterprise Backup 产品对于在单个文件中的表更加灵活。例如，表可以从备份中排除，但只有在单个文件中时才可以这样做。因此，该设置适合不太频繁备份或在不同的备份计划中的表。

另见 压缩行格式、压缩、文件格式、.ibd 文件、ibdata 文件、innodb_file_per_table、MySQL Enterprise Backup、行格式、系统表空间。

fill factor

在 InnoDB 索引 中，页面中索引数据所占的比例，在页面被分割之前。未使用的空间当索引数据首次被分配到页面时，允许行被更新为更长的字符串值，而不需要昂贵的索引维护操作。如果填充因子太低，索引将消耗更多的空间，导致额外的 I/O 开销来读取索引。如果填充因子太高，任何更新列值的长度的操作都将导致额外的 I/O 开销来维护索引。另见 第 17.6.2.2 节，“InnoDB 索引的物理结构”。

另见 索引、页面。

fixed row format

这种行格式由 MyISAM 存储引擎使用，而不是 InnoDB。如果您在 MySQL 5.7.6 或更早版本中创建了一个 InnoDB 表，并指定了选项 ROW_FORMAT=FIXED，那么 InnoDB 将使用 紧凑行格式，尽管 FIXED 值可能仍然出现在输出中，例如 SHOW TABLE STATUS 报告中。从 MySQL 5.7.7 开始，InnoDB 将返回错误，如果指定了 ROW_FORMAT=FIXED。

另见 紧凑行格式，行格式。

flush

将更改写入数据库文件，这些更改曾经缓存在内存区域或临时磁盘存储区域中。InnoDB 存储结构周期性地刷新包括 重做日志、撤销日志 和 缓冲池。

刷新可能是因为内存区域变满，系统需要释放一些空间，因为 提交 操作意味着事务的更改可以被最终确定，或者因为 慢关闭 操作意味着所有未完成的工作都应该被最终确定。InnoDB 可以使用称为 模糊检查点 的技术来刷新小批量的页面，以分散 I/O 开销。

另见 缓冲池，提交，模糊检查点，重做日志，慢关闭，撤销日志。

flush list

一个内部 InnoDB 数据结构，用于跟踪 脏页 在 缓冲池 中：即，页 已经被更改并需要被写回磁盘。这个数据结构由 InnoDB 内部 迷你事务 频繁更新，并因此受到其自己的 互斥锁 保护，以允许对缓冲池的并发访问。

另见 缓冲池，脏页，LRU，迷你事务，互斥锁，页，页清洁器。

foreign key

一个指针关系类型，存在于两个单独的 InnoDB 表之间。外键关系定义在父表和子表的某一列上。

除了启用快速查找相关信息外，外键还帮助实施 参照完整性，防止这些指针在数据插入、更新和删除时变得无效。如果一个行指向另一个表，但关联的外键值不存在于另一个表中，外键将阻止插入。如果一个行被删除或其外键值被更改，而其他表中的行指向该外键值，外键可以设置为防止删除，或者将对应的列值设置为 空，或者自动删除对应的行。

设计一个 规范化 数据库的阶段之一是识别重复的数据，将其分离到一个新表中，并设置外键关系，以便可以使用 连接 操作来查询多个表，如同一个表。

另见 子表，外键约束，连接，规范化，空，父表，参照完整性，关系。

FOREIGN KEY constraint

类型的 约束，通过 外键 关系维护数据库的一致性。像其他类型的约束一样，它可以防止数据被插入或更新，以免数据变得不一致；在这种情况下，防止的不一致是多个表之间的不一致。另外，当执行 DML 操作时，FOREIGN KEY 约束可以导致 子行 中的数据被删除、更改为不同的值或设置为 空，基于创建外键时指定的 ON CASCADE 选项。

另见 子表、约束、DML、外键、空。

FTS

在大多数情况下，全文搜索 的缩写。有时在性能讨论中，全表扫描 的缩写。

另见 全表扫描、全文搜索。

full backup

包括每个 MySQL 数据库 中所有 表 的备份，以及所有数据库在 MySQL 实例 中的备份。与 部分备份 相比。

另见 备份、数据库、实例、部分备份、表。

full table scan

需要读取整个表的内容，而不是使用 索引 仅读取选定的部分。通常在小型查找表或数据仓库情况下使用大量表时执行，所有可用的数据都被聚合和分析。这些操作的频率和表的大小相对于可用内存的影响，对查询优化算法和管理 缓冲池 的影响。

索引的目的是允许在大型表中查找特定值或值范围，从而避免全表扫描。

另见 缓冲池、索引。

full-text search

MySQL 的功能，用于在表数据中查找单词、短语、布尔组合等，以一种更快、更方便、更灵活的方式，而不是使用 SQL LIKE 运算符或编写自己的应用程序级搜索算法。它使用 SQL 函数 MATCH() 和 FULLTEXT 索引。

另见 FULLTEXT 索引。

FULLTEXT index

特殊类型的 索引，用于存储 MySQL 全文搜索 机制中的 搜索索引。表示列值中的单词，忽略指定的 停用词。最初仅适用于 MyISAM 表。从 MySQL 5.6.4 开始，也适用于 InnoDB 表。

另见 全文搜索、索引、InnoDB、搜索索引、停用词。

fuzzy checkpointing

一种技术，用于从 缓冲池 中刷新小批量的 脏页，而不是刷新所有脏页，以免干扰数据库处理。

另见 缓冲池、脏页、刷新。

G

GA

“一般可用”，软件产品离开 测试版 并可用于销售、官方支持和生产使用。

另见 测试版。

GAC

“全球程序集缓存” 的缩写。是一个中央存储库（程序集）在 .NET 系统中。物理上由嵌套文件夹组成，.NET CLR 将其视为单个虚拟文件夹。

另见 .NET，程序集。

gap

在 InnoDB 索引 数据结构中，新值可以插入的地方。当您使用语句如 SELECT ... FOR UPDATE 锁定一组行时，InnoDB 可以创建锁，应用于索引中的间隙以及实际值。例如，如果您选择所有大于 10 的值进行更新，间隙锁将阻止另一个事务插入大于 10 的新值。最高记录 和 最低记录 代表索引中的所有值大于或小于当前索引值。

另见 并发，间隙锁，索引，最低记录，隔离级别，最高记录。

gap lock

在索引记录之间的 间隙 上的锁，或者在索引记录之前或之后的锁。例如，SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE; 防止其他事务将值 15 插入列 t.c1，无论该列中是否已经存在该值，因为该范围内的所有间隙都被锁定。与 记录锁 和 next-key 锁 相比。

间隙锁是性能和 并发 之间的权衡，并且在某些事务 隔离级别 中使用，而在其他级别中不使用。

另见 间隙，最低记录，锁，next-key 锁，记录锁，最高记录。

general log

另见 通用查询日志。

general query log

一种用于诊断和故障排除的 MySQL 服务器处理的 SQL 语句的 日志。可以存储在文件中或数据库表中。您必须通过 general_log 配置选项启用此功能，以便使用它。您可以通过 sql_log_off 配置选项禁用特定连接的日志记录。

记录了比 慢查询日志 更广泛的查询范围。与 二进制日志 不同，该日志包含 SELECT 语句，不维护严格的顺序。有关更多信息，请参阅 第 7.4.3 节，“通用查询日志”。

另见 二进制日志，日志，慢查询日志。

general tablespace

使用 CREATE TABLESPACE 语法创建的共享 InnoDB 表空间。通用表空间可以在 MySQL 数据目录外创建，能够容纳多个 表，并支持所有行格式的表。通用表空间是在 MySQL 5.7.6 中引入的。

表添加到通用表空间使用CREATE TABLE tbl_name ... TABLESPACE [=] tablespace_name或ALTER TABLE tbl_name TABLESPACE [=] tablespace_name语法。

与系统表空间和每个表文件表空间相比。

更多信息，请参见第17.6.3.3节，“通用表空间”。

另见每个表文件、系统表空间、表、表空间。

generated column

一列whose值来自表达式，包括在列定义中。生成的列可以是虚拟或存储。

另见基准列、存储生成列、虚拟生成列。

generated stored column

另见存储生成列。

generated virtual column

另见虚拟生成列。

Glassfish

另见J2EE。

global temporary tablespace

一个临时表空间，用于存储用户创建的临时表的回滚段。

另见临时表空间。

global transaction

一种事务，涉及到XA操作。它由多个事务组成，每个事务都必须成功完成，否则所有事务都将回滚。在本质上，这扩展了ACID属性，使多个ACID事务可以作为一个全球操作的一部分执行。

另见ACID、事务、XA。

group commit

一个InnoDB优化，执行一些低级I/O操作（日志写入）一次，对于一组提交操作，而不是为每个提交单独刷新和同步。

另见二进制日志、提交。

GUID

缩写为“全球唯一标识符”，一个ID值，可以跨不同的数据库、语言、操作系统等关联数据。（作为使用顺序整数的替代方案，其中相同的值可能出现在不同的表、数据库等中，指向不同的数据。）旧版本的MySQL将其表示为BINARY(16)。目前，它被表示为CHAR(36)。MySQL有一个UUID()函数，返回字符格式的GUID值，还有一个UUID_SHORT()函数，返回整数格式的GUID值。由于连续的GUID值不一定按升序排列，因此它不是大型InnoDB表的主键的高效选择。

H

hash index

一种索引，旨在用于使用相等操作符的查询，而不是范围操作符，如大于或BETWEEN。它适用于MEMORY表。虽然散列索引是MEMORY表的默认索引，但该存储引擎也支持B树索引，对于通用查询通常是一个更好的选择。

MySQL 包括一种变体的索引类型，即 自适应哈希索引，该索引根据运行时条件自动构建在 InnoDB 表中。

另见 自适应哈希索引, B 树, 索引, InnoDB。

HDD

“硬盘驱动器”的缩写。指的是使用旋转盘的存储介质，通常是在与 SSD 进行比较和对比时使用。其性能特征可以影响基于磁盘的工作负载的吞吐量。

另见 基于磁盘, SSD。

heartbeat

定期发送的消息，以表明系统正常运行。在 复制 上下文中，如果 源 停止发送这些消息，则其中一个 副本 可以取代它。类似的技术可以在集群环境中的服务器之间使用，以确认所有服务器都在正常运行。

另见 复制, 源。

high-water mark

一个表示上限的值，或者是一个记录的最大值，或者是一个记录的实际达到值。与 低水位标记 相比。

另见 低水位标记。

history list

一个 事务 列表，其中包含标记为删除的记录，计划由 InnoDB 清除 操作处理。记录在 撤销日志 中。历史列表的长度由命令 SHOW ENGINE INNODB STATUS 报告。如果历史列表的长度超过了 innodb_max_purge_lag 配置选项的值，每个 DML 操作将被延迟，以允许清除操作完成 刷新 删除的记录。

也称为 清除延迟。

另见 DML, 刷新, 清除, 清除延迟, 回滚段, 事务, 撤销日志。

hole punching

从页面释放空块。 InnoDB 透明页压缩 功能依赖于洞 punching 支持。有关更多信息，请参阅 第 17.9.2 节，“InnoDB 页压缩”。

另见 稀疏文件, 透明页压缩。

host

数据库服务器的网络名称，用于建立 连接。通常与 端口 一起指定。在某些情况下，IP 地址 127.0.0.1 比特殊名称 localhost 更适合访问同一服务器上的数据库。

另见 连接, localhost, 端口。

hot

一种情况，其中行、表或内部数据结构被访问得如此频繁，以至于需要某种形式的锁定或互斥，导致性能或可扩展性问题。

尽管 ““热”” 通常表示不良的条件，但 热备份 是首选的备份类型。

另见 热备份。

hot backup

在数据库运行并且应用程序正在读取和写入时采取的备份。备份不仅仅是复制数据文件：它必须包括在备份过程中插入或更新的数据；它必须排除在备份过程中删除的数据；并且它必须忽略未提交的更改。

执行热备份的Oracle产品，特别是对InnoDB表，但也包括来自MyISAM和其他存储引擎的表，称为MySQL Enterprise Backup。

热备份过程分两个阶段。初始数据文件的复制产生一个原始备份。应用更改的步骤将数据库在备份过程中发生的更改应用于备份中。应用更改后产生了一个准备备份；这些文件随时可以恢复。

另见 应用, MySQL Enterprise Backup, 准备备份, 原始备份。

I

.ibd file

文件-per-table 表空间和通用表空间的数据文件。.ibd 文件包含单个表和关联索引数据。通用表空间 .ibd 文件可能包含多个表和索引数据。

文件扩展名 .ibd 不适用于 系统表空间，它由一个或多个 ibdata 文件 组成。

如果文件-per-table 表空间或通用表空间是在 DATA DIRECTORY = 子句中创建的，则 .ibd 文件位于指定的路径中，位于正常数据目录之外。

当 .ibd 文件被 MySQL Enterprise Backup 产品包含在压缩备份中时，压缩后的等效文件是一个 .ibz 文件。

另见 数据库, 文件-per-table, 通用表空间, ibdata 文件, .ibz 文件, innodb_file_per_table, MySQL Enterprise Backup, 系统表空间。

.ibz file

当 MySQL Enterprise Backup 产品执行 压缩备份 时，它将每个使用 文件-per-table 设置创建的表空间文件从 .ibd 扩展名更改为 .ibz 扩展名。

备份期间的压缩与正常操作期间的 压缩行格式 不同。压缩备份操作跳过了已经在压缩行格式下的表空间的压缩步骤，因为第二次压缩将减慢备份速度，但几乎不节省空间。

另见 压缩备份, 压缩行格式, 文件-per-table, .ibd 文件, MySQL Enterprise Backup, 表空间。

I/O-bound

另见 磁盘绑定。

ib-file set

由 InnoDB 在 MySQL 数据库中管理的一组文件：系统表空间、文件-per-table 表空间文件和 重做日志 文件。根据 MySQL 版本和 InnoDB 配置，可能还包括 通用表空间、临时表空间 和 撤销表空间 文件。这个术语有时用于详细讨论 InnoDB 文件结构和格式时，指的是 InnoDB 在 MySQL 数据库中管理的一组文件。

另请参阅 数据库、每表文件、通用表空间、重做日志、系统表空间、临时表空间、撤销表空间。

ibbackup_logfile

由 MySQL Enterprise Backup 产品在热备份操作期间创建的补充备份文件。它包含备份过程中发生的数据更改信息。初始备份文件，包括 ibbackup_logfile，称为原始备份，因为备份操作期间的更改尚未合并。执行 apply 步骤后，原始备份文件将包含最终的数据更改，并称为准备备份。在这个阶段，ibbackup_logfile 文件不再需要。

另请参阅 应用、热备份、MySQL Enterprise Backup、准备备份、原始备份。

ibdata file

一个名为 ibdata1、ibdata2 等的文件集，组成 InnoDB 系统表空间。有关系统表空间 ibdata 文件中的结构和数据的信息，请参阅 第 17.6.3.1 节，“系统表空间”。

ibdata 文件的增长受到 innodb_autoextend_increment 配置选项的影响。

另请参阅 更改缓冲区、数据字典、双写缓冲区、每表文件、.ibd 文件、InnoDB 每表文件、系统表空间、撤销日志。

ibtmp file

InnoDB 临时表空间 数据文件，用于非压缩 InnoDB 临时表和相关对象。配置文件选项 innodb_temp_data_file_path 允许用户定义临时表空间数据文件的相对路径。如果未指定 innodb_temp_data_file_path，则默认行为是创建一个名为 ibtmp1 的自动扩展 12MB 数据文件在数据目录中，旁边是 ibdata1。

另请参阅 数据文件、临时表、临时表空间。

ib_logfile

一个名为 ib_logfile0 和 ib_logfile1 的文件集，组成 重做日志。也称为 日志组。这些文件记录尝试更改 InnoDB 表数据的语句。这些语句将在启动后自动重放，以纠正崩溃后的数据。

这些数据不能用于手动恢复；对于那种操作，请使用 二进制日志。

另请参阅 二进制日志、日志组、重做日志。

ilist

在 InnoDB 全文索引 中，数据结构由文档 ID 和令牌（即特定单词）的位置信息组成。

另见 全文索引。

implicit row lock

InnoDB 获取的行锁，以确保一致性，而不需要您明确请求。

另见 行锁。

in-memory database

一种数据库系统，维护内存中的数据，以避免磁盘 I/O 和磁盘块与内存区域之间的转换的一些开销。一些内存数据库牺牲了持久性（ACID 设计哲学中的“D”），并且容易受到硬件、电源和其他类型的故障的影响，使它们更适合只读操作。其他内存数据库使用持久性机制，如将更改日志记录到磁盘或使用非易失性内存。

MySQL 的一些功能解决了同样的内存密集型处理，包括 InnoDB 缓冲池、自适应哈希索引 和 只读事务 优化、MEMORY 存储引擎、MyISAM 键缓存和 MySQL 查询缓存。

另见 ACID、自适应哈希索引、缓冲池、基于磁盘、只读事务。

incremental backup

一种 热备份，由 MySQL 企业备份 产品执行，仅保存自某个时间点以来更改的数据。拥有完整备份和一系列增量备份可以在长期内重建备份数据，而不需要存储多个完整备份的开销。您可以恢复完整备份，然后依次应用每个增量备份，或者保持完整备份最新，并应用每个增量备份，然后执行单个恢复操作。

更改数据的粒度在 页 级别。一页可能实际上涵盖多行。每个更改的页都包含在备份中。

另见 热备份、MySQL 企业备份、页。

index

提供快速查找 行 的数据结构，通常通过形成树结构（B 树）来表示特定 列 或列集的所有值。

InnoDB 表总是具有一个 聚簇索引，表示 主键。它们也可以具有一个或多个 次要索引，定义在一个或多个列上。根据结构，次要索引可以分类为 部分、列 或 复合 索引。

索引是 查询 性能的关键方面。数据库架构师设计表、查询和索引，以便快速查找应用程序所需的数据。理想的数据库设计使用 覆盖索引，其中查询结果完全来自索引，而不需要读取实际表数据。每个 外键 约束也需要一个索引，以便高效地检查父表和子表中的值是否存在。

尽管 B 树索引是最常见的，但 哈希索引 使用不同的数据结构，如 MEMORY 存储引擎和 InnoDB 自适应哈希索引。R 树 索引用于多维空间索引。

查看 自适应哈希索引、 B 树、 子表、 聚簇索引、 列索引、 复合索引、 覆盖索引、 外键、 哈希索引、 父表、 部分索引、 主键、 查询、 R 树、 行、 次要索引、 表。

index cache

一个内存区域，用于存储 InnoDB 全文搜索 的令牌数据。它缓冲数据，以最小化磁盘 I/O，当数据被插入或更新到 FULLTEXT 索引的列中时。令牌数据将被写入磁盘，当索引缓存变满时。每个 InnoDB FULLTEXT 索引都有其自己的独立索引缓存，其大小由配置选项 innodb_ft_cache_size 控制。

查看 全文搜索、 FULLTEXT 索引。

index condition pushdown

索引条件下推（ICP）是一种优化，推送部分 WHERE 条件到存储引擎，如果条件的一部分可以使用索引中的字段来评估。ICP 可以减少存储引擎必须访问基本表的次数，以及 MySQL 服务器必须访问存储引擎的次数。有关更多信息，请参阅 第 10.2.1.6 节，“索引条件下推优化”。

查看 索引、 存储引擎。

index hint

扩展 SQL 语法，用于覆盖优化器推荐的 索引。例如，FORCE INDEX、USE INDEX 和 IGNORE INDEX 子句。通常用于索引列具有不均匀分布的值，从而导致不准确的 基数 估计。

查看 基数、 索引。

index prefix

在一个 索引 中应用于多个列（称为 复合索引），的初始或leading 列。查询引用复合索引的第 1、2、3 等列时，即使查询不引用索引的所有列，也可以使用索引。

查看 复合索引、 索引。

index statistics

查看 统计信息。

infimum record

一个 伪记录 在一个 索引 中，表示该索引中的 间隙。如果事务具有语句，如 SELECT ... FROM ... WHERE col < 10 FOR UPDATE;，且该列的最小值为 5，则锁定该伪记录，以防止其他事务插入更小的值，如 0、-10 等。

查看 间隙、 索引、 伪记录、 上限记录。

INFORMATION_SCHEMA

数据库的名称，它提供了对 MySQL 数据字典的查询接口。（该名称由 ANSI SQL 标准定义。）要检查数据库的信息（元数据），可以查询表格，如 INFORMATION_SCHEMA.TABLES 和 INFORMATION_SCHEMA.COLUMNS，而不是使用 SHOW 命令生成非结构化输出。

该 INFORMATION_SCHEMA 数据库还包含特定于 InnoDB 的表格，提供了对 InnoDB 数据字典的查询接口。您使用这些表格不仅是为了查看数据库的结构，还可以获取 InnoDB 表格的实时信息，以帮助性能监控、调整和故障排除。

另见 数据字典, 数据库, InnoDB。

InnoDB

一个 MySQL 组件，它将高性能与 事务 能力结合，以提供可靠性、robustness 和并发访问。它体现了 ACID 设计哲学。它作为一个 存储引擎，处理使用 ENGINE=INNODB 子句创建或修改的表格。请参阅 第 17 章，InnoDB 存储引擎 以获取架构细节和管理过程，以及 第 10.5 节，“优化 InnoDB 表” 以获取性能建议。

在 MySQL 5.5 及更高版本中，InnoDB 是新表格的默认存储引擎，不需要 ENGINE=INNODB 子句。

InnoDB 表格非常适合 热备份。请参阅 第 32.1 节，“MySQL 企业备份概述” 以获取关于 MySQL 企业备份 产品的信息，该产品可以在不中断正常处理的情况下备份 MySQL 服务器。

另见 ACID, 热备份, MySQL 企业备份, 存储引擎, 事务。

innodb_autoinc_lock_mode

选项 innodb_autoinc_lock_mode 控制用于 自动递增锁定 的算法。当您拥有自动递增的 主键 时，可以使用基于语句的复制仅与设置 innodb_autoinc_lock_mode=1。该设置称为 连续 锁定模式，因为事务中的多行插入将收到连续的自动递增值。如果您有 innodb_autoinc_lock_mode=2，则允许插入操作的更高并发性，使用基于行的复制而不是基于语句的复制。该设置称为 交叉 锁定模式，因为多个多行插入语句在同一时间运行时可以收到交叉的自动递增值。设置 innodb_autoinc_lock_mode=0 仅用于兼容性目的。

连续锁定模式 (innodb_autoinc_lock_mode=1) 是 MySQL 8.0.3 之前的默认设置。从 MySQL 8.0.3 开始，交叉锁定模式 (innodb_autoinc_lock_mode=2) 是默认设置，这反映了从基于语句的复制到基于行的复制的默认复制类型的变化。

另见 自动递增, 自动递增锁定, 混合模式插入, 主键。

innodb_file_per_table

一个重要的配置选项，它影响了许多方面的 InnoDB 文件存储、可用性和 I/O 特性。在 MySQL 5.6.7 及更高版本中，默认启用该选项。innodb_file_per_table 选项启用了 每表文件 模式。在该模式下，新创建的 InnoDB 表和关联索引可以存储在单独的文件中，位于 系统表空间 之外。

该选项影响了多个 SQL 语句的性能和存储考虑，例如 DROP TABLE 和 TRUNCATE TABLE。

启用 innodb_file_per_table 选项允许您利用诸如表 压缩 和命名表备份在 MySQL 企业备份 中的功能。

有关更多信息，请参阅 innodb_file_per_table，和 第 17.6.3.2 节，“每表文件表空间”。

另请参阅 压缩, 每表文件, .ibd 文件, MySQL 企业备份, 系统表空间。

innodb_lock_wait_timeout

innodb_lock_wait_timeout 选项设置了等待共享资源可用或处理错误、重试或在应用程序中执行替代处理的平衡。回滚任何等待超过指定时间以获取锁定的 InnoDB 事务。特别有用的是，如果 死锁 由多个表的更新引起，这些死锁不会被自动检测到。

另请参阅 死锁, 死锁检测, 锁, 等待。

innodb_strict_mode

innodb_strict_mode 选项控制 InnoDB 是否在 严格模式 下运作，在该模式下，通常被视为警告的条件将导致错误（并且基础语句将失败）。

另请参阅 严格模式。

insert

在 SQL 中的一种主要 DML 操作。插入性能对于加载数百万行到表中的 数据仓库 系统和多个并发连接可能插入行到同一表中的 OLTP 系统非常重要。如果插入性能对您很重要，您应该了解 InnoDB 的功能，例如用于 更改缓冲 的 插入缓冲 和 自动递增 列。

另请参阅 自动递增, 更改缓冲, 数据仓库, DML, InnoDB, 插入缓冲, OLTP, SQL。

insert buffer

之前的名称是 更改缓冲区。在 MySQL 5.5 中，添加了对次要索引页的更改缓冲区支持，以便在 DELETE 和 UPDATE 操作中缓冲更改。以前，只有来自 INSERT 操作的更改被缓冲。现在，首选术语是 更改缓冲区。

另见 更改缓冲区，更改缓冲。

insert buffering

将次要索引页的更改存储在 更改缓冲区 中，而不是立即写入，以便将物理写入最小化随机 I/O。这是一种 更改缓冲 类型；其他类型包括 删除缓冲 和 清除缓冲。

如果次要索引是 唯一的，则不使用插入缓冲，因为无法在写入新条目之前验证新值的唯一性。其他类型的更改缓冲对唯一索引有效。

另见 更改缓冲区，更改缓冲，删除缓冲，插入缓冲区，清除缓冲，唯一索引。

insert intention lock

一种 间隙锁 类型，由 INSERT 操作在插入行之前设置。这种锁类型表明了插入意图，以便在同一个间隙中插入的多个事务不需要等待对方，如果它们不是在同一个位置插入。有关更多信息，请参阅 第 17.7.1 节，“InnoDB 锁定”。

另见 间隙锁，锁，下一个键锁。

instance

一个 mysqld 守护进程管理着一个 数据目录，该目录代表一个或多个 数据库，其中包含一组 表。在开发、测试和某些 复制 场景中，通常在同一台 服务器 机器上运行多个实例，每个实例管理其自己的数据目录并监听其自己的端口或套接字。使用一个实例运行磁盘绑定的工作负载时，服务器可能仍然有额外的 CPU 和内存容量来运行其他实例。

另见 数据目录，数据库，磁盘绑定，mysqld，复制，服务器，表。

instrumentation

在源代码级别对性能数据进行修改，以便进行调整和调试。在 MySQL 中，通过 INFORMATION_SCHEMA 和 PERFORMANCE_SCHEMA 数据库，instrumentation 收集的数据通过 SQL 接口公开。

另见 INFORMATION_SCHEMA，性能模式。

intention exclusive lock

另见 意图锁。

intention lock

一种应用于表的锁，用于指示事务对表中的行将获取的锁类型。不同的事务可以在同一个表上获取不同的意图锁，但第一个获取排他意图锁（IX）的事务将阻止其他事务在该表上获取任何共享锁（S）或排他锁（X）。相反，第一个获取共享意图锁（IS）的事务将阻止其他事务在该表上获取任何排他锁（X）。这种两阶段过程允许锁请求按顺序解析，而不会阻塞锁和相应的操作，这些操作是兼容的。有关此锁定机制的更多信息，请参阅 第 17.7.1 节，“InnoDB 锁定”。

另见 锁、锁模式、锁定、事务。

intention shared lock

另见 意图锁。

interceptor

用于instrument或调试应用程序某些方面的代码，可以在不重新编译或更改应用程序源代码的情况下启用。

另见 命令拦截器、Connector/J、Connector/NET、异常拦截器。

intrinsic temporary table

优化的内部 InnoDB 临时表，用于 优化器。

另见 优化器。

inverted index

用于文档检索系统的数据结构，用于 InnoDB 全文搜索 的实现。 InnoDB FULLTEXT 索引，实现为倒排索引，记录每个文档中的每个单词的位置，而不是表行的位置。单个列值（文档存储为文本字符串）由倒排索引中的多个条目表示。

另见 全文搜索、FULLTEXT 索引、ilist。

IOPS

缩写为 每秒输入/输出操作数。忙碌系统的常见度量，特别是 OLTP 应用程序。如果该值接近存储设备可以处理的最大值，则应用程序可能会变成 磁盘绑定，限制 可扩展性。

另见 磁盘绑定、OLTP、可扩展性。

isolation level

数据库处理的基础之一。隔离是 ACID 缩写中的 I；隔离级别是调整多个 事务 同时进行更改和查询时性能和可靠性、一致性和结果可重复性的平衡的设置。

从最高的一致性和保护到最低，InnoDB 支持的隔离级别是：SERIALIZABLE、REPEATABLE READ、READ COMMITTED 和 READ UNCOMMITTED。

对于 InnoDB 表，大多数用户可以将默认隔离级别（REPEATABLE READ）用于所有操作。高级用户可能会选择 READ COMMITTED 级别，以推动 OLTP 处理的可扩展性边界，或者在数据仓库操作中，minor 不一致不会影响大量数据的聚合结果。边缘级别（SERIALIZABLE 和 READ UNCOMMITTED）改变处理行为，以至于它们很少使用。

查看 Also ACID, OLTP, READ COMMITTED, READ UNCOMMITTED, REPEATABLE READ, SERIALIZABLE, 事务.

J

J2EE

Java 平台，企业版：Oracle 的企业 Java 平台。它由 API 和企业级 Java 应用程序的运行时环境组成。有关详细信息，请参阅 http://www.oracle.com/technetwork/java/javaee/overview/index.html。在 MySQL 应用程序中，您通常使用 Connector/J 进行数据库访问，并使用应用程序服务器如 Tomcat 或 JBoss 处理中间层工作，并可选使用框架如 Spring。数据库相关功能通常在 J2EE 堆栈中提供，包括 连接池 和 故障转移 支持。

查看 Also 连接池, Connector/J, 故障转移, Java, JBoss, Spring, Tomcat.

Java

一种编程语言，结合了高性能、丰富的内置功能和数据类型、面向对象机制、广泛的标准库和大量可重用的第三方模块。企业开发支持许多框架、应用服务器和其他技术。大多数语法与 C 和 C++ 开发者熟悉。要编写 Java 应用程序与 MySQL 一起使用，您使用 JDBC 驱动程序，称为 Connector/J。

查看 Also C, Connector/J, C++, JDBC.

JBoss

查看 Also J2EE.

JDBC

“Java 数据库连接” 的缩写，用于 Java 应用程序从数据库访问的 API。Java 开发者编写 MySQL 应用程序时使用 Connector/J 组件作为 JDBC 驱动程序。

查看 Also API, Connector/J, J2EE, Java.

JNDI

查看 Also Java.

join

一个从多个表中检索数据的 查询，通过引用表中的相同值列。理想情况下，这些列是 InnoDB 外键 关系的一部分，确保 参照完整性 并且连接列是 索引 的。通常用于节省空间和改善查询性能，通过在 标准化 数据设计中将重复字符串替换为数字 ID。

查看 Also 外键, 索引, 标准化, 查询, 参照完整性.

K

KDC

查看 密钥分发中心.

key distribution center

在 Kerberos 中，密钥分发中心由身份验证服务器 (AS) 和票据授予服务器 (TGS) 组成。

查看 Also 身份验证服务器, 票据授予票据.

keystore

查看 Also SSL.

KEY_BLOCK_SIZE

在使用 压缩行格式 的 InnoDB 表中指定数据页的大小的选项。默认值为 8 千字节。较低的值可能会遇到内部限制，这些限制取决于行大小和压缩百分比的组合。

对于 MyISAM 表，KEY_BLOCK_SIZE 可选地指定索引键块的大小（以字节为单位）。该值被视为提示；如果必要，可能会使用不同的大小。单个索引定义中的 KEY_BLOCK_SIZE 值将覆盖表级 KEY_BLOCK_SIZE 值。

另见 压缩行格式。

L

latch

InnoDB 用于实现锁的轻量级结构，通常持有很短的时间，测量单位为毫秒或微秒。通用术语，包括 互斥锁（用于独占访问）和 读写锁（用于共享访问）。某些闩锁是 InnoDB 性能调整的焦点。通过 性能模式 接口可以获取闩锁使用和争用统计信息。

另见 锁、锁定、互斥锁、性能模式、读写锁。

libmysql

库 libmysqlclient 的非正式名称。

另见 libmysqlclient。

libmysqlclient

库文件，名为 libmysqlclient.a 或 libmysqlclient.so，通常链接到用 C 编写的 客户端 程序中。有时非正式地称为 libmysql 或 mysqlclient 库。

另见 客户端、libmysql、mysqlclient。

libmysqld

这个 嵌入式 MySQL 服务器库使得可以在 客户端 应用程序中运行完整的 MySQL 服务器。主要优点是增加速度和更简单的管理嵌入式应用程序。你链接到 libmysqld 库，而不是 libmysqlclient 库。三个库之间的 API 是相同的。

另见 客户端、嵌入式、libmysql、libmysqlclient。

lifecycle interceptor

由 Connector/J 支持的一种 拦截器 类型。它涉及实现接口 com.mysql.jdbc.ConnectionLifecycleInterceptor。

另见 Connector/J、拦截器。

list

InnoDB 的 缓冲池 表示为内存 页 的列表。该列表根据新页的访问和进入缓冲池、缓冲池中的页被再次访问并被认为较新、长时间未访问的页从缓冲池中 驱逐 而重新排序。缓冲池被分为 子列表，替换策略是熟悉的 LRU 技术的变体。

另见 缓冲池、驱逐、LRU、页、子列表。

load balancing

一种技术，通过将查询请求发送到复制或集群配置中的不同从服务器，以扩展只读连接的能力。使用 Connector/J，可以通过 com.mysql.jdbc.ReplicationDriver 类启用负载平衡，并通过配置属性 loadBalanceStrategy 控制。

另见 Connector/J， J2EE。

localhost

另见 连接。

lock

控制访问资源（如表、行或内部数据结构）的高级概念，作为锁定策略的一部分。为了进行高级性能调整，您可能需要深入研究锁定的实际结构，例如 互斥锁 和 闩锁。

另见 闩锁， 锁定模式， 锁定， 互斥锁。

lock escalation

在某些数据库系统中使用的一种操作，将多个 行锁 转换为单个 表锁，从而节省内存空间，但减少了对表的并发访问。InnoDB 使用行锁的空间高效表示，因此不需要锁升级。

另见 锁定， 行锁， 表锁。

lock mode

共享（S） 锁 允许事务读取行。多个事务可以在同一行上同时获取 S 锁。

排他（X）锁允许事务更新或删除行。没有其他事务可以在同一行上获取任何类型的锁。

意图锁 应用于表，并用于指示事务在表中的锁定意图。不同的事务可以在同一表上获取不同的意图锁，但第一个获取意图排他（IX）锁的事务将阻止其他事务在表上获取任何 S 或 X 锁。相反，第一个获取意图共享（IS）锁的事务将阻止其他事务在表上获取任何 X 锁。两阶段过程允许锁请求按顺序解决，而不会阻止锁和相应的操作。

另见 意图锁， 锁， 锁定， 事务。

locking

保护事务免受其他事务的影响的系统，从而确保数据库操作的一致性和可靠性。锁定策略必须平衡可靠性和一致性与并发性能的需求。微调锁定策略通常涉及选择 隔离级别 并确保所有数据库操作在该隔离级别下都是安全和可靠的。

另见 ACID， 并发， 隔离级别， 锁定， 事务。

locking read

一个 SELECT 语句，也执行 锁定 操作在 InnoDB 表上。要么是 SELECT ... FOR UPDATE，要么是 SELECT ... LOCK IN SHARE MODE。它可能会产生 死锁，取决于事务的 隔离级别。与 非锁定读取 相反。在只读事务中不允许对全局表进行锁定。

SELECT ... FOR SHARE 替换 SELECT ... LOCK IN SHARE MODE 在 MySQL 8.0.1 中，但 LOCK IN SHARE MODE 仍然可用于向后兼容。

参见 第 17.7.2.4 节，“锁定读取”。

另见 死锁、隔离级别、锁定、非锁定读取、只读事务。

log

在 InnoDB 上下文中，““日志” 或 “日志文件” 通常指的是由 重做日志 represented by the ib_logfileN 文件组成的。 另一种 InnoDB 日志是 撤销日志，它是一个存储区域，用于存储活动事务修改的数据副本。

其他重要的 MySQL 日志包括 错误日志（用于诊断启动和运行时问题）、二进制日志（用于复制和执行点时恢复）、通用查询日志（用于诊断应用程序问题）和 慢查询日志（用于诊断性能问题）。

另见 二进制日志、错误日志、通用查询日志、ib_logfile、重做日志、慢查询日志、撤销日志。

log buffer

将要写入 日志文件 的内存区域，组成 重做日志。它由 innodb_log_buffer_size 配置选项控制。

另见 日志文件、重做日志。

log file

ib_logfileN 文件之一，组成 重做日志。数据从 日志缓冲区 内存区域写入这些文件。

另见 ib_logfile、日志缓冲区、重做日志。

log group

组成 重做日志 的文件集，通常命名为 ib_logfile0 和 ib_logfile1。（因此，有时统称为 ib_logfile。）

另见 ib_logfile、重做日志。

logical

一种涉及高级、抽象方面的操作，如表、查询、索引和其他 SQL 概念。通常，逻辑方面对于数据库管理和应用程序开发非常重要。与 物理 相比。

另见 逻辑备份、物理。

logical backup

一种 备份，它重现表结构和数据，而不复制实际数据文件。例如，mysqldump 命令生成逻辑备份，因为其输出包含诸如 CREATE TABLE 和 INSERT 的语句，可以重新创建数据。与 物理备份 相比。逻辑备份提供灵活性（例如，您可以在还原之前编辑表定义或插入语句），但恢复时间可能比物理备份长。

另请参阅 备份, mysqldump, 物理备份, 恢复。

loose_

在InnoDB配置选项后添加的前缀，服务器启动后，因此任何当前MySQL级别不认识的新配置选项不会导致启动失败。 MySQL处理以该前缀开头的配置选项，但如果该前缀后的部分不是已知选项，则发出警告而不是失败。

另请参阅 启动。

low-water mark

代表下限的值，通常是某些纠正措施开始或变得更加激进的阈值。与高水位标记相比。

另请参阅 高水位标记。

LRU

“最近最少使用”（LRU）的缩写，用于管理存储区域。最近未使用的项目将在需要缓存新项目时被驱逐。InnoDB默认使用LRU机制来管理缓冲池中的页，但在某些情况下例外，如在全表扫描期间读取一页。这种LRU算法的变体称为中点插入策略。更多信息，请参阅第17.5.1节，“缓冲池”。

另请参阅 缓冲池, 驱逐, 全表扫描, 中点插入策略, 页。

LSN

“日志序列号”（LSN）的缩写。该任意、不断增加的值表示记录在重做日志中的操作点（无论事务边界）。它用于InnoDB内部的崩溃恢复和管理缓冲池。

在MySQL 5.6.3之前，LSN是一个4字节无符号整数。从MySQL 5.6.3开始，LSN变成了一个8字节无符号整数，因为重做日志文件大小限制从4GB增加到512GB，需要额外的字节来存储大小信息。基于MySQL 5.6.3或更高版本的应用程序使用LSN值应该使用64位而不是32位变量来存储和比较LSN值。

在MySQL Enterprise Backup产品中，可以指定一个LSN来表示从哪个时间点开始进行增量备份。相关的LSN将显示在mysqlbackup命令的输出中。一旦您拥有了完整备份的LSN，可以指定该值来进行后续的增量备份，其输出将包含下一个增量备份的LSN。

另请参阅 缓冲池, 崩溃恢复, 增量备份, MySQL Enterprise Backup, 重做日志, 事务。

M

.MRG file

一个包含对其他表的引用的文件，用于MERGE存储引擎。具有该扩展名的文件总是包含在mysqlbackup命令的备份中。

另请参阅 MySQL Enterprise Backup, mysqlbackup 命令。

.MYD file

MySQL用于存储MyISAM表数据的文件。

另请参阅 .MYI 文件、MySQL 企业备份、mysqlbackup 命令。

.MYI file

MySQL 用于存储 MyISAM 表索引的文件。

另请参阅 .MYD 文件、MySQL 企业备份、mysqlbackup 命令。

master

另请参阅 源。

master thread

一个 InnoDB 线程，它在后台执行各种任务。大多数任务都是 I/O 相关的，例如将 更改缓冲区 中的更改写入适当的辅助索引。

为了提高 并发性，有时将操作从主线程移到单独的后台线程。例如，在 MySQL 5.6 及更高版本中，脏页 从 缓冲池 中刷新到适当的辅助索引中，而不是由主线程刷新。

另请参阅 缓冲池、更改缓冲区、并发性、脏页、刷新、页清洁器、线程。

MDL

缩写为““元数据锁”。

另请参阅 元数据锁。

medium trust

部分信任 的同义词。由于信任设置范围很广，因此““部分信任” 是首选的，以避免暗示只有三个级别（低、中、完全）。

另请参阅 Connector/NET、部分信任。

memcached

MySQL 和 NoSQL 软件栈中的流行组件，允许快速读取和写入单个值，并将结果完全缓存在内存中。传统上，应用程序需要额外的逻辑来将相同的数据写入 MySQL 数据库以进行永久存储，或者从 MySQL 数据库读取数据时尚未缓存在内存中。现在，应用程序可以使用简单的 memcached 协议，通过客户端库与 MySQL 服务器通信，使用 InnoDB 或 NDB 表。这些 NoSQL 接口允许应用程序比直接发出 SQL 语句更高的读取和写入性能，并可以简化应用程序逻辑和部署配置。

另请参阅 NoSQL。

merge

将更改应用于缓存在内存中的数据，例如将页面带入 缓冲池，并将适用的更改从 更改缓冲区 合并到缓冲池中的页面中。更新的数据最终将被 刷新 机制写入 表空间。

另请参阅 缓冲池、更改缓冲区、刷新、表空间。

metadata lock

一种类型的 锁，它防止在同一时间对表执行 DDL 操作，而该表正在被另一个 事务 使用。有关详细信息，请参阅 第 10.11.4 节，“元数据锁定”。

在线操作的增强，特别是在 MySQL 5.6 及更高版本中，集中在减少元数据锁定。目标是使 DDL 操作不改变表结构（例如 CREATE INDEX 和 DROP INDEX 对于 InnoDB 表）在其他事务查询、更新表时继续进行。

另见 DDL、锁、在线、事务。

metrics counter

在 MySQL 5.6 及更高版本中，INNODB_METRICS 表中的一个功能，位于 INFORMATION_SCHEMA 中。你可以查询 计数器 和总数，用于性能调整，结合 性能模式 的数据。

另见 计数器、INFORMATION_SCHEMA、性能模式。

midpoint insertion strategy

将 页 初始加载到 InnoDB 缓冲池 中，不是在列表的“最新”端，而是在中间某个点上。该点的确切位置取决于 innodb_old_blocks_pct 选项的设置。该技术的目的是使只读一次的页（例如在 全表扫描 中）可以更快地从缓冲池中淘汰出去，而不是使用严格的 LRU 算法。更多信息，请参阅 第 17.5.1 节，“缓冲池”。

另见 缓冲池、全表扫描、LRU、页。

mini-transaction

InnoDB 处理的内部阶段，在 物理 级别上对内部数据结构进行更改，发生在 DML 操作期间。mini-事务（mtr）没有回滚的概念；多个 mini-事务可以在单个 事务 中发生。mini-事务将信息写入 重做日志，用于 崩溃恢复。mini-事务也可以在背景线程的 清理 处理期间发生。

另见 提交、崩溃恢复、DML、物理、清理、重做日志、回滚、事务。

mixed-mode insert

一个 INSERT 语句，其中 自动递增 值指定了一些但不是所有新行的值。例如，多值 INSERT 可能会指定某些行的自动递增列值，而其他行则指定为 NULL。InnoDB 生成自动递增值，用于那些指定了 NULL 的行。另一个示例是 INSERT ... ON DUPLICATE KEY UPDATE 语句，其中自动递增值可能会生成，但不用于任何重复行，这些行将被处理为 UPDATE 语句，而不是 INSERT 语句。

可能在源和副本服务器在复制配置中引发一致性问题。可能需要调整innodb_autoinc_lock_mode配置选项的值。

另见 auto-increment, innodb_autoinc_lock_mode, 副本, 复制, 源。

MM.MySQL

MySQL 的旧 JDBC 驱动程序，后来演变为 Connector/J 并与 MySQL 产品集成。

另见 Connector/J。

Mono

Novell 开发的开源框架，用于与 Connector/NET 和 C# 应用程序在 Linux 平台上工作。

另见 Connector/NET, C#。

mtr

见 mini-transaction。

multi-core

一种可以利用多线程程序的处理器，例如 MySQL 服务器。

multiversion concurrency control

见 MVCC。

mutex

Informal 缩写为 “互斥变量”。（Mutex 本身是 “互斥排除” 的缩写。）InnoDB 使用的低级对象，用于表示和实施对内部内存数据结构的独占访问 锁。一旦锁被获取，任何其他进程、线程等都不能获取同一个锁。与 rw-锁 相比，InnoDB 使用它来表示和实施对内部内存数据结构的共享访问 锁。Mutex 和 rw-锁统称为 闩。

另见 闩, 锁, 性能模式, Pthreads, rw-锁。

MVCC

缩写为 “多版本并发控制”。该技术允许 InnoDB 事务 在某些 隔离级别 下执行 一致读取 操作；即查询正在被其他事务更新的行，并看到更新前的值。这是一种强大的技术，可以增加 并发性，因为查询不需要等待其他事务的锁。

这项技术在数据库世界中不是普遍的。一些其他数据库产品和 MySQL 存储引擎不支持它。

另见 ACID, 并发性, 一致读取, 隔离级别, 锁, 事务。

my.cnf

在 Unix 或 Linux 系统上，MySQL 的 选项文件 的名称。

另见 my.ini, 选项文件。

my.ini

在 Windows 系统上，MySQL 的 选项文件 的名称。

另见 my.cnf, 选项文件。

MyODBC drivers

Connector/ODBC 的旧名称。

另见 Connector/ODBC。

mysql

命令行解释器mysql是 MySQL 数据库的命令行解释器。它处理 SQL 语句，也处理 MySQL 特定的命令，如SHOW TABLES，通过将请求传递给mysqld 守护进程。

另见 mysqld, SQL。

MySQL Enterprise Backup

一个具有许可的产品，执行 MySQL 数据库的 热备份。它在备份 InnoDB 表时提供了最高效率和灵活性，但也可以备份 MyISAM 和其他类型的表。

另见 热备份, InnoDB。

mysqlbackup command

MySQL Enterprise Backup 产品的命令行工具。它执行 InnoDB 表的 热备份 操作，并执行 MyISAM 和其他类型的表的 温备份。请参阅 第 32.1 节，“MySQL Enterprise Backup 概述”，以获取关于该命令的更多信息。

另见 热备份, MySQL Enterprise Backup, 温备份。

mysqlclient

库的非正式名称，由文件 libmysqlclient 实现，扩展名为 .a 或 .so。

另见 libmysqlclient。

mysqld

mysqld，也称为 MySQL 服务器，是 MySQL 安装中的单个多线程程序。它不spawn 附加进程。MySQL 服务器管理对 MySQL 数据目录的访问，该目录包含数据库、表和其他信息，如日志文件和状态文件。

mysqld 作为 Unix 守护进程或 Windows 服务，始终等待请求并在后台执行维护工作。

另见 实例, mysql。

MySQLdb

开源 Python 模块的名称，形成了 MySQL Python API 的基础。

另见 Python, Python API。

mysqldump

一个命令，执行某些数据库、表和表数据的 逻辑备份。结果是重现原始架构对象、数据或两者的 SQL 语句。对于大量数据，使用 物理备份 解决方案，如 MySQL Enterprise Backup，特别是在 恢复 操作时更快。

另见 逻辑备份, MySQL Enterprise Backup, 物理备份, 恢复。

N

.NET

另见 ADO.NET, ASP.net, Connector/NET, Mono, Visual Studio。

native C API

libmysqlclient的同义词。

另见 libmysql。

natural key

一个索引列，通常是一个 主键，其中的值具有实际世界意义。通常不建议使用，因为：

• 如果值需要更改，将需要大量的索引维护来重新排序 聚簇索引 并更新每个 次要索引 中重复的主键值。

• 即使看似稳定的值也可能以不可预测的方式更改，难以在数据库中正确表示。例如，一个国家可能会分裂成两个或多个，使原始国家代码变得过时。或者，关于唯一值的规则可能有例外。例如，即使纳税人 ID 号码旨在每个人的唯一，但数据库可能需要处理违反该规则的记录，例如身份盗用情况。纳税人 ID 号码和其他敏感 ID 号码也不是良好的主键，因为它们可能需要加密、加密和以不同的方式处理其他列。

因此，通常更好地使用任意数字值来形成 合成键，例如使用 自动递增 列。

另见 自动递增，聚簇索引，主键，次要索引，合成键。

neighbor page

在同一个 范围 中的任何 页。当一页被选中以被 刷新 时，任何邻近页如果是 脏 的，也通常会被刷新，以便于传统硬盘的 I/O 优化。在 MySQL 5.6 及更高版本中，这种行为可以通过配置变量 innodb_flush_neighbors 控制；您可能会将该设置关闭，以便于 SSD 驱动器，它们不具有相同的随机写入开销。

另见 脏页，范围，刷新，页。

next-key lock

一个组合，包括索引记录的 记录锁 和索引记录前的 gap 锁。

另见 gap 锁，锁定，记录锁。

non-locking read

一个不使用 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 子句的 查询。这是全局表在 只读事务 中允许的唯一查询类型。与 锁定读 相反。见 第 17.7.2.3 节，“一致的非锁定读取”。

SELECT ... FOR SHARE 在 MySQL 8.0.1 中取代了 SELECT ... LOCK IN SHARE MODE，但 LOCK IN SHARE MODE 仍然保留了向后兼容性。

另见 锁定读，查询，只读事务。

non-repeatable read

在同一个 事务 中，查询检索数据，然后后续查询检索相同的数据，但查询返回不同的结果（在此期间另一个事务提交了更改）。

这种操作违反了数据库设计的 ACID 原则。在事务中，数据应该是一致的，具有可预测的和稳定的关系。

在不同的 隔离级别 中，非重复读取被可序列化读取和重复读取级别所防止，而一致读取和未提交读取级别允许这种情况。

也见 ACID，一致读取，隔离级别，READ UNCOMMITTED，可重复读取，可串行化，事务。

nonblocking I/O

industry术语，表示异步I/O的同义词。

也见 异步I/O。

normalized

数据库设计策略，其中数据被拆分为多个表，并将重复值压缩到单行中，使用ID表示，以避免存储、查询和更新冗长或冗长的值。它通常用于 OLTP 应用程序。

例如，地址可能被赋予唯一的ID，以便人口普查数据库可以通过关联该ID与每个家庭成员，来表示 居住在这个地址 关系，而不是存储多个副本的复杂值，例如 123 Main Street, Anytown, USA。

例如，虽然简单的地址簿应用程序可能将每个电话号码存储在同一个表中的人名和地址中，但电话公司数据库可能会给每个电话号码一个特殊的ID，并将号码和ID存储在单独的表中。这种规范化表示可以简化大规模更新时的区域代码拆分。

规范化并不总是推荐的。主要用于查询的数据，并且仅通过删除整个重新加载来更新，通常保持在较少的、较大的表中，具有冗长的副本值。这种数据表示形式称为 非规范化，经常出现在数据仓库应用程序中。

也见 非规范化，外键，OLTP，关系型。

NoSQL

广义术语，指不使用 SQL 语言作为主要机制来读取和写入数据的一组数据访问技术。一些NoSQL技术充当键值存储，只接受单值读取和写入；一些放松了 ACID 方法学的限制；还有一些不需要预先计划的 模式。MySQL用户可以通过使用 memcached API直接访问某些MySQL表来结合NoSQL风格的处理速度和简单性与SQL操作的灵活性和便捷性。

也见 ACID，memcached，模式，SQL。

NOT NULL constraint

一种类型的 约束，指定某个 列 不能包含任何 NULL 值。它有助于保存 参照完整性，因为数据库服务器可以识别具有错误缺失值的数据。它还帮助了查询优化中的算术运算，允许优化器预测该列上的索引中的条目数。

也见 列，约束，NULL，主键，参照完整性。

NULL

SQL 中的特殊值，表示数据的缺失。任何涉及 NULL 值的算术运算或相等测试都将产生 NULL 结果。（因此它类似于IEEE浮点概念中的NaN，“不是数字”）。任何聚合计算，例如 AVG()，在确定要除以多少行时都会忽略具有 NULL 值的行。只有使用SQL idioms IS NULL 或 IS NOT NULL 的测试可以与 NULL 值一起工作。

NULL 值在 索引 操作中扮演着重要角色，因为数据库必须尽量减少跟踪缺失数据值的开销。通常，NULL 值不会存储在索引中，因为使用标准比较运算符测试索引列的查询永远不会匹配该列的 NULL 值。出于同样的原因，唯一索引不禁止 NULL 值；这些值只是不在索引中表示。声明 NOT NULL 约束在列上提供了确保没有行被排除在索引之外的保证，从而允许更好的查询优化（准确计数行和估算是否使用索引）。

因为 主键 必须能够唯一标识表中的每一行，所以单列主键不能包含任何 NULL 值，而多列主键不能包含所有列的 NULL 值。

尽管 Oracle 数据库允许将 NULL 值与字符串连接，但 InnoDB 将这种操作的结果视为 NULL。

另见 索引、主键、SQL。

O

.OPT file

包含数据库配置信息的文件。具有该扩展名的文件包含在由 mysqlbackup 命令生成的备份中，该命令来自 MySQL Enterprise Backup 产品。

另见 MySQL Enterprise Backup、mysqlbackup 命令。

ODBC

Open Database Connectivity 的缩写，一个行业标准 API。通常用于 Windows 基础服务器或需要使用 ODBC 与 MySQL 通信的应用程序。MySQL ODBC 驱动程序称为 Connector/ODBC。

另见 Connector/ODBC。

off-page column

包含可变长度数据（例如 BLOB 和 VARCHAR）的列，该数据太长无法适合 B 树 页。数据存储在 溢出页 中。DYNAMIC 行格式比旧的 COMPACT 行格式更适合这种存储。

另见 B 树、compact 行格式、dynamic 行格式、溢出页。

OLTP

缩写为“在线事务处理”。数据库系统或数据库应用程序，运行大量事务的工作负载，同时具有频繁的写入和读取操作，通常影响小量数据。例如，航空公司预订系统或处理银行存款的应用程序。数据可能以 标准化 形式组织，以平衡 DML（插入/更新/删除）效率和 查询 效率。与 数据仓库 相比。

由于其 行级锁定 和 事务 能力，InnoDB 是 MySQL 表用于 OLTP 应用程序的理想存储引擎。

另见 数据仓库、DML、InnoDB、查询、行锁、事务。

online

一种不需要停机、阻塞或限制操作的数据库操作。通常应用于 DDL。操作可以缩短限制操作期的操作，例如 快速索引创建，已经演变为 MySQL 5.6 中更广泛的一组 在线 DDL 操作。

在备份的上下文中，一个 热备份 是一个在线操作，而 温备份 是部分在线操作。

另见 DDL, 快速索引创建, 热备份, 在线 DDL, 温备份。

online DDL

一个改进 InnoDB 表性能、并发性和可用性的功能，主要用于 DDL（主要是 ALTER TABLE）操作。详见 第 17.12 节，“InnoDB 和在线 DDL”。

细节根据操作类型而异。在某些情况下，表可以在 ALTER TABLE 进行时被修改。操作可能可以在不复制表的情况下进行，或者使用特殊优化的表复制方式。DML 日志空间使用情况由 innodb_online_alter_log_max_size 配置选项控制。

该功能是 MySQL 5.5 中 快速索引创建 功能的增强。

另见 DDL, 快速索引创建, 在线。

optimistic

关系数据库系统的低级实现决策指南。性能和 并发性 需要快速启动或派遣操作。一致性和 参照完整性 需要任何操作都可能失败：事务可能回滚，DML 操作可能违反约束，锁请求可能导致死锁，网络错误可能导致超时。乐观策略假设大多数请求或尝试都成功，因此数据库做了很少的无用工作；当请求失败时，需要做额外的工作来清理和撤销更改。

InnoDB 使用乐观策略来处理操作，如 锁定 和 提交。例如，事务更改的数据可以在提交之前写入数据文件，使提交本身非常快，但需要更多的工作来撤销更改如果事务回滚。

乐观策略的对立面是一个 悲观 策略，其中系统被优化以处理不可靠和频繁失败的操作。这在数据库系统中很少见，因为选择了可靠的硬件、网络和算法。

另见 提交, 并发性, DML, 锁定, 悲观, 参照完整性。

optimizer

MySQL 组件，确定用于 查询 的最佳 索引 和 连接 顺序，基于相关 表 的特征和数据分布。

另见 索引, 连接, 查询, 表。

option

MySQL 配置参数，存储在 选项文件 中或通过命令行传递。

对于 InnoDB 表的选项，每个选项名称以 innodb_ 前缀开头。

另见 InnoDB, 选项, 选项文件。

option file

MySQL 实例的配置 选项 文件。传统上，在 Linux 和 Unix 中该文件名为 my.cnf，在 Windows 中名为 my.ini。

另见 配置文件，my.cnf，my.ini，选项。

overflow page

单独分配的磁盘 页，用于存储变长列（如 BLOB 和 VARCHAR）这些列太长，无法容纳在 B 树 页上。这些列被称为 离页列。

另见 B 树，离页列，页。

P

.par file

包含分区定义的文件。该扩展名文件包含在由 mysqlbackup 命令生成的备份中，属于 MySQL Enterprise Backup 产品。

从 MySQL 5.7.6 开始，InnoDB 表的本地分区支持不再创建 .par 文件。MyISAM 表的分区仍然使用 .par 文件。在 MySQL 8.0 中，仅 InnoDB 存储引擎支持分区，因此不再使用 .par 文件。

另见 MySQL Enterprise Backup，mysqlbackup 命令。

page

一个单位，表示 InnoDB 在磁盘（数据文件）和内存（缓冲池）之间传输的数据量。一个页可以包含一个或多个 行，取决于每行中的数据量。如果一行不适合单个页，InnoDB 将设置附加的指针样式数据结构，以便将行信息存储在一个页上。

一种方法是使用 压缩行格式，以便在每个页中容纳更多数据。对于使用 BLOB 或大文本字段的表，紧凑行格式 允许这些大列单独存储，减少 I/O 开销和内存使用量，对于不引用这些列的查询。

当 InnoDB 以批处理方式读取或写入页，以提高 I/O 吞吐量时，它读取或写入一个 范围。

所有 InnoDB 磁盘数据结构在一个 MySQL 实例中共享同一个 页大小。

另见 缓冲池，紧凑行格式，压缩行格式，数据文件，范围，页大小，行。

page cleaner

一个 InnoDB 后台 线程，用于从 缓冲池 中刷新 脏页。在 MySQL 5.6 之前，该活动由 主线程 执行。该线程的数量由 innodb_page_cleaners 配置选项控制，自 MySQL 5.7.4 起引入。

另见 缓冲池，脏页，刷新，主线程，线程。

page size

对于 MySQL 5.5 及更低版本，InnoDB 的每个 页 的大小固定为 16 千字节。这是一个平衡值：足够大以容纳大多数行的数据，同时又足够小以最小化将不需要的数据传输到内存中的性能开销。其他值未经测试或支持。

从 MySQL 5.6 开始，InnoDB 实例 的页大小可以是 4KB、8KB 或 16KB，由 innodb_page_size 配置选项控制。从 MySQL 5.7.6 开始，InnoDB 还支持 32KB 和 64KB 的页大小。对于 32KB 和 64KB 的页大小，ROW_FORMAT=COMPRESSED 不受支持，最大记录大小为 16KB。

页大小是在创建 MySQL 实例时设置的，并且在以后保持不变。同一个页大小适用于所有 InnoDB 表空间，包括 系统表空间、每个表的表空间 和 通用表空间。

较小的页大小可以帮助改善使用小块大小的存储设备的性能，特别是在 SSD 设备上的 磁盘绑定 工作负载中，例如对于 OLTP 应用程序。当单个行被更新时，少量的数据被复制到内存中，写入磁盘，重新组织，锁定等。

另见 磁盘绑定、每个表的表空间、通用表空间、实例、OLTP、页、SSD、系统表空间、表空间。

parent table

在 外键 关系中，持有初始列值的表，从 子表 指向的表。根据外键定义中的 ON UPDATE 和 ON DELETE 子句，删除或更新父表中的行可能会自动删除或更新子表中的行，或者将这些列设置为 NULL，或者阻止操作。

另见 子表、外键。

partial backup

一个 备份，其中包含 MySQL 数据库中的某些 表，或 MySQL 实例中的某些数据库。与 完整备份 相比。

另见 备份、完整备份、表。

partial index

一个 索引，它只代表列值的一部分，通常是长 VARCHAR 值的前 N 个字符（前缀）。

另见 索引、索引前缀。

partial trust

一个执行环境，通常由托管提供商使用，其中应用程序具有某些权限，但不是所有权限。例如，应用程序可能可以访问网络上的数据库服务器，但被 “沙盒”，不能读取或写入本地文件。

另见 Connector/NET。

Performance Schema

在 MySQL 5.5 及更高版本中，performance_schema 架构提供了一组表，可以查询以获取 MySQL 服务器内部许多部分的性能特征信息。见 第 29 章 MySQL 性能架构。

另见 INFORMATION_SCHEMA、锁、互斥锁、读写锁。

Perl

一种具有 Unix 脚本和报告生成根源的编程语言。它结合了高性能的正则表达式和文件 I/O。通过仓库如 CPAN 提供了大量可重用的模块。

另见 Perl API。

Perl API

一个为 MySQL 应用程序编写的开源 API，使用 Perl 语言。通过 DBI 和 DBD::mysql 模块实现。详细信息，请参阅 第 31.9 节，“MySQL Perl API”。

另见 API, Perl。

persistent statistics

一个存储 索引 统计信息的功能，以便于 InnoDB 表 在磁盘上，提供更好的 计划稳定性，用于 查询。详细信息，请参阅 第 17.8.10.1 节，“配置持久优化器统计参数”。

另见 索引, 优化器, 计划稳定性, 查询, 表。

pessimistic

一种牺牲性能或并发性以换取安全性的方法。如果大多数请求或尝试可能失败，或者如果失败的请求的后果很严重。InnoDB 使用所谓的悲观 锁定 策略，以尽量减少 死锁 的可能性。在应用程序级别，您可以通过在事务的开始时获取所有需要的锁来避免死锁。

许多内置数据库机制使用相反的 乐观 方法。

另见 死锁, 锁定, 乐观。

phantom

在查询结果集中出现的一行，但不在早期查询结果集中。例如，如果在事务中两次运行查询，并在此期间另一个事务提交了新行或更新了行以匹配查询的 WHERE 子句。

这种情况称为幻影读取。它比 不可重复读取 更难以防止，因为锁定第一个查询结果集中的所有行不能防止引起幻影出现的更改。

在不同的 隔离级别 中，幻影读取被可序列化读取级别所防止，而在可重复读取、一致读取和读取未提交级别中被允许。

另见 一致读取, 隔离级别, 不可重复读取, 读取未提交, 可重复读取, 可序列化, 事务。

PHP

一种起源于 Web 应用程序的编程语言。代码通常嵌入到 Web 页面的源代码中，以便在 Web 服务器传输页面时将输出替换到页面中。这与 CGI 脚本打印整个 Web 页面的输出不同。PHP 风格的编程用于高度交互式和动态的 Web 页面。现代 PHP 程序也可以作为命令行或 GUI 应用程序运行。

MySQL 应用程序使用一个 PHP API 编写。可重用的模块可以用 C 编写并从 PHP 调用。

另一种用于编写服务器端 Web 页面的技术是 ASP.net。

另见 ASP.net, C, PHP API。

PHP API

多个 API 可用于编写 MySQL 应用程序，以 PHP 语言：原始 MySQL API (Mysql)，MySQL Improved Extension (Mysqli)，MySQL Native Driver (Mysqlnd)，MySQL 函数 (PDO_MYSQL)，以及 Connector/PHP。有关详细信息，请参阅 MySQL 和 PHP。

另见 API, PHP。

physical

一种涉及硬件相关方面的操作，如磁盘块、内存页、文件、位、磁盘读取等。通常，在专家级性能调整和问题诊断中，物理方面非常重要。与 逻辑 相比。

另见 逻辑, 物理备份。

physical backup

一个 备份，它复制了实际的数据文件。例如，mysqlbackup 命令的 MySQL Enterprise Backup 产品生成了一个物理备份，因为其输出包含可以直接由 mysqld 服务器使用的数据文件，从而导致更快的 恢复 操作。与 逻辑备份 相比。

另见 备份, 逻辑备份, MySQL Enterprise Backup, 恢复。

PITR

PITR 的缩写，表示 点-in-time 恢复。

另见 点-in-time 恢复。

plan stability

查询执行计划的属性，其中优化器对给定 查询 做出相同的选择，以便性能是一致的和可预测的。

另见 查询, 查询执行计划。

point-in-time recovery

将 备份 恢复到特定日期和时间的状态。通常缩写为 “PITR”。因为指定的时间通常不正好对应备份的时间，因此该技术通常需要结合 物理备份 和 逻辑备份。例如，使用 MySQL Enterprise Backup 产品，恢复最后一个在指定时间之前的备份，然后从 二进制日志 中回放变化。

另见 备份, 二进制日志, 逻辑备份, MySQL Enterprise Backup, 物理备份。

port

数据库服务器监听的 TCP/IP 套接字号，用于建立 连接。通常与 主机 一起指定。根据网络加密的使用情况，可能有一个端口用于未加密的流量，另一个端口用于 SSL 连接。

另见 连接, 主机, SSL。

prefix

另见 索引前缀。

prepared backup

由 MySQL Enterprise Backup 产品生成的备份文件，经过了所有阶段的二进制日志和增量备份应用后。结果文件准备好以供 恢复。在应用步骤之前，这些文件被称为 原始备份。

另请参阅：二进制日志、热备份、增量备份、MySQL Enterprise Backup、原始备份、恢复。

prepared statement

预先分析的 SQL 语句，以确定高效的执行计划。它可以多次执行，而不需要每次都进行解析和分析。可以通过使用占位符将不同的值替换到 WHERE 子句中，每次执行时。这项技术可以提高安全性，保护against 一些 SQL 注入攻击。您还可以减少将返回值复制到程序变量的开销。

虽然可以通过 SQL 语句直接使用预备语句，但是各种 连接器 都有编程接口来操作预备语句，这些 API 比通过 SQL 更高效。

另请参阅：客户端预备语句、连接器、服务器端预备语句。

primary key

一组可以唯一标识表中每一行的列集——因此，它必须是一个唯一索引，不包含任何 NULL 值。

InnoDB 需要每个表都有这样一个索引（也称为 聚簇索引 或 簇索引），并根据主键列的值组织表存储。

选择主键值时，考虑使用任意值（一个 合成键）而不是依赖来自其他来源的值（一个 自然键）。

另请参阅：聚簇索引、索引、自然键、合成键。

principal

Kerberos 中命名实体的术语，例如用户或服务器。

另请参阅：服务主体名称、用户主体名称。

process

执行程序的一个实例。操作系统在多个运行进程之间切换，允许一定程度的 并发。在大多数操作系统中，进程可以包含多个 线程，共享资源。线程之间的上下文切换比进程之间的切换更快。

另请参阅：并发、线程。

pseudo-record

索引中的一个虚拟记录，用于 锁定 不存在的键值或范围。

另请参阅：最小记录、锁定、最大记录。

Pthreads

POSIX 线程标准，定义了 Unix 和 Linux 系统上的线程和锁操作接口。InnoDB 在 Unix 和 Linux 系统上使用该实现来实现 互斥锁。

另请参阅：互斥锁。

purge

由一个或多个后台线程（由 innodb_purge_threads 控制）执行的垃圾回收类型，周期性地运行。Purge 解析和处理 撤销日志 页，从 历史列表 中删除标记为删除的聚簇和辅助索引记录，并释放撤销日志页。

另请参阅 历史记录列表, 多版本并发控制, 回退, 撤销日志。

purge buffering

将次要索引页的更改存储在 更改缓冲区 中，而不是立即写入，以便将物理写入最小化随机 I/O。（因为删除操作是一个两步过程，因此该操作缓冲了通常清除已标记为删除的索引记录的写入。）它是 更改缓冲 的一种类型；其他类型是 插入缓冲 和 删除缓冲。

另请参阅 更改缓冲区, 更改缓冲, 删除缓冲, 插入缓冲区, 插入缓冲。

purge lag

InnoDB 历史记录列表 的另一个名称。与 innodb_max_purge_lag 配置选项相关。

另请参阅 历史记录列表, 清除。

purge thread

InnoDB 进程中的一个 线程，专门执行周期性的 清除 操作。在 MySQL 5.6 及更高版本中，通过 innodb_purge_threads 配置选项启用多个清除线程。

另请参阅 清除, 线程。

Python

广泛应用于多个领域的编程语言，从 Unix 脚本到大型应用程序。包括运行时类型、内置高级数据类型、面向对象特性和广泛的标准库。经常用作其他语言之间的 “胶水” 语言。MySQL 的 Python API 是开源的 MySQLdb 模块。

另请参阅 MySQLdb, Python API。

Python API

另请参阅 API, Python。

Q

query

在 SQL 中，从一个或多个 表 中读取信息的操作。根据数据的组织方式和查询参数，查找可能通过咨询 索引 进行优化。如果涉及多个表，则查询称为 连接。

出于历史原因，有时内部处理语句的讨论使用 “查询” 一词，以涵盖 MySQL 语句的其他类型，例如 DDL 和 DML 语句。

另请参阅 DDL, DML, 索引, 连接, SQL, 表。

query execution plan

优化器关于如何最有效地执行 查询 的一系列决定，包括哪些 索引 或索引使用，以及表的连接顺序。计划稳定性 涉及到一致地为给定查询做出相同的选择。

另请参阅 索引, 连接, 计划稳定性, 查询。

query log

另请参阅 通用查询日志。

quiesce

为了减少数据库活动，通常是在准备某些操作之前，如ALTER TABLE，备份，或关闭。可能或不可能涉及尽可能多地刷新，以便InnoDB不再进行后台I/O。

在MySQL 5.6及更高版本中，语法FLUSH TABLES ... FOR EXPORT将一些数据写入磁盘，以便备份InnoDB表格时可以通过复制数据文件。

另见备份，刷新，InnoDB，关闭。

R

R-tree

一个树形数据结构，用于多维数据的空间索引，如地理坐标、矩形或多边形。

另见B树。

RAID

缩写为““廉价磁盘冗余阵列””。将I/O操作分布在多个驱动器上，提高了硬件级别的并发性，并改善了原本顺序执行的低级写操作的效率。

另见并发性。

random dive

一个快速估算列中不同值的数量（列的基数）技术。InnoDB从索引中随机抽样页面，并使用该数据来估算不同值的数量。

另见基数。

raw backup

由MySQL Enterprise Backup产品生成的初始备份文件集，在应用二进制日志和增量备份的更改之前。在这个阶段，文件还不能恢复。在应用这些更改后，文件被称为prepared backup。

另见二进制日志，热备份，ibbackup_logfile，增量备份，MySQL Enterprise Backup，prepared backup，恢复。

READ COMMITTED

一个隔离级别，使用锁定策略来放松事务之间的一些保护，以提高性能。事务不能看到未提交的数据，但可以看到其他事务提交的数据。因此，事务从不看到坏数据，但看到的数据可能取决于其他事务的时序。

当事务具有该隔离级别时，执行UPDATE ... WHERE或DELETE ... WHERE操作时，其他事务可能需要等待。事务可以执行SELECT ... FOR UPDATE和LOCK IN SHARE MODE操作，而不需要其他事务等待。

SELECT ... FOR SHARE在MySQL 8.0.1中取代了SELECT ... LOCK IN SHARE MODE，但LOCK IN SHARE MODE仍然可用于向后兼容。

另见ACID，隔离级别，锁定，可重复读，可串行化，事务。

read phenomena

如脏读、不可重复读和幻读等现象，可能发生在事务读取其他事务修改的数据时。

另见 脏读, 不可重复读, 幻像。

READ UNCOMMITTED

该隔离级别提供了最少的保护之间的事务。查询采用锁定策略，允许它们在通常情况下等待另一个事务的情况下继续执行。然而，这种额外的性能来自于结果的可靠性较低，包括其他事务尚未提交的数据更改（称为 脏读）。请谨慎使用该隔离级别，并注意结果可能不一致或不可重复，取决于其他事务同时执行的情况。通常，该隔离级别的事务仅执行查询，而不是插入、更新或删除操作。

另见 ACID, 脏读, 隔离级别, 锁定, 事务。

read view

InnoDB 的 MVCC 机制使用的内部快照。某些 事务，取决于它们的 隔离级别，看到数据值是从事务（或在某些情况下，语句）开始时的那样。使用读取视图的隔离级别是 可重复读、提交读 和 未提交读。

另见 隔离级别, MVCC, 提交读, 未提交读, 可重复读, 事务。

read-ahead

一种 I/O 请求，预先将一组 页（整个 范围）异步加载到 缓冲池 中，以便在需要时使用。线性读取预读技术预先加载前一个范围的所有页，而随机读取预读技术预先加载某个范围的所有页，直到该范围中的某些页被加载到缓冲池中。随机读取预读技术不在 MySQL 5.5 中，但在 MySQL 5.6 中重新引入，受 innodb_random_read_ahead 配置选项的控制。

另见 缓冲池, 范围, 页。

read-only transaction

一种 事务，可以为 InnoDB 表优化，通过消除创建 读取视图 的一些簿记工作。只能执行 非锁定读 查询。可以使用语法 START TRANSACTION READ ONLY 明确启动，或者在某些情况下自动启动。详见 第 10.5.3 节，“优化 InnoDB 只读事务”。

另见 非锁定读, 读取视图, 事务。

record lock

索引记录上的锁。例如，SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE; 防止其他事务插入、更新或删除行，其中 t.c1 的值为 10。与 间隙锁 和 next-key 锁 相比。

另见 间隙锁, 锁, next-key 锁。

redo

记录在 重做日志 中的数据，以记录为单位，当 DML 语句更改 InnoDB 表时。它在 崩溃恢复 期间用于纠正不完整 事务 所写入的数据。不断增加的 LSN 值表示通过重做日志传递的累积重做数据量。

另见 崩溃恢复, DML, LSN, 重做日志, 事务。

redo log

在 崩溃恢复 期间用于纠正不完整 事务 所写入的数据的磁盘 기반数据结构。在正常操作期间，它对 InnoDB 表数据的更改请求进行编码，这些请求来自 SQL 语句或低级 API 调用。在意外 shutdown 之前未完成更新 数据文件 的修改将自动重放。

重做日志在磁盘上物理表示为一组重做日志文件。重做日志数据以记录为单位编码；这些数据统称为 重做。重做日志中的数据传递由不断增加的 LSN 值表示。

更多信息，请参阅 第 17.6.5 节，“重做日志”

另见 崩溃恢复, 数据文件, ib_logfile, 日志缓冲区, LSN, 重做, shutdown, 事务。

redo log archiving

InnoDB 的一个功能，当启用时，将重做日志记录顺序写入存档文件，以避免备份实用程序在备份操作期间无法跟上重做日志生成时可能发生的数据丢失。更多信息，请参阅 重做日志存档。

另见 重做日志。

redundant row format

InnoDB 的最古老的 行格式。在 MySQL 5.0.3 之前，它是 InnoDB 中唯一可用的行格式。从 MySQL 5.0.3 到 MySQL 5.7.8，默认行格式是 COMPACT。从 MySQL 5.7.9 开始，默认行格式由 innodb_default_row_format 配置选项定义，默认设置为 DYNAMIC。您仍然可以为与旧的 InnoDB 表兼容指定 REDUNDANT 行格式。

更多信息，请参阅 第 17.10 节，“InnoDB 行格式”。

另见 紧凑行格式, 动态行格式, 行格式。

referential integrity

一种保持数据始终保持一致格式的技术，是 ACID 哲学的一部分。特别是，通过使用 外键约束，保持不同表中的数据一致，这些约束可以防止更改或自动将更改传播到所有相关表。相关机制包括 唯一约束，它防止重复值被插入错误，以及 非空约束，它防止空值被插入错误。

另见 ACID, 外键约束, 非空约束, 唯一约束。

relational

现代数据库系统的一个重要方面。数据库服务器编码和执行关系，如一对一、一对多、多对一和唯一性。例如，在地址数据库中，一人可能有零、一个或多个电话号码；单个电话号码可能与多个家庭成员相关。在财务数据库中，一个人可能需要有一个唯一的纳税人ID，每个纳税人ID只能与一个人相关。

数据库服务器可以使用这些关系来防止坏数据的插入，并找到查找信息的高效方式。例如，如果一个值被声明为唯一，服务器可以在找到第一个匹配项时停止搜索，并拒绝插入第二个副本的相同值。

在数据库级别，这些关系通过SQL功能表达，如表中的列、唯一和 NOT NULL 约束、外键和不同的连接操作。复杂的关系通常涉及多个表之间的数据分割。通常，数据是规范化的，以便在一对多关系中存储唯一值。

在数学上下文中，数据库中的关系来自集合理论。例如，WHERE子句中的 OR 和 AND 运算符表示union和交集的概念。

另见 ACID, 列, 约束, 外键, 规范化。

relevance

在全文搜索功能中，一个数字表示搜索字符串和数据在 FULLTEXT 索引中的相似度。例如，当您搜索单个单词时，该单词在文本中出现多次的行比出现一次的行更相关。

另见 全文搜索, FULLTEXT 索引。

REPEATABLE READ

InnoDB 的默认 隔离级别。它防止任何查询的行被其他 事务更改，从而阻止 不可重复读，但不阻止 幻影 读取。它使用中等严格的 锁定 策略，以便所有查询在事务中看到相同的快照，即事务开始时的数据。

当事务具有这种隔离级别时执行 UPDATE ... WHERE、DELETE ... WHERE、SELECT ... FOR UPDATE 和 LOCK IN SHARE MODE 操作时，其他事务可能需要等待。

SELECT ... FOR SHARE 在 MySQL 8.0.1 中取代 SELECT ... LOCK IN SHARE MODE，但 LOCK IN SHARE MODE 仍然可用于向后兼容。

另见 ACID, 一致读取, 隔离级别, 锁定, 幻影, 事务。

repertoire

字符集 репертуар是应用于字符集的术语。字符集 репертуар是集合中的字符。见 第 12.2.1 节，“Character Set Repertoire”。

replica

在 复制拓扑结构中，一个数据库 服务器 机器，它从另一个服务器（源）接收更改，并应用相同的更改。因此，它维护与源相同的内容，尽管可能落后一些。

在 MySQL 中，副本通常用于灾难恢复，以取代失败的源。它们也常用于测试软件升级和新设置，以确保数据库配置更改不会导致性能或可靠性问题。

副本通常具有高工作负载，因为它们处理来自源的所有 DML（写）操作，以及用户查询。为了确保副本可以快速应用来自源的更改，它们通常具有快速的 I/O 设备和足够的 CPU 和内存，以在同一服务器上运行多个数据库实例。例如，源可能使用硬盘存储，而副本使用 SSDs。

另见 DML, 复制, 服务器, 源, SSD。

replication

从 源 将更改发送到一个或多个 副本，以便所有数据库具有相同的数据。这项技术有广泛的用途，例如负载均衡以提高可扩展性、灾难恢复和测试软件升级和配置更改。这些更改可以通过称为 基于行的复制 和 基于语句的复制 的方法在数据库之间发送。

另见 副本, 基于行的复制, 源, 基于语句的复制。

restore

将 MySQL Enterprise Backup 产品的备份文件集放置在 MySQL 使用的过程。这项操作可以用于修复损坏的数据库、返回到某个早期时间点或（在 复制 上下文中）设置新的 副本。在 MySQL Enterprise Backup 产品中，这项操作由 copy-back 选项的 mysqlbackup 命令执行。

另见 热备份, MySQL Enterprise Backup, mysqlbackup 命令, 预备备份, 副本, 复制。

rollback

一条 SQL 语句，结束一个 事务，撤销事务中的所有更改。这是 提交 的反义词，后者使事务中的所有更改永久化。

默认情况下，MySQL 使用 自动提交 设置，该设置在每个 SQL 语句后自动发出提交。你必须在使用回滚技术之前更改此设置。

另见 ACID, 自动提交, 提交, SQL, 事务。

rollback segment

存储区域，包含 撤销日志。回滚段传统上位于 系统表空间 中。从 MySQL 5.6 开始，回滚段可以位于 撤销表空间 中。从 MySQL 5.7 开始，回滚段也分配给 全局临时表空间。

另见 全局临时表空间, 系统表空间, 撤销日志, 撤销表空间。

row

由一组 列 定义的逻辑数据结构。一个表由一组行组成。在 InnoDB 数据文件 中，每个 页 可以包含一个或多个行。

尽管 InnoDB 使用术语 行格式 以保持与 MySQL 语法的一致性，但行格式是每个表的属性，并应用于该表中的所有行。

另请参阅：列、数据文件、页、行格式、表。

row format

InnoDB 表的磁盘存储格式为 行。随着 InnoDB 获得新的功能，如 压缩，新的行格式被引入以支持存储效率和性能的改进。

InnoDB 表的行格式由 ROW_FORMAT 选项或 innodb_default_row_format 配置选项（在 MySQL 5.7.9 中引入）指定。行格式包括 REDUNDANT、COMPACT、COMPRESSED 和 DYNAMIC。要查看 InnoDB 表的行格式，请发出 SHOW TABLE STATUS 语句或查询 InnoDB 表元数据在 INFORMATION_SCHEMA 中。

另请参阅：紧凑行格式、压缩行格式、压缩、动态行格式、冗余行格式、行、表。

row lock

防止行被其他 事务 以不兼容的方式访问的 锁。同一表中的其他行可以被其他事务自由写入。这是 DML 操作在 InnoDB 表上的锁定类型。

与 表锁 相比，后者用于 MyISAM，或在 InnoDB 表上进行的 DDL 操作中，无法使用 在线 DDL；这些锁阻止了对表的并发访问。

另请参阅：DDL、DML、InnoDB、锁、锁定、在线 DDL、表锁、事务。

row-based replication

一种 复制 形式，其中事件从 源 指定如何更改个别行在 副本 上。这对于所有 innodb_autoinc_lock_mode 选项的设置都是安全的。

另请参阅：自动递增锁定、innodb_autoinc_lock_mode、副本、复制、源、基于语句的复制。

row-level locking

InnoDB 表的 锁定 机制，依赖于 行锁 而不是 表锁。多个 事务 可以并发修改同一表。只有当两个事务尝试修改同一行时，一个事务将等待另一个事务完成（并释放其行锁）。

另请参阅 InnoDB、锁定、行锁、表锁、事务。

Ruby

一种强调动态类型和面向对象编程的编程语言。一些语法与 Perl 开发者熟悉。

另请参阅 API、Perl、Ruby API。

Ruby API

基于 libmysqlclient API 库的 mysql2，适用于 Ruby 程序员开发 MySQL 应用程序。有关更多信息，请参阅 第 31.11 节，“MySQL Ruby APIs”。

另请参阅 libmysql、Ruby。

rw-lock

低级对象，InnoDB 用于表示和实施共享访问 锁 到内部内存数据结构，遵循一定规则。与 互斥锁 相比，InnoDB 用于表示和实施独占访问内部内存数据结构。互斥锁和读写锁统称为 闩锁。

rw-lock 类型包括 s-locks（共享锁）、x-locks（排他锁）和 sx-locks（共享排他锁）。

• 一个 s-lock 提供对公共资源的读取访问。

• 一个 x-lock 提供对公共资源的写入访问，同时不允许其他线程进行不一致的读取。

• 一个 sx-lock 提供对公共资源的写入访问，同时允许其他线程进行不一致的读取。sx-locks 在 MySQL 5.7 中引入，以优化读写工作负载的并发性和可扩展性。

以下矩阵总结了 rw-lock 类型的兼容性。

	S	SX	X
S	Compatible	Compatible	Conflict
SX	Compatible	Conflict	Conflict
X	Conflict	Conflict	Conflict

另请参阅 闩锁、锁、互斥锁、性能模式。

S

savepoint

保存点有助于实现嵌套 事务。它们可以用于提供对表的操作范围，该表是更大事务的一部分。例如，在预订系统中预订旅行可能涉及预订多个不同的航班；如果所需的航班不可用，您可能 回滚 预订该航班所涉及的更改，而不回滚早些时候成功预订的航班。

另请参阅 回滚、事务。

scalability

系统在不降低性能的情况下增加更多工作和同时请求的能力。软件架构、硬件配置、应用程序编码和工作负载类型都对可扩展性产生影响。当系统达到其最大容量时，流行的技术来增加可扩展性是 scale up（增加现有硬件或软件的容量）和 scale out（添加新服务器和更多的 MySQL 实例）。通常与 可用性 配对，作为大规模部署的关键方面。

另请参阅 可用性、scale out、scale up。

scale out

通过添加新服务器和更多的 MySQL 实例来增加 可扩展性 的技术。例如，设置复制、NDB Cluster、连接池或其他跨多个服务器分布工作的功能。与 scale up 相比。

另请参阅 可扩展性、scale up。

scale up

一种通过增加现有硬件或软件的容量来提高可扩展性的技术。例如，增加服务器的内存并调整与内存相关的参数，如innodb_buffer_pool_size和innodb_buffer_pool_instances。与水平扩展相比。

另见 可扩展性，水平扩展。

schema

概念上，一个模式是一组相互关联的数据库对象，如表、表列、列的数据类型、索引、外键等。这些对象通过 SQL 语法相互连接，因为列组成了表，外键引用表和列等。理想情况下，它们也在逻辑上相互连接，作为统一应用程序或灵活框架的一部分。例如，INFORMATION_SCHEMA和performance_schema数据库在名称中使用““模式”，以强调它们包含的表和列之间的紧密关系。

在 MySQL 中，物理上，一个模式与一个数据库是同义的。你可以在 MySQL SQL 语法中使用关键字 SCHEMA 代替 DATABASE，例如使用 CREATE SCHEMA 代替 CREATE DATABASE。

其他一些数据库产品对其进行区分。例如，在 Oracle Database 产品中，一个模式仅代表数据库的一部分：由单个用户拥有的表和其他对象。

另见 数据库，INFORMATION_SCHEMA，Performance Schema。

SDI

““序列化词典信息””的缩写。

另见 序列化词典信息 (SDI)。

search index

在 MySQL 中，全文搜索查询使用特殊类型的索引，即 FULLTEXT 索引。在 MySQL 5.6.4 及更高版本中，InnoDB 和 MyISAM 表都支持 FULLTEXT 索引；以前，这些索引仅适用于 MyISAM 表。

另见 全文搜索，FULLTEXT 索引。

secondary index

一种 InnoDB 索引，表示表列的子集。一个 InnoDB 表可以有零个、一個或多个次要索引。（与 聚簇索引 相比，该索引是每个 InnoDB 表所需的，存储所有表列的数据。）

次要索引可以用于满足仅需要索引列的查询。对于更复杂的查询，可以用于标识表中的相关行，然后通过聚簇索引的查找来检索这些行。

创建和删除次要索引传统上需要从 InnoDB 表中复制所有数据。 快速索引创建 功能使得 CREATE INDEX 和 DROP INDEX 语句对于 InnoDB 次要索引变得非常快。

另见 聚簇索引，快速索引创建，索引。

segment

一个 InnoDB 表空间中的一个分区。如果表空间类似于目录，那么分区类似于目录中的文件。一个分区可以增长。新的分区可以被创建。

例如，在 每表文件 表空间中，表数据在一个分区中，每个关联索引在其自己的分区中。 系统表空间 包含许多不同的分区，因为它可以包含许多表和它们的关联索引。在 MySQL 8.0 之前，系统表空间还包括一个或多个 回滚分区，用于 撤销日志。

段落增长和缩小随着数据的插入和删除。当一个段需要更多的空间时，它将以一个 范围（1兆字节）为单位扩展。同样，当一个段中的所有数据都不再需要时，它将释放一个范围的空间。

另见 范围, 每个表文件, 回滚段, 系统表空间, 表空间, 撤销日志。

selectivity

数据分布的属性，列中的唯一值数（其 基数）除以表中的记录数。高选择性意味着列值相对唯一，可以通过索引高效地检索。如果您（或查询优化器）可以预测 WHERE 子句中的测试仅匹配表中的少数行，整个 查询倾向于高效，如果它首先评估该测试，使用索引。

另见 基数, 查询。

semi-consistent read

一种读取操作，用于 UPDATE 语句，即 提交读取 和 一致读取 的组合。当 UPDATE 语句检查已经锁定的行时，InnoDB 将最新的提交版本返回给 MySQL，以便 MySQL 确定该行是否匹配 WHERE 子句的条件。如果该行匹配（必须更新），MySQL 将重新读取该行，这时 InnoDB 将锁定该行或等待锁定该行。这种读取操作只能在事务具有提交读取 隔离级别 时发生。

另见 一致读取, 隔离级别, 提交读取。

SERIALIZABLE

隔离级别 使用最保守的锁定策略，以防止其他 事务 在当前事务完成之前插入或更改数据。这使得同一个查询可以在事务中多次运行，并确保每次都检索到相同的结果集。任何尝试更改自当前事务开始以来提交的数据的尝试都将导致当前事务等待。

这是 SQL 标准指定的默认隔离级别。在实践中，这种严格性很少需要，因此 InnoDB 的默认隔离级别是下一个最严格的，可重复读取。

另见 ACID, 一致读取, 隔离级别, 锁定, 可重复读取, 事务。

serialized dictionary information (SDI)

字典对象元数据的序列化形式。SDI 以 JSON 格式存储。

从 MySQL 8.0.3 开始，SDI 存在于所有 InnoDB 表空间文件中，除了临时表空间文件和撤销表空间文件。表空间文件中的 SDI 提供了元数据冗余。例如，使用 ibd2sdi 实用程序可以从表空间文件中提取字典对象元数据，如果数据字典不可用。

对于 MyISAM 表，SDI 存储在模式目录中的 .sdi 元数据文件中。SDI 元数据文件是执行 IMPORT TABLE 操作所需的。

另见 每个表文件, 通用表空间, 系统表空间, 表空间。

server

一种程序，持续运行，等待从另一个程序（客户端）接收和处理请求。由于通常整个计算机都是专门运行一个或多个服务器程序（例如数据库服务器、Web 服务器、应用程序服务器或这些的组合），因此术语“服务器”也可以指运行服务器软件的计算机。

另见 客户端, mysqld。

server-side prepared statement

由 MySQL 服务器管理的 预备语句。历史上，服务器端预备语句的问题导致 Connector/J 和 Connector/PHP 开发者有时使用 客户端预备语句。使用现代 MySQL 服务器版本，服务器端预备语句建议用于性能、可扩展性和内存效率。

另见 客户端预备语句, Connector/J, Connector/PHP, 预备语句。

service principal name

Kerberos 命名实体，表示服务。

另见 principal。

service ticket

提供对应用程序服务的访问的 Kerberos 票据，例如 Web 或数据库服务器提供的服务。

servlet

另见 Connector/J。

session temporary tablespace

一个 临时表空间，用于存储用户创建的 临时表 和优化器创建的内部临时表，当 InnoDB 配置为磁盘存储引擎时。

另见 优化器, 临时表, 临时表空间。

shared lock

一种 锁，允许其他 事务 读取锁定的对象，并获取其他共享锁，但不能写入它。与 排他锁 相反。

另见 排他锁, 锁, 事务。

shared tablespace

另一种方式来指代 系统表空间 或 通用表空间。通用表空间是在 MySQL 5.7 中引入的。多个表可以驻留在共享表空间中。只有一个表可以驻留在 每个表文件 表空间中。

另见 通用表空间, 系统表空间。

sharp checkpoint

将所有 脏 缓冲池页面的redo日志条目刷新到磁盘的过程，该过程发生在 InnoDB 重用日志文件的一部分之前；日志文件以循环方式使用。通常发生在写入密集型 工作负载 中。

另见 脏页, 刷新, redo日志, 工作负载。

shutdown

停止 MySQL 服务器的过程。默认情况下，该过程清理 InnoDB 表的操作，因此 InnoDB 可能会慢慢关闭，但下次启动时会很快。如果跳过清理操作，关闭将很快，但下次启动时必须执行清理。

停止模式由 innodb_fast_shutdown 选项控制。

另见 快速关闭, InnoDB, 慢速关闭, 启动。

slave

另见 副本。

slow query log

一种用于性能调整的日志，记录 MySQL 服务器处理的 SQL 语句。日志信息存储在文件中。您必须启用此功能以使用它。您可以控制哪些类别的 “慢” SQL 语句被记录。更多信息，请参见 第 7.4.5 节，“慢查询日志”。

另见 通用查询日志, 日志。

slow shutdown

一种 关闭，在完成之前执行额外的 InnoDB 刷新操作。也称为 清洁关闭。指定了配置参数 innodb_fast_shutdown=0 或命令 SET GLOBAL innodb_fast_shutdown=0;。虽然关闭本身可能需要更长时间，但是在后续启动时应该节省时间。

另见 清洁关闭, 快速关闭, 关闭。

snapshot

在特定时间点的数据表示，尽管其他 事务 提交了更改。用于某些 隔离级别，以允许 一致读取。

另见 提交, 一致读取, 隔离级别, 事务。

sort buffer

在创建 InnoDB 索引时用于排序数据的缓冲区。排序缓冲区大小由配置选项 innodb_sort_buffer_size 配置。

source

在 复制 场景中处理初始插入、更新和删除请求的数据库服务器机器。这些更改将被传播到其他服务器，称为 副本。

另见 副本, 复制。

space ID

用于唯一标识 InnoDB 表空间 的标识符。在 MySQL 实例中，系统表空间的空间 ID 始终为零；同一个 ID 适用于系统表空间或通用表空间中的所有表。每个 文件每表 表空间和 通用表空间 都有其自己的空间 ID。

在 MySQL 5.6 之前，这个硬编码值在将 InnoDB 表空间文件之间移动时引发了困难。从 MySQL 5.6 开始，您可以使用 可传输表空间 功能，使用语句 FLUSH TABLES ... FOR EXPORT、ALTER TABLE ... DISCARD TABLESPACE 和 ALTER TABLE ... IMPORT TABLESPACE。在复制表空间文件时，需要将空间 ID 信息包含在 .cfg 文件 中。请参见 第 17.6.1.3 节，“导入 InnoDB 表” 了解详细信息。

另见 .cfg 文件, 文件每表, 通用表空间, .ibd 文件, 系统表空间, 表空间, 可传输表空间。

sparse file

一种文件类型，使用文件系统空间更高效，通过将空块的元数据写入磁盘，而不是写入实际的空白空间。InnoDB 透明页压缩功能依赖稀疏文件支持。更多信息，请参见第 17.9.2 节，“InnoDB 页压缩”。

另见 洞 punching, 透明页压缩。

spin

一种 等待 操作，连续测试资源是否可用。这项技术用于通常仅持有资源的短暂时间，在这种情况下，在““忙循环” 中等待比让线程休眠并执行上下文切换更高效。如果资源在短时间内不可用，自旋循环将停止，并使用其他等待技术。

另见 闩, 锁, 互斥锁, 等待。

SPN

见 服务主体名称。

Spring

一个基于 Java 的应用程序框架，旨在通过提供组件配置方式来帮助应用程序设计。

另见 J2EE。

SQL

结构化查询语言（SQL），用于执行数据库操作。通常分为 DDL、DML 和 查询 三类。MySQL 还包括一些其他语句类别，如 复制。请参见 第 11 章，语言结构 了解 SQL 语法的构建块，第 13 章，数据类型 了解 MySQL 表列的数据类型，第 15 章，SQL 语句 了解 SQL 语句的详细信息和相关类别，以及 第 14 章，函数和操作符 了解标准和 MySQL 特定的函数用于查询。

另见 DDL, DML, 查询, 复制。

SQLState

由 JDBC 标准定义的错误代码，用于应用程序使用 Connector/J 的异常处理。

另见 Connector/J, JDBC。

SSD

“固态驱动器”的缩写。是一种存储设备，具有与传统硬盘驱动器（HDD）不同的性能特征：较小的存储容量，随机读取速度更快，无移动部件，并且写入性能受到多种因素的影响。其性能特征可以影响磁盘绑定的工作负载的吞吐量。

另见 磁盘绑定, HDD。

SSL

“安全套接字层”的缩写。为应用程序和 MySQL 数据库服务器之间的网络通信提供加密层。

另见 密钥库, 信任库。

ST

见 服务票据。

startup

启动 MySQL 服务器的过程。通常由 第 6.3 节，服务器和服务器启动程序 中列出的程序之一完成。与 关闭 相反。

另见 关闭。

statement interceptor

一种用于跟踪、调试或增强数据库应用程序所发出的 SQL 语句的 拦截器。有时也称为 命令拦截器。

在使用 Java 的应用程序中使用 Connector/J，设置这种类型的拦截器涉及实现 com.mysql.jdbc.StatementInterceptorV2 接口，并将 statementInterceptors 属性添加到 连接字符串 中。

在使用 Visual Studio 的应用程序中使用 Connector/NET，设置这种类型的拦截器涉及定义继承自 BaseCommandInterceptor 类的类，并将该类名指定为连接字符串的一部分。

另见 命令拦截器、连接字符串、Connector/J、Connector/NET、拦截器、Java、Visual Studio。

statement-based replication

一种形式的 复制，其中 SQL 语句从 源 发送并在 副本 上重放。它需要对 innodb_autoinc_lock_mode 选项的设置进行一些注意，以避免自动递增锁定的潜在计时问题。

另见 自动递增锁定、innodb_autoinc_lock_mode、副本、复制、基于行的复制、源。

statistics

与每个 InnoDB 表 和 索引 相关的估算值，用于构建高效的 查询执行计划。主要值是 基数（distinct 值的数量）和表行或索引条目的总数。表的统计信息代表其 主键 索引中的数据。索引的统计信息代表该索引所涵盖的行。

这些值是估算的，而不是精确计算的，因为在任何时候，不同的 事务 都可以在同一个表中插入和删除行。为了避免频繁地重新计算这些值，可以启用 持久统计信息，其中这些值将存储在 InnoDB 系统表中，并且只有在发出 ANALYZE TABLE 语句时才会刷新。

可以通过 innodb_stats_method 配置选项控制 NULL 值在统计信息计算中的处理方式。

其他类型的统计信息可通过 INFORMATION_SCHEMA 和 PERFORMANCE_SCHEMA 表获得。

另见 基数、索引、INFORMATION_SCHEMA、NULL、性能模式、持久统计信息、主键、查询执行计划、次要索引、表、事务。

stemming

能够根据共同的根词搜索不同变体的单词，如单数和复数，或者过去、现在和将来时态的动词。这项功能当前在 MyISAM 全文搜索 功能中支持，但不在 FULLTEXT 索引 中支持 InnoDB 表。

另见 全文搜索, FULLTEXT 索引。

stopword

在 FULLTEXT 索引 中，一个被认为是常见或琐碎的词语，以至于它被从 搜索索引 中省略，并在搜索查询中忽略。不同的配置设置控制 InnoDB 和 MyISAM 表的停用词处理。请参阅 第 14.9.4 节，“全文停用词” 了解详细信息。

另见 FULLTEXT 索引, 搜索索引。

storage engine

MySQL 数据库的一个组件，负责存储、更新和查询数据。在 MySQL 5.5 及更高版本中，InnoDB 是新表的默认存储引擎，取代了 MyISAM。不同的存储引擎具有不同的权衡，如内存使用量与磁盘使用量、读取速度与写入速度、速度与robustness 之间的权衡。每个存储引擎管理特定的表，因此我们称之为 InnoDB 表、MyISAM 表等。

MySQL Enterprise Backup 产品针对 InnoDB 表进行了优化，也可以备份 MyISAM 和其他存储引擎的表。

另见 InnoDB, MySQL Enterprise Backup, 表类型。

stored generated column

一列，其值来自列定义中的表达式。列值在插入或更新行时计算和存储。存储生成列需要存储空间，可以被索引。

与 虚拟生成列 相比。

另见 基准列, 生成列, 虚拟生成列。

stored object

存储程序或视图。

stored program

存储例程（过程或函数）、触发器或事件计划器事件。

stored routine

存储过程或函数。

strict mode

通用名称，控制由 innodb_strict_mode 选项控制的设置。启用该设置将某些通常被视为警告的条件视为错误。例如，某些无效的选项组合相关的 文件格式 和 行格式，通常会产生警告并使用默认值，现在会使 CREATE TABLE 操作失败。innodb_strict_mode 在 MySQL 5.7 中默认启用。

MySQL 还有一个严格模式。请参阅 第 7.1.11 节，“服务器 SQL 模式”。

另见 文件格式, innodb_strict_mode, 行格式。

sublist

在表示 缓冲池 的列表结构中，相对较旧和相对较新的页面由列表的不同部分表示。一些参数控制这些部分的大小和新旧页面之间的分界点。

另见 缓冲池, 驱逐, 列表, LRU。

supremum record

在索引中的一个 伪记录，表示该索引中最大的值以上的 间隙。如果事务中有语句如 SELECT ... FROM ... WHERE col > 10 FOR UPDATE;，且该列中的最大值为 20，那么它将锁定 supremum 记录，防止其他事务插入更大的值，如 50、100 等。

另见 间隙、最小记录、伪记录。

surrogate key

合成键 的同义词。

另见 合成键。

synthetic key

一个索引列，通常是一个 主键，其中的值是任意分配的。通常使用 自动递增 列。通过将值视为完全任意，可以避免过于严格的规则和错误的应用假设。例如，员工编号的数字序列可能会出现间隙，如果员工被批准录用但从未实际加入。或者，员工编号 100 的入职日期可能晚于员工编号 500 的入职日期，如果他们离开公司然后重新加入。数字值也可以生成较短的可预测长度的值。例如，存储表示 ““Road”、“Boulevard”、“Expressway” 等的数字代码比重复这些字符串更节省空间。

也称为 代理键。与 自然键 相对。

另见 自动递增、自然键、主键、代理键。

system tablespace

一个或多个数据文件 (ibdata 文件)，包含 InnoDB 相关对象的元数据、更改缓冲区 和 双写缓冲区 的存储区域。如果表是在系统表空间中创建的，而不是 每个文件表 或 通用表空间，那么它也可能包含表和索引数据。该系统表空间中的数据和元数据适用于 MySQL 实例 中的所有 数据库。

在 MySQL 5.6.7 之前，默认情况下所有 InnoDB 表和索引都存储在系统表空间中，这可能会导致该文件变得非常大。因为系统表空间从不缩小，因此如果加载了大量临时数据然后删除了它们，可能会出现存储问题。在 MySQL 8.0 中，默认情况下是 每个文件表 模式，其中每个表和其关联的索引都存储在一个单独的 .ibd 文件 中。这使得使用 InnoDB 功能变得更容易，如表 压缩、off-page 列 的高效存储和大索引键前缀。

将所有表数据存储在系统表空间或单独的 .ibd 文件中对存储管理有普遍的影响。MySQL Enterprise Backup 产品可能会备份少量的大文件或许多小文件。在具有数千个表的系统中，处理数千个 .ibd 文件的文件系统操作可能会导致瓶颈。

InnoDB 在 MySQL 5.7.6 中引入了通用表空间，也由 .ibd 文件表示。通用表空间是使用 CREATE TABLESPACE 语法创建的共享表空间。它们可以在数据目录外创建，能够容纳多个表，并支持所有行格式的表。

查看以下：更改缓冲区、压缩、数据字典、数据库、双写缓冲区、动态行格式、每表文件、通用表空间、.ibd 文件、ibdata 文件、InnoDB 每表文件、实例、MySQL 企业备份、非页列、表空间、撤销日志。

T