MySQL 8.4 Reference Manual  /  MySQL Glossary

MySQL 词汇表

这些术语通常用于 MySQL 数据库服务器的信息中。

.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

一个缩写,代表原子性、一致性、隔离性和持久性。这些属性都是数据库系统中所需的,并且都与事务概念紧密相关。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 树索引缓存在缓冲池中。

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

ADO.NET

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

另见 .NETASP.NETConnector/NETMonoVisual Studio

AIO

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

另见 异步 I/O

ANSI

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

另见 Connector/ODBCODBCUnicode

API

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

另见 C API客户端Connectornative C APIPerl APIPHP APIPython APIRuby 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的另一种服务器端Web页面技术是 PHP

另见 .NET, ADO.NET, Connector/NET, Mono, PHP, Visual Studio

assembly

.NET系统中的编译代码库,通过 Connector/NET 访问。存储在 GAC 中,以便在不产生命名冲突的情况下进行版本控制。

另见 .NET, GAC

asynchronous I/O

允许其他处理在I/O完成之前继续进行的I/O操作。也称为 非阻塞I/O,缩写为 AIOInnoDB 使用这种类型的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 中,提供初始票据所需的服务,以获取票据授予票据(TGT),从而从票据授予服务器(TGS)获取其他票据。身份验证服务器(AS)与 TGS 组合成密钥分发中心(KDC)。

另见 密钥分发中心票据授予服务器

auto-increment

表列的一个属性(由 AUTO_INCREMENT 关键字指定),该属性自动添加一个升序序列值到该列中。

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

自动递增列可能会在基于语句的复制中出现问题,因为在副本上重放语句可能不会生成与源相同的列值,原因是计时问题。当您拥有自动递增的主键时,可以使用基于语句的复制,只要设置 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

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

另见 自动递增并发性innodb_autoinc_lock_mode

autocommit

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

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

availability

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

另见 可扩展性

B-tree

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

因为 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 Backupmysqldump物理备份温备份

base column

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

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

beta

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

另见 早期采用者, GA

binary log

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

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

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

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

另见 binlog, MySQL Enterprise Backup, 复制

binlog

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

另见 二进制日志

blind query expansion

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

另见 全文搜索

BLOB

SQL 数据类型 (TINYBLOB, BLOB, MEDIUMBLOB, 和 LONGBLOB),用于存储任意大小的二进制数据,例如文档、图像、音频文件和其他无法轻松分解为表行和列的信息。在 MySQL 应用程序中处理 BLOB 的技术因 ConnectorAPI 而异。MySQL Connector/ODBCBLOB 值定义为 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

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

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

另见 关系型

.cfg file

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

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

C

一种编程语言,结合了可移植性和性能,并且可以访问低级硬件特性,使其成为编写操作系统、驱动程序和其他系统软件的流行选择。许多复杂的应用程序、语言和可重用模块都包含用 C 编写的部分,连接到高级组件上,使用其他语言编写。

另见 C APIC++C#Java

C API

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

另见 APIClibmysqlclient

C#

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

另见 .NETASP.netCConnector/NETC++JavaMono

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, UPDATEDELETE 语句 (DML)。该功能集称为 更改缓冲,包括 插入缓冲删除缓冲清除缓冲

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

物理上,更改缓冲是 系统表空间 的一部分,因此索引更改在数据库重启之间保持缓冲。只有当页面被带入缓冲池时,才应用 (合并) 更改。

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

以前称为 插入缓冲区

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

change buffering

一般术语,指涉及 更改缓冲区 的功能,包括 插入缓冲删除缓冲清除缓冲。索引更改来自 SQL 语句,可能涉及随机 I/O 操作,这些操作将被延迟并由后台 线程 定期执行。该序列操作可以更高效地写入磁盘块,以便于一系列索引值。由 innodb_change_bufferinginnodb_change_buffer_max_size 配置选项控制。

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

checkpoint

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

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

checksum

InnoDB 中,用于检测磁盘上 的腐败的验证机制,当从磁盘读取到 InnoDB 缓冲池 中时。该功能由 innodb_checksums 配置选项控制,在 MySQL 5.5 中有效。innodb_checksums 在 MySQL 5.6.3 中已弃用,取而代之的是 innodb_checksum_algorithm

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

MySQL 也使用 checksums 用于复制目的。有关详细信息,请参阅配置选项 binlog_checksumsource_verify_checksummaster_verify_checksum,以及 replica_sql_verify_checksumslave_sql_verify_checksum

另请参阅 缓冲池表空间

child table

在外键关系中,子表是指其行引用(或指向)另一个表中具有相同值的特定列的行。这是包含 FOREIGN KEY ... REFERENCES 子句和可选 ON UPDATEON DELETE 子句的表。相应的行在父表中必须存在,然后才能在子表中创建行。子表中的值可以防止父表上的删除或更新操作,或者可以根据创建外键时使用的 ON CASCADE 选项自动删除或更新子表中的行。

另请参阅 外键父表

clean page

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

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

clean shutdown

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

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

client

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

另请参阅 API客户端库Connectormysql服务器

client libraries

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

另请参阅 客户端libmysqlclient

client-side prepared statement

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

另见 Connector/JConnector/ODBCConnector/PHP预备语句

CLOB

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

另见 APIBLOBconnectorConnector/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_levelinnodb_compression_failure_threshold_pctinnodb_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.cnfMySQL Enterprise Backup选项选项文件

connection

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

另请参阅 连接池连接字符串Connector/NETConnector/ODBCDSN主机端口

connection pool

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

另请参阅 连接Connector/JJ2EETomcat

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 的 plain C 应用程序开发成为可能。它还使得使用 Connector/C++ 1.1 的 JDBC-based API 的 C++ 应用程序开发成为可能。详见 MySQL Connector/C++ 8.4 开发者指南

另见 客户端, 连接器, JDBC

Connector/J

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

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

Connector/NET

一个 MySQL 连接器,为使用语言、技术和框架如 C#.NETMonoVisual StudioASP.netADO.net 的开发者提供连接性。

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

Connector/ODBC

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

另见 连接器, ODBC

Connector/PHP

一个版本的 mysqlmysqli API,为 PHP 优化,适用于 Windows 操作系统。

也见 连接器PHPPHP API

consistent read

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

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

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

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

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

constraint

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

也见 ACID外键唯一约束

counter

特定 InnoDB 操作递增的值。有助于衡量服务器的繁忙程度、排除性能问题的来源,并测试配置设置或查询使用的索引是否产生了预期的低级别效果。不同的计数器可通过 性能架构 表和 信息架构 表获得,特别是 INFORMATION_SCHEMA.INNODB_METRICS

也见 信息架构度量计数器性能架构

covering index

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

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

也见 列索引复合索引索引主键次要索引

CPU-bound

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

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

crash

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

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

crash recovery

MySQL 在崩溃后重新启动时的清理活动。对于 InnoDB 表,使用 重做日志 中的数据来重放未完成的事务更改。在崩溃前提交但尚未写入 数据文件 的更改,从 双写缓冲区 中重建。当数据库正常关闭时,这种活动在关闭期间由 清理 操作执行。

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

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

CRUD

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

另见 DDL, DML, 查询, SQL

cursor

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

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

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

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 中,包括 GRANTREVOKE 语句。与 DDLDML 相比。

另见 DDLDMLSQL

DDEX provider

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

另见 Visual Studio

DDL

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

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

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

DMLDCL 相比。

查看 提交, DCL, DML, 每个表文件, 回滚, SQL, 事务

deadlock

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

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

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

查看 间隙, , 事务

deadlock detection

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

查看 死锁, 回滚, 事务, 受害者

delete

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

查看 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 语句,用于执行 INSERTUPDATEDELETE 操作。 SELECT 语句有时被认为是 DML 语句,因为 SELECT ... FOR UPDATE 形式受到与 INSERTUPDATEDELETE 相同的锁定考虑。

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

DDLDCL 相比。

另见 提交DCLDDL锁定回滚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 TABLEDROP 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, 预备语句

early adopter

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

另见 beta

Eiffel

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

另见 APIC#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/JConnector/NET拦截器JavaVisual Studio

exclusive lock

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

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

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。

查看 Also 双写缓冲区, , 页大小, 预读取, , 表空间

.frm file

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

查看 Also 数据词典, MySQL Enterprise Backup, 系统表空间

failover

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

查看 Also Connector/J, J2EE

Fast Index Creation

首先在 InnoDB 插件中引入,现在是 MySQL 5.5 及更高版本的一部分,用于加速创建 InnoDB 次要索引 的速度,避免了完全重写关联表的需要。该速度提升也适用于删除次要索引。

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

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

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

查看 Also DML, 索引, 在线 DDL, 次要索引

fast shutdown

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

一种技术,刷新 小批量 脏页缓冲池 中,而不是刷新所有脏页,以免中断数据库处理。

另见 缓冲池, 脏页, 刷新

GA

一般可用,软件产品离开 beta 阶段并可供销售、官方支持和生产使用时的阶段。

另见 beta

GAC

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

另见 .NETassembly

gap

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

另见 并发间隙锁索引infimum 记录隔离级别supremum 记录

gap lock

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

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

另见 间隙infimum 记录next-key 锁记录锁supremum 记录

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_nameALTER 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 表的主键的高效选择。

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 透明页压缩 功能依赖于 hole 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, 准备备份, 原始备份

.ibd file

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

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

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

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

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

.ibz file

MySQL Enterprise Backup 产品执行 压缩备份 时,它将每个使用 文件每表 设置创建的表空间文件从 .ibd 扩展名转换为 .ibz 扩展名。

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

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

I/O-bound

另见 磁盘绑定

ib-file set

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

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

ibbackup_logfile

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

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

ibdata file

一组文件,名称如 ibdata1ibdata2 等,组成 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_logfile0ib_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 INDEXUSE INDEXIGNORE 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.TABLESINFORMATION_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 表和关联索引可以存储在单独的文件中,位于 系统表空间 之外的 .ibd 文件 中。

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

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

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

另见 压缩, 每表文件, .ibd 文件, MySQL Enterprise Backup, 系统表空间

innodb_lock_wait_timeout

innodb_lock_wait_timeout 选项设置了等待共享资源可用之间的平衡,或者放弃并处理错误、重试或在应用程序中执行备用处理。回滚任何等待超过指定时间以获取锁定的 InnoDB 事务。特别有用的是,如果 死锁 是由多个表的更新所引起的,这些表由不同的存储引擎控制;这些死锁不会自动 检测

另见 死锁, 死锁检测, , 等待

innodb_strict_mode

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

另见 严格模式

Innovation Series

带有相同主要版本的创新版本形成了创新系列。例如,MySQL 8.1 到 8.3 形成了 MySQL 8 创新系列。

另见 LTS 系列

insert

SQL 中的一种主要 DML 操作。在数据仓库系统中,插入性能是关键因素,因为它们需要加载数百万行到表中,而在 OLTP 系统中,许多并发连接可能会插入行到同一个表中,以任意顺序。如果插入性能对您很重要,您应该了解 InnoDB 的功能,例如 插入缓冲区更改缓冲 中的使用,以及 自动递增 列。

另见 自动递增, 更改缓冲, 数据仓库, DML, InnoDB, 插入缓冲区, OLTP, SQL

insert buffer

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

另见 更改缓冲区, 更改缓冲

insert buffering

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

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

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

insert intention lock

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

另见 间隙锁, , 下一个键锁

instance

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

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

instrumentation

在源代码级别对性能数据进行修改,以便进行调整和调试。在 MySQL 中,通过 SQL 接口使用 INFORMATION_SCHEMAPERFORMANCE_SCHEMA 数据库来公开收集的数据。

另见 INFORMATION_SCHEMA, 性能模式

intention exclusive lock

另见 意图锁

intention lock

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

另见 锁模式锁机制事务

intention shared lock

另见 意图锁

interceptor

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

另见 命令拦截器Connector/JConnector/NET异常拦截器

intrinsic temporary table

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

另见 优化器

inverted index

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

另见 全文搜索FULLTEXT 索引ilist

IOPS

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

另见 磁盘绑定OLTP可扩展性

isolation level

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

从最高的一致性和保护到最低,InnoDB 支持的隔离级别是:SERIALIZABLEREPEATABLE READREAD COMMITTEDREAD UNCOMMITTED

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

查看 ACIDOLTPREAD COMMITTEDREAD UNCOMMITTEDREPEATABLE READSERIALIZABLE事务

J2EE

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

查看 连接池Connector/J故障转移JavaJBossSpringTomcat

Java

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

查看 CConnector/JC++JDBC

JBoss

查看 J2EE

JDBC

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

查看 APIConnector/JJ2EEJava

JNDI

查看 Java

join

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

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

KDC

查看 密钥分发中心

key distribution center

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

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

keystore

查看 SSL

KEY_BLOCK_SIZE

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

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

另见 压缩行格式

latch

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

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

libmysql

非正式名称为 libmysqlclient 库。

另见 libmysqlclient

libmysqlclient

库文件,名为 libmysqlclient.alibmysqlclient.so,通常链接到 客户端 程序中,编写语言为 C。有时非正式地称为 libmysqlmysqlclient 库。

另见 客户端libmysqlmysqlclient

libmysqld

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

另见 客户端嵌入式libmysqllibmysqlclient

lifecycle interceptor

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

另见 Connector/J拦截器

list

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

另见 缓冲池驱逐LRU子列表

load balancing

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

另见 Connector/JJ2EE

localhost

另见 连接

lock

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

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

lock escalation

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

另见 锁定行锁表锁

lock mode

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

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

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

另见 意图锁锁定事务

locking

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

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

locking read

一条也执行锁定操作的 SELECT 语句,例如 SELECT ... FOR UPDATESELECT ... LOCK IN SHARE MODE。它可能会产生 死锁,取决于事务的 隔离级别。与 非锁定读取 相反。在只读事务中不允许对全局表进行锁定。

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

参见 第 17.7.2.4 节,“锁定读取”

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

log

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

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

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

log buffer

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

另见 日志文件重做日志

log file

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

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

log group

组成 重做日志 的文件集,通常命名为 ib_logfile0ib_logfile1。(因此,有时统称为 ib_logfile。)

另见 ib_logfile重做日志

logical

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

另见 逻辑备份物理

logical backup

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

另见 备份, mysqldump, 物理备份, 恢复

loose_

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

另见 启动

low-water mark

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

另见 高水位标记

LRU

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

另见 缓冲池, 驱逐, 全表扫描, 中点插入策略,

LSN

“日志序列号”(Log Sequence Number)的缩写。该任意、不断增加的值表示操作记录在 重做日志 中的时间点。(该时间点不考虑 事务 边界;它可以落在一个或多个事务中间。)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, 重做日志, 事务

LTS Series

具有相同主要版本号的 LTS 版本形成一个 LTS 系列。例如,所有 MySQL 8.4.x 版本形成 MySQL 8.4 LTS 系列。

注意:MySQL 8.0 是一个 Bugfix 系列,先于 LTS 发布模型。

另见 创新系列

.MRG file

一个包含对其他表的引用的文件,用于 MERGE 存储引擎。具有该扩展名的文件总是包含在 mysqlbackup 命令的备份中,来自 MySQL Enterprise Backup 产品。

另见 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 服务器使用 NDB 表进行通信。这些 NoSQL 接口到 MySQL 表允许应用程序实现比直接发出 SQL 语句更高的读取和写入性能,并可以简化应用程序逻辑和部署配置对于已经包含 memcached 的系统。

另见 NoSQL

merge

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

另见 缓冲池, 更改缓冲区, 刷新, 表空间

metadata lock

一种类型的 ,防止 DDL 操作在同一时间由另一个 事务 使用的表上。详见 第 10.11.4 节,“元数据锁定”

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

另见 DDL在线事务

metrics counter

在 MySQL 5.6 及更高版本中,INNODB_METRICS 表中的一个功能,在 INFORMATION_SCHEMA 中实现的。您可以查询 计数器 和总数的低级 InnoDB 操作,并将结果与 性能模式 的数据结合使用,以进行性能调整。

另见 计数器INFORMATION_SCHEMA性能模式

midpoint insertion strategy

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

另见 缓冲池全表扫描LRU

mini-transaction

InnoDB 处理的内部阶段,在 物理 级别上对内部数据结构进行更改期间的 DML 操作。小事务(mtr)没有 回滚 的概念;多个小事务可以在单个 事务 中发生。小事务将信息写入 重做日志,用于 崩溃恢复。小事务也可以在常规事务之外发生,例如在后台线程的 清理 处理期间。

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

mixed-mode insert

一个 INSERT 语句,其中 自动递增 值仅指定了一些新行,而不是所有行。例如,多值 INSERT 可能会指定某些情况下的自动递增列值,而在其他情况下指定为 NULLInnoDB 会生成自动递增值,用于那些列值指定为 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/NETC#应用程序在Linux平台上工作。

另见 Connector/NET, C#

mtr

mini-transaction

multi-core

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

multiversion concurrency control

MVCC

mutex

非正式缩写为“互斥变量。(Mutex本身是“互斥排除的缩写。)InnoDB使用的低级对象,用于表示和实施对内部内存数据结构的独占访问。一旦获取锁,就会阻止其他进程、线程等获取相同的锁。与rw-locks相比,InnoDB使用rw-locks来表示和实施对内部内存数据结构的共享访问。Mutexes和rw-locks统称为

另见 , , 性能模式, Pthreads, rw-lock

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守护进程。

另见mysqldSQL

MySQL Enterprise Backup

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

另见热备份InnoDB

mysqlbackup command

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

另见热备份MySQL Enterprise Backup温备份

mysqlclient

库文件的非正式名称,扩展名为.a.so

另见libmysqlclient

mysqld

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

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

另见实例mysql

MySQLdb

开源Python模块的名称,该模块是 MySQL Python API的基础。

另见PythonPython API

mysqldump

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

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

.NET

另见ADO.NETASP.netConnector/NETMonoVisual 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 UPDATESELECT ... 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操作的灵活性和便捷性。

另请参阅 ACIDmemcached模式SQL

NOT NULL constraint

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

另请参阅 约束NULL主键参照完整性

NULL

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

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

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

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

另见 索引主键SQL

.OPT file

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

另见 MySQL Enterprise Backupmysqlbackup 命令

ODBC

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

另见 Connector/ODBC

off-page column

包含可变长度数据(例如 BLOBVARCHAR)的列,该数据太长无法存储在 B-tree 页上。数据存储在 溢出页 中。DYNAMIC 行格式比旧的 COMPACT 行格式更适合这种存储。

另见 B-treecompact 行格式dynamic 行格式溢出页

OLTP

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

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

另见 数据仓库DMLInnoDB查询行锁事务

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.cnfmy.ini选项

overflow page

单独分配的磁盘 ,用于存储变长列(如 BLOBVARCHAR)这些列太长,无法容纳在 B 树 页上。这些列被称为 离页列

另见 B 树离页列

.par file

包含分区定义的文件。该扩展名文件包含在由 mysqlbackup 命令生成的备份中,该命令来自 MySQL 企业备份 产品。

随着 MySQL 5.7.6 中引入的原生分区支持,.par 文件不再为分区的 InnoDB 表创建。在 MySQL 5.7 中,分区的 MyISAM 表继续使用 .par 文件。从 MySQL 8.0 开始,分区支持仅由 InnoDB 存储引擎提供。因此,.par 文件不再使用自 MySQL 8.0 起。

另见 MySQL 企业备份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 表空间,包括 系统表空间每个表的表空间通用表空间

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

另见 磁盘绑定每个表的表空间通用表空间实例OLTPSSD系统表空间表空间

parent table

外键 关系中,持有初始列值的表,指向 子表。根据 ON UPDATEON 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 应用程序编写的开源 APIPerl 语言。通过 DBIDBD::mysql 模块实现。详细信息,请参阅 第 31.9 节,“MySQL Perl API”

另见 APIPerl

persistent statistics

一个存储 索引 统计信息的功能,以提供更好的 计划稳定性,用于 查询。详细信息,请参阅 第 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.netCPHP 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

点时恢复 的缩写。

另见 点时恢复

plan stability

一个 查询执行计划 的属性,其中优化器每次为给定的 查询 选择相同的选择,以便性能是一致和可预测的。

另见 查询, 查询执行计划

point-in-time recovery

备份 恢复到数据库的特定日期和时间。通常缩写为 PITR。因为指定的时间可能不正好对应备份的时间,因此该技术通常需要结合 物理备份逻辑备份。例如,使用 MySQL Enterprise Backup 产品,恢复在指定时间之前的最后一个备份,然后从备份时间到 PITR 时间重放 二进制日志 中的更改。

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

port

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

另见 连接, 主机, SSL

prefix

另见 索引前缀

prepared backup

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

也见:二进制日志热备份增量备份MySQL Enterprise Backup原始备份恢复

prepared statement

预先分析的 SQL 语句,以确定高效的执行计划。它可以多次执行,而不需要每次都进行解析和分析。每次可以通过使用占位符将不同的值替换到 WHERE 子句中,这种替换技术可以提高安全性,防止某些类型的 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 解析和处理 撤销日志 页面,从 历史列表 中删除聚簇和次要索引记录,这些记录以前被标记为删除(由之前的 DELETE 语句)且不再需要用于 MVCC回滚。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

query

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

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

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

query execution plan

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

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

query log

另请参阅 通用查询日志

quiesce

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

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

另见备份刷新InnoDB关闭

R-tree

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

另见B-tree

RAID

缩写为“廉价磁盘冗余阵列”。将I/O操作分布在多个驱动器上,能够在硬件级别上实现更高的并发性,并提高低级写操作的效率,否则这些操作将按顺序执行。

另见并发性

random dive

一种快速估算列中不同值的数量(列的基数)。InnoDB从索引中随机抽样页面,并使用该数据来估算不同值的数量。

另见基数

raw backup

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

另见二进制日志热备份ibbackup_logfile增量备份MySQL Enterprise Backupprepared backup恢复

READ COMMITTED

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

当事务具有该隔离级别时,执行UPDATE... WHEREDELETE... WHERE操作时,其他事务可能需要等待。事务可以执行SELECT... FOR UPDATELOCK 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

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

另见 隔离级别, 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 值表示通过重做日志传输的累积重做数据量。

另见 崩溃恢复DMLLSN重做日志事务

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。您仍然可以指定 REDUNDANT 行格式,以与旧的 InnoDB 表保持兼容。

更多信息,请参见 第 17.10 节,“InnoDB 行格式”

另见 compact 行格式dynamic 行格式行格式

referential integrity

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

另见 ACIDFOREIGN KEY 约束NOT NULL 约束唯一约束

relational

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

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

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

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

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

relevance

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

另见 全文搜索, FULLTEXT索引

REPEATABLE READ

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

当事务具有这种隔离级别时,执行 UPDATE ... WHEREDELETE ... WHERESELECT ... FOR UPDATELOCK IN SHARE MODE 操作时,其他事务可能需要等待。

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

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

repertoire

库是字符集的一个术语。字符集库是集合中的字符集。见 第 12.2.1 节,“字符集库”

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 语法的一致性,但行格式是每个表的属性,并应用于该表中的所有行。

See Also column, data files, page, row format, table.

row format

The disk storage format for rows of an InnoDB table. As InnoDB gains new capabilities such as compression, new row formats are introduced to support the resulting improvements in storage efficiency and performance.

The row format of an InnoDB table is specified by the ROW_FORMAT option or by the innodb_default_row_format configuration option (introduced in MySQL 5.7.9). Row formats include REDUNDANT, COMPACT, COMPRESSED, and DYNAMIC. To view the row format of an InnoDB table, issue the SHOW TABLE STATUS statement or query InnoDB table metadata in the INFORMATION_SCHEMA.

See Also compact row format, compressed row format, compression, dynamic row format, redundant row format, row, table.

row lock

A lock that prevents a row from being accessed in an incompatible way by another transaction. Other rows in the same table can be freely written to by other transactions. This is the type of locking done by DML operations on InnoDB tables.

Contrast with table locks used by MyISAM, or during DDL operations on InnoDB tables that cannot be done with online DDL; those locks block concurrent access to the table.

See Also DDL, DML, InnoDB, lock, locking, online DDL, table lock, transaction.

row-based replication

A form of replication where events are propagated from the source specifying how to change individual rows on the replica. It is safe to use for all settings of the innodb_autoinc_lock_mode option.

See Also auto-increment locking, innodb_autoinc_lock_mode, replica, replication, source, statement-based replication.

row-level locking

The locking mechanism used for InnoDB tables, relying on row locks rather than table locks. Multiple transactions can modify the same table concurrently. Only if two transactions try to modify the same row does one of the transactions wait for the other to complete (and release its row locks).

另见 InnoDB锁定行锁表锁事务

Ruby

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

另见 APIPerlRuby API

Ruby API

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

另见 libmysqlRuby

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 兼容 兼容 冲突
SX 兼容 冲突 冲突
X 冲突 冲突 冲突

另见 闩锁互斥锁性能模式

savepoint

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

另见 回滚事务

scalability

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

另见 可用性水平扩展扩展

scale out

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

另见 可扩展性扩展

scale up

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

See Also 可扩展性, 水平扩展

schema

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

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

其他一些数据库产品对模式的定义不同。例如,在 Oracle 数据库产品中,一个模式仅代表数据库的一部分:由单个用户拥有的表和其他对象。

See Also 数据库, INFORMATION_SCHEMA, 性能模式

SDI

序列化字典信息”的缩写。

See Also 序列化字典信息 (SDI)

search index

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

See Also 全文搜索, FULLTEXT 索引

secondary index

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

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

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

See Also 聚簇索引, 快速索引创建, 索引

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

将所有脏缓冲池页面刷新到磁盘,这些页面的重做日志条目包含在某个重做日志部分中。发生在 InnoDB 重用日志文件的一部分之前;日志文件以循环方式使用。通常发生在写入密集型工作负载中。

另见 脏页, 刷新, 重做日志, 工作负载

shutdown

停止 MySQL 服务器的过程。默认情况下,该过程清理 InnoDB 表的操作,因此 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 EXPORTALTER TABLE... DISCARD TABLESPACEALTER TABLE... IMPORT TABLESPACE。在传输表空间文件时,需要传输的信息包含在 .cfg 文件 中。请参阅 第 17.6.1.3 节,“导入 InnoDB 表” 了解详细信息。

另见 .cfg 文件, 文件每表, 通用表空间, .ibd 文件, 系统表空间, 表空间, 可传输表空间

sparse file

一种文件类型,使用文件系统空间更高效,通过将空块的元数据写入磁盘,而不是写入实际的空白空间。InnoDB透明页压缩 功能依赖于稀疏文件支持。更多信息,请参阅 第 17.9.2 节,“InnoDB 页压缩”

另见 洞 punching, 透明页压缩

spin

一种 等待 操作,连续测试资源是否可用。这项技术用于通常仅持有资源很短时间的资源,在这种情况下,在“忙循环 中等待比将线程置于睡眠状态并执行上下文切换更高效。如果资源在短时间内不可用,自旋循环将停止,并使用其他等待技术。

另见 latch, , 互斥锁, 等待

SPN

另见 服务主体名称

Spring

一个基于 Java 的应用程序框架,旨在通过提供组件配置方式来帮助应用程序设计。

另见 J2EE

SQL

结构化查询语言(SQL),用于执行数据库操作。通常分为 DDLDML查询 三类。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 节,“服务器和服务器启动程序” 中列出的程序之一完成。与 shutdown 相反。

另见 shutdown

statement interceptor

一种用于跟踪、调试或增强数据库应用程序所发出的 SQL 语句的 拦截器。有时也称为 命令拦截器

在使用 Connector/JJava 应用程序中,设置这种类型的拦截器涉及实现 com.mysql.jdbc.StatementInterceptorV2 接口,并将 statementInterceptors 属性添加到 连接字符串 中。

在使用 Connector/NETVisual Studio 应用程序中,设置这种类型的拦截器涉及定义继承自 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_SCHEMAPERFORMANCE_SCHEMA 表获得。

另见 基数, 索引, INFORMATION_SCHEMA, NULL, 性能模式, 持久统计信息, 主键, 查询执行计划, 次要索引, , 事务

stemming

能够根据共同的根词搜索不同变体的单词,例如单数和复数,或者过去、现在和将来时态的动词。该功能当前支持在 MyISAM 全文搜索 功能中,但不支持 FULLTEXT 索引 中的 InnoDB 表。

另见 全文搜索, FULLTEXT 索引

stopword

FULLTEXT 索引 中,一个被认为是常见或琐碎的词语,以至于它被从 搜索索引 中省略并在搜索查询中忽略。不同的配置设置控制 InnoDBMyISAM 表的停用词处理。详见 第 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

A pseudo-record in an index, representing the gap above the largest value in that index. If a transaction has a statement such as SELECT ... FROM ... WHERE col > 10 FOR UPDATE;, and the largest value in the column is 20, it is a lock on the supremum record that prevents other transactions from inserting even larger values such as 50, 100, and so on.

See Also gap, infimum record, pseudo-record.

surrogate key

Synonym name for synthetic key.

See Also synthetic key.

synthetic key

An indexed column, typically a primary key, where the values are assigned arbitrarily. Often done using an auto-increment column. By treating the value as completely arbitrary, you can avoid overly restrictive rules and faulty application assumptions. For example, a numeric sequence representing employee numbers might have a gap if an employee was approved for hiring but never actually joined. Or employee number 100 might have a later hiring date than employee number 500, if they left the company and later rejoined. Numeric values also produce shorter values of predictable length. For example, storing numeric codes meaning Road, Boulevard, Expressway, and so on is more space-efficient than repeating those strings over and over.

Also known as a surrogate key. Contrast with natural key.

See Also auto-increment, natural key, primary key, surrogate key.

system tablespace

One or more data files (ibdata files) containing the metadata for InnoDB-related objects, and the storage areas for the change buffer, and the doublewrite buffer. It may also contain table and index data for InnoDB tables if tables were created in the system tablespace instead of file-per-table or general tablespaces. The data and metadata in the system tablespace apply to all databases in a MySQL instance.

Prior to MySQL 5.6.7, the default was to keep all InnoDB tables and indexes inside the system tablespace, often causing this file to become very large. Because the system tablespace never shrinks, storage problems could arise if large amounts of temporary data were loaded and then deleted. In MySQL 8.0, the default is file-per-table mode, where each table and its associated indexes are stored in a separate .ibd file. This default makes it easier to use InnoDB features that rely on DYNAMIC and COMPRESSED row formats, such as table compression, efficient storage of off-page columns, and large index key prefixes.

Keeping all table data in the system tablespace or in separate .ibd files has implications for storage management in general. The MySQL Enterprise Backup product might back up a small set of large files, or many smaller files. On systems with thousands of tables, the file system operations to process thousands of .ibd files can cause bottlenecks.

InnoDB introduced general tablespaces in MySQL 5.7.6, which are also represented by .ibd files. General tablespaces are shared tablespaces created using CREATE TABLESPACE syntax. They can be created outside of the data directory, are capable of holding multiple tables, and support tables of all row formats.

也见 更改缓冲区压缩数据字典数据库双写缓冲区动态行格式每表文件通用表空间.ibd 文件ibdata 文件InnoDB 每表文件实例MySQL Enterprise 备份非页列表空间撤销日志

table

每个 MySQL 表都与特定的 存储引擎 相关联。InnoDB 表具有特定的 物理逻辑 特征,这些特征影响性能、可扩展性备份、管理和应用程序开发。

在文件存储方面,InnoDB 表属于以下表空间类型之一:

  • 共享的 InnoDB 系统表空间,由一个或多个 ibdata 文件 组成。

  • 一个 每表文件 表空间,由一个单独的 .ibd 文件 组成。

  • 一个共享的 通用表空间,由一个单独的 .ibd 文件组成。通用表空间是在 MySQL 5.7.6 中引入的。

.ibd 数据文件包含表和 索引 数据。

InnoDB 表在每表文件表空间中可以使用 DYNAMICCOMPRESSED 行格式。这些行格式启用 InnoDB 功能,如 压缩、非页列的高效存储和大索引键前缀。通用表空间支持所有行格式。

系统表空间支持使用 REDUNDANTCOMPACTDYNAMIC 行格式的表。系统表空间对 DYNAMIC 行格式的支持是在 MySQL 5.7.6 中添加的。

InnoDB 表的 按照 聚簇索引 结构组织,按照表的 主键 列排序。数据访问针对主键列的查询和排序进行了优化,每个索引包含关联主键列的副本。修改主键列的值是一个昂贵的操作。因此,InnoDB 表设计的重要方面是选择一个主键,以便在最重要的查询中使用,并保持主键短小,具有不常更改的值。

也见 备份聚簇索引紧凑行格式压缩行格式压缩动态行格式快速索引创建每表文件.ibd 文件索引非页列主键冗余行格式系统表空间表空间

table lock

防止其他任何 事务 访问表的锁。 InnoDB 通过使用诸如 在线 DDL行锁一致读取 等技术来尽量减少这种锁的使用。在 SQL 中,您可以使用 LOCK TABLE 语句创建这种锁;在从其他数据库系统或 MySQL 存储引擎迁移到时,需要尽量删除这些语句。

另见 一致读取DML锁定在线 DDL查询行锁事务

table scan

另见 全表扫描

table statistics

另见 统计信息

table type

已弃用的同义词 存储引擎。我们指的是 InnoDB 表、MyISAM 表等。

另见 InnoDB存储引擎

tablespace

可以容纳一个或多个 InnoDB 和关联的 索引 的数据文件。

系统表空间 包含 InnoDB 数据字典,在 MySQL 5.6 之前,默认情况下包含所有其他 InnoDB 表。

innodb_file_per_table 选项,在 MySQL 5.6 及更高版本中默认启用,允许表创建在自己的表空间中。文件每表表空间支持功能,如 离页列 的高效存储、表压缩和可移植表空间。详见 第 17.6.3.2 节,“文件每表表空间”

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

MySQL NDB Cluster 也将其表分组到表空间中。详见 第 25.6.11.1 节,“NDB Cluster 磁盘数据对象”

另见 压缩行格式数据字典数据文件文件每表通用表空间索引innodb_file_per_table系统表空间

Tcl

来自 Unix 脚本世界的编程语言。有时由 CC++Java 代码扩展。对于 MySQL 的开源 Tcl API,请参阅 第 31.12 节,“MySQL Tcl API”

另见 API

temporary table

一个不需要永久保存的表。例如,临时表可能用作复杂计算或转换的中间结果存储区域;这些中间数据在崩溃后不需要恢复。数据库产品可以采取各种捷径来提高临时表操作的性能,例如减少对磁盘的写入和其他保护数据的措施。

有时,数据本身会在设定的时间自动删除,例如事务结束或会话结束时。一些数据库产品还会自动删除表本身。

参见

temporary tablespace

InnoDB 使用两种类型的临时表空间。会话临时表空间 存储用户创建的临时表和优化器创建的内部临时表。全局临时表空间 存储用户创建的临时表的回滚段。

参见 全局临时表空间会话临时表空间临时表

text collection

FULLTEXT 索引中包含的列集。

参见 FULLTEXT 索引

TGS

一个 Kerberos 票据授予服务器。TGS 也可以指票据授予服务器提供的票据授予服务。

参见 票据授予服务器

TGT

参见 票据授予票据

thread

一个处理单元,通常比 进程 轻量级,允许更高的 并发性

参见 并发性主线程进程Pthreads

ticket-granting server

在 Kerberos 中,提供票据的服务器。票据授予服务器(TGS)与身份验证服务器(AS)组合成密钥分配中心(KDC)。

TGS 也可以指票据授予服务器提供的票据授予服务。

参见 身份验证服务器密钥分配中心

ticket-granting ticket

在 Kerberos 中,票据授予票据呈递给票据授予服务器(TGS),以获取服务票据用于服务访问。

参见 票据授予服务器

Tomcat

一个开源的 J2EE 应用服务器,实现 Java Servlet 和 JavaServer Pages 编程技术。由 Web 服务器和 Java Servlet 容器组成。与 MySQL 一起使用时,通常与 Connector/J 一起使用。

参见 J2EE

torn page

一个可能由于 I/O 设备配置和硬件故障而出现的错误条件。如果数据以小于 InnoDB 页大小(默认为 16KB)的块写入,硬件故障可能会导致只有部分页被写入磁盘。InnoDB 双写缓冲区 防止这种可能性。

参见 双写缓冲区

TPS

“每秒事务数”的缩写,一个衡量单位,有时用于基准测试。其值取决于特定基准测试的 工作负载,结合您控制的硬件能力和数据库配置等因素。

参见 事务工作负载

transaction

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

数据库事务,如InnoDB所实现的那样,有着共同的ACID属性,即原子性、一致性、隔离性和持久性。

另见 ACID, 提交, 隔离级别, , 回滚

transaction ID

每行关联的内部字段。该字段由 INSERT, UPDATEDELETE 操作修改,以记录哪个 事务 锁定了该行。

另见 隐式行锁, , 事务

transparent page compression

MySQL 5.7.8 中添加的一个功能,允许对 InnoDB 表进行页面级压缩,该表驻留在 每个表文件 表空间中。页面压缩可以通过指定 COMPRESSION 属性与 CREATE TABLEALTER TABLE 实现。更多信息,请参阅 第 17.9.2 节,“InnoDB 页面压缩”

另见 每个表文件, 洞穿, 稀疏文件

transportable tablespace

允许将 表空间 从一个实例迁移到另一个实例。传统上,这在 InnoDB 表空间中是不可能的,因为所有表数据都是 系统表空间 的一部分。在 MySQL 5.6 及更高版本中,使用 FLUSH TABLES ... FOR EXPORT 语法可以准备 InnoDB 表以便复制到另一个服务器;在另一个服务器上运行 ALTER TABLE ... DISCARD TABLESPACEALTER TABLE ... IMPORT TABLESPACE 可以将复制的数据文件导入到另一个实例中。一个单独的 .cfg 文件,与 .ibd 文件 一起复制,用于更新表元数据(例如 空间 ID)当表空间被导入时。请参阅 第 17.6.1.3 节,“导入 InnoDB 表” 获取使用信息。

另见 .cfg 文件, .ibd 文件, 空间 ID, 系统表空间, 表空间

troubleshooting

确定问题来源的一种过程。一些用于排除 MySQL 问题的资源包括:

truncate

一种 DDL 操作,它删除表的所有内容,同时保留表和相关索引不变。与 drop 相比。虽然概念上它与 DELETE 语句无 WHERE 子句相同,但是在幕后它的工作方式不同:InnoDB 创建一个新的空表,删除旧表,然后将新表重命名为旧表的名称。因为这是一个 DDL 操作,所以它不能 回滚

如果被截断的表包含 外键,引用另一个表,截断操作使用较慢的操作方式,逐行删除,以便在需要时删除相关表中的行,根据 ON DELETE CASCADE 子句。(MySQL 5.5 及更高版本不允许这种较慢的截断形式,并在涉及外键时返回错误。 在这种情况下,使用 DELETE 语句 instead。

另见 DDL, drop, 外键, 回滚

truststore

另见 SSL

tuple

一个技术术语,指的是一个有序元素集。这是一个抽象概念,用于数据库理论的正式讨论。在数据库领域,元组通常由表行的列表示。它们也可以由查询结果集表示,例如,仅检索表的一些列,或者来自连接表的列。

另见 游标

two-phase commit

分布式 事务 的一部分,根据 XA 规范。(有时缩写为 2PC。)当多个数据库参与事务时,或者所有数据库 提交 更改,或者所有数据库 回滚 更改。

另见 提交, 回滚, 事务, XA

undo

在整个 事务 生命周期中维护的数据,记录所有更改,以便在 回滚 操作时撤销更改。它存储在 撤销日志 中,位于 系统表空间 内(在 MySQL 5.7 或更早版本中),或在单独的 撤销表空间 中(从 MySQL 8.0 开始,默认情况下撤销日志驻留在撤销表空间中)。

另见 回滚, 回滚段, 系统表空间, 事务, 撤销日志, 撤销表空间

undo buffer

另见 撤销日志

undo log

存储区域,用于存储活动 事务 修改的数据副本。如果另一个事务需要查看原始数据(作为 一致读取 操作的一部分),则从该存储区域中检索未修改的数据。

在 MySQL 5.6 和 MySQL 5.7 中,您可以使用 innodb_undo_tablespaces 变量,使撤销日志驻留在 撤销表空间 中,可以将其放在另一个存储设备上,例如 SSD。在 MySQL 8.0 中,撤销日志驻留在两个默认的撤销表空间中,这些表空间是在 MySQL 初始化时创建的,另外还可以使用 CREATE UNDO TABLESPACE 语法创建其他撤销表空间。

撤销日志被分成两个部分:插入撤销缓冲区更新撤销缓冲区

另请参阅:一致读取回滚段固态硬盘系统表空间事务撤销表空间

undo log segment

一组 撤销日志。撤销日志段存在于 回滚段 中。一个撤销日志段可能包含多个事务的撤销日志。一个撤销日志段只能被一个事务同时使用,但可以在事务 提交回滚 后被重新使用。也可以被称为 撤销段

另请参阅:提交回滚回滚段撤销日志

undo tablespace

撤销表空间包含 撤销日志。撤销日志存在于 撤销日志段 中,这些段又包含于 回滚段 中。回滚段传统上位于系统表空间中。在 MySQL 5.6 中,回滚段可以位于撤销表空间中。在 MySQL 5.6 和 MySQL 5.7 中,撤销表空间的数量由 innodb_undo_tablespaces 配置选项控制。在 MySQL 8.0 中,两个默认的撤销表空间是在 MySQL 实例初始化时创建的,其他撤销表空间可以使用 CREATE UNDO TABLESPACE 语法创建。

更多信息,请参阅 第 17.6.3.4 节,“撤销表空间”

另请参阅:回滚段系统表空间撤销日志撤销日志段

Unicode

支持国家字符、字符集、代码页和其他国际化方面的灵活和标准化的系统。

Unicode 支持是 ODBC 标准的重要方面。Connector/ODBC 5.1 是一个 Unicode 驱动程序,与 Connector/ODBC 3.51 相比,它是一个 ANSI 驱动程序。

另请参阅:ANSIConnector/ODBCODBC

unique constraint

一种 约束,断言某列不能包含任何重复值。在关系代数中,它用于指定 1 对 1 的关系。为了检查某个值是否可以插入(即该值不在该列中已经存在),唯一约束由一个底层 唯一索引 支持。

另请参阅:约束关系唯一索引

unique index

在某列或一组列上具有 唯一约束 的索引。因为该索引已知不包含任何重复值,因此某些查找和计数操作比普通索引更高效。大多数对该类型索引的查找只是为了确定某个值是否存在。该索引中的值数量与表中的行数相同,或者至少是该列的非空值数量。

更改缓冲 优化不适用于唯一索引。作为解决方法,可以在批量加载数据到 InnoDB 表时临时将 unique_checks=0

另请参阅:基数更改缓冲唯一约束唯一键

unique key

由一个或多个列组成的 唯一索引。当您可以定义一个精确匹配一行的 WHERE 条件,并且查询可以使用关联的唯一索引时,查找和错误处理可以非常高效地执行。

另见 基数唯一约束唯一索引

UPN

另见 用户主体名称

user principal name

代表用户的 Kerberos 命名实体的名称。

另见 主体

variable-length type

变长数据类型。VARCHARVARBINARYBLOBTEXT 类型是变长类型。

InnoDB 将长度大于或等于 768 字节的固定长度字段视为变长字段,可以 off-page 存储。例如,CHAR(255) 列可以超过 768 字节,如果字符集的最大字节长度大于 3,如 utf8mb4

另见 off-page 列溢出页

victim

在检测到 死锁 时自动选择回滚的 事务InnoDB 回滚更新最少行的事务。

死锁检测 可以使用 innodb_deadlock_detect 配置选项禁用。

另见 死锁死锁检测innodb_lock_wait_timeout事务

view

一个存储的查询,执行时生成结果集。视图充当虚拟表。

virtual column

另见 虚拟生成列

virtual generated column

一个从表达式计算的列值,不存储值,而是在读取行时立即计算,紧接着 BEFORE 触发器。InnoDB 支持虚拟生成列的次要索引。

存储生成列 相比。

另见 基准列生成列存储生成列

virtual index

在一个或多个 虚拟生成列 或虚拟生成列和常规列或存储生成列的组合上创建的 次要索引。有关更多信息,请参阅 第 15.1.20.9 节,“次要索引和生成列”

另见 次要索引存储生成列虚拟生成列

Visual Studio

对于支持的 Visual Studio 版本,请参阅以下参考:

另见 Connector/C++Connector/NET

wait

当操作,如获取 互斥体,无法立即完成时,InnoDB 会暂停并重试。这种机制足够复杂,以至于这个操作有了自己的名称,即 等待。单个线程使用内部 InnoDB 调度、操作系统 wait() 调用和短期 自旋 循环暂停。

在系统负载重且有许多事务的情况下,您可能使用 SHOW INNODB STATUS 命令或 性能模式 来确定线程是否花费太多时间等待,如果是这样,您可以如何改善 并发性

另见 并发性互斥体性能模式自旋

warm backup

在数据库运行时采取的 备份,但限制了一些数据库操作的过程。例如,表可能变为只读。对于繁忙的应用程序和网站,您可能更喜欢 热备份

另见 备份冷备份热备份

warm up

在系统启动后,让系统在典型的 工作负载 下运行一段时间,以便 缓冲池 和其他内存区域像正常情况下那样填充。这过程自然地发生在 MySQL 服务器重新启动或受到新工作负载时。

通常,您在性能测试前让工作负载运行一段时间,以便缓冲池预热,以确保多次运行的结果一致;否则,性能可能在第一次运行时人为地降低。

在 MySQL 5.6 中,您可以通过启用 innodb_buffer_pool_dump_at_shutdowninnodb_buffer_pool_load_at_startup 配置选项来加速预热过程,以便在重新启动后将缓冲池的内容带回内存中。这些选项在 MySQL 5.7 中默认启用。另见 第 17.8.3.6 节,“保存和恢复缓冲池状态”

另见 缓冲池工作负载

workload

数据库应用程序在典型或峰值使用时的 SQL 和其他数据库操作的组合和体积。在性能测试中,您可以对数据库施加特定的工作负载,以确定 瓶颈,或在容量规划中。

另见 瓶颈CPU 绑定磁盘绑定SQL

write combining

一种优化技术,减少了从 InnoDB 缓冲池 中刷新 脏页 时的写操作。如果一页上的行被多次更新,或者一页上的多行被更新,那么所有这些更改都将在单个写操作中存储到数据文件中,而不是每个更改一个写操作。

另见 缓冲池脏页刷新

XA

一个标准接口,用于协调分布式 事务,允许多个数据库参与事务同时维持 ACID 合规性。详细信息,请参阅 第 15.3.8 节,“XA 事务”

XA 分布式事务支持默认启用。

另请参阅:ACID二进制日志提交事务两阶段提交

young

InnoDB 缓冲池中的一个特征,表示它最近被访问过,因此在缓冲池数据结构中被移动,以免被 LRU 算法太快地 刷新。该术语用于某些与缓冲池相关的 INFORMATION_SCHEMA 表的列名中。

另请参阅:缓冲池刷新INFORMATION_SCHEMALRU


PREV   HOME   UP