MySQL 词汇表
这些术语通常用于 MySQL 数据库服务器的信息中。
- .ARM file
-
ARCHIVE 表的元数据。与 .ARZ 文件 相比。具有此扩展名的文件总是包含在由
mysqlbackup
命令生成的备份中,该命令是 MySQL Enterprise Backup 产品的一部分。 - .ARZ file
-
ARCHIVE 表的数据。与 .ARM 文件 相比。具有此扩展名的文件总是包含在由
mysqlbackup
命令生成的备份中,该命令是 MySQL Enterprise Backup 产品的一部分。 - ACID
-
一个缩写,代表原子性、一致性、隔离性和持久性。这些属性都是数据库系统中所需的,并且都与事务概念紧密相关。
InnoDB
的事务功能遵循 ACID 原则。事务是 原子 工作单元,可以 提交 或 回滚。当事务对数据库进行多个更改时,或者所有更改在提交时成功,或者所有更改在回滚时撤销。
数据库始终保持一致状态 —— 在每个提交或回滚后,以及事务进行中。如果相关数据跨多个表进行更新,查询将看到所有旧值或所有新值,而不是旧值和新值的混合。
事务彼此隔离,以免相互干扰或看到未提交的数据。这种隔离通过 锁定 机制实现。经验丰富的用户可以调整 隔离级别,以换取更高的性能和 并发性,只要他们可以确保事务真的不相互干扰。
事务的结果是持久的:一旦提交操作成功,事务所做的更改就安全地存储在磁盘存储中,免受电源故障、系统崩溃、竞争条件或其他潜在危险的影响。(在
InnoDB
中,双写缓冲区 有助于持久性。) - adaptive flushing
-
一个算法,用于平滑 InnoDB 表中的 I/O 开销,该开销是由 检查点 引入的。相比于将所有修改的 页 从 缓冲池 刷新到 数据文件,MySQL 定期刷新小批量的修改页。自适应刷新算法通过估算最佳刷新速率来扩展该过程,该速率基于刷新速率和 重做 信息的生成速率。
- 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 进行接口。
- AIO
-
异步 I/O 的缩写。你可能在 InnoDB 消息或关键字中看到这个缩写。
另见 异步 I/O。
- ANSI
-
在 ODBC 中,支持字符集和其他国际化方面的替代方法。与 Unicode 相比。Connector/ODBC 3.51 是 ANSI 驱动程序,而 Connector/ODBC 5.1 是 Unicode 驱动程序。
- API
-
API 提供了对 MySQL 协议和 MySQL 资源的低级访问,从 客户端 程序中。与提供高级访问的 Connector 相比。
另见 C API、客户端、Connector、native C API、Perl API、PHP API、Python API、Ruby API。
- application programming interface (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 中,以便在不产生命名冲突的情况下进行版本控制。
- asynchronous I/O
-
允许其他处理在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。 - atomic
-
在SQL上下文中, 事务 是要么完全成功(当 提交 时)要么完全没有效果(当 回滚 时)。事务的不可分割(“原子”)属性是 ACID缩写中的“A”。
- atomic DDL
-
原子 DDL 语句是将 数据字典 更新、 存储引擎 操作和 二进制日志 写入与DDL操作结合到单个原子事务中的语句。事务要么完全提交要么完全回滚,即使服务器在操作期间停止。原子DDL支持从MySQL 8.0开始。有关更多信息,请参阅 第15.1.1节,“原子数据定义语句支持”。
- atomic instruction
- 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
)是默认设置,这反映了从基于语句的复制到基于行的复制的默认复制类型的变化。 - auto-increment locking
-
自动递增主键的便捷性与并发性之间存在一些权衡。在最简单的情况下,如果一个事务正在将值插入表中,任何其他事务都必须等待执行自己的插入,以便第一个事务插入的行可以获得连续的主键值。
InnoDB
包括优化和innodb_autoinc_lock_mode
选项,以便您可以配置最佳的自动递增值序列和最大 并发性 的平衡。 - autocommit
-
一个设置,导致每个 SQL 语句后执行 提交 操作。该模式不建议用于处理
InnoDB
表的跨多个语句的事务中。它可以帮助 只读事务 的性能,特别是在 MySQL 5.6.4 及更高版本中,减少了锁定和撤销数据的开销。它也适用于处理MyISAM
表,其中事务不可用。 - availability
-
能力来cope with,并在必要时从主机故障中恢复,包括MySQL、操作系统或硬件故障,以及可能导致停机的维护活动。通常与可扩展性一起作为大规模部署的关键方面。
另见 可扩展性。
- 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
命令执行 逻辑备份。这些技术在备份数据的大小和表示形式、恢复速度(特别是恢复操作的速度)方面有所不同。备份还可以分类为 热备份、温备份 或 冷备份,这取决于它们对正常数据库操作的干扰程度。(热备份干扰最小,冷备份干扰最大。)
- base column
- beta
-
软件产品生命周期的早期阶段,当时它仅供评估使用,通常没有明确的版本号或小于1的版本号。
InnoDB
不使用 beta 标志,宁愿使用 早期采用者 阶段,该阶段可能会跨越多个点版本,直到达到 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 的技术因 Connector 和 API 而异。MySQLConnector/ODBC
将BLOB
值定义为LONGVARBINARY
。对于大型、自由形式的字符数据集合,行业术语是 CLOB,由 MySQLTEXT
数据类型表示。另见 API, CLOB, Connector, Connector/ODBC。
- bottleneck
-
系统中的一部分,大小或容量受到限制,从而限制了整体吞吐量。例如,内存区域可能小于必要的大小;访问单个必需资源可能会阻止多个 CPU 核心同时运行;或等待磁盘 I/O 完成可能会阻止 CPU 以满负荷运行。消除瓶颈往往会提高 并发性。例如,拥有多个
InnoDB
缓冲池 实例可以减少同时从缓冲池读取和写入时的争用。 - bounce
-
shutdown 操作紧接着重新启动。理想情况下,伴随着相对较短的 热身 期间,以便性能和吞吐量快速恢复到高水平。
另见 shutdown。
- buddy allocator
- buffer
-
用于临时存储的内存或磁盘区域。数据在内存中缓存,以便高效地写入磁盘,使用少量的大型 I/O 操作,而不是许多小型操作。数据在磁盘上缓存,以提高可靠性,以便在最坏情况下崩溃或其他故障时恢复。InnoDB 使用的主要缓冲类型是 缓冲池、双写缓冲 和 更改缓冲。
- buffer pool
-
保存缓存的 InnoDB 数据的内存区域,用于表和索引。为了高效地执行大量读取操作,缓冲池被分成可以容纳多行的 页。为了高效地管理缓存,缓冲池被实现为一个链表的页;很少使用的数据将被从缓存中删除,使用一种变体的 LRU 算法。在具有大内存的系统上,可以通过将缓冲池分成多个 缓冲池实例 来提高并发性。
多个 InnoDB 状态变量、
INFORMATION_SCHEMA
表和performance_schema
表有助于监控缓冲池的内部工作。从 MySQL 5.6 开始,可以通过在服务器关闭时保存缓冲池状态并在服务器启动时恢复缓冲池状态来避免长时间的热身期,特别是对于具有大缓冲池的实例。见 第 17.8.3.6 节,“保存和恢复缓冲池状态”。 - 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。 - C
-
一种编程语言,结合了可移植性和性能,并且可以访问低级硬件特性,使其成为编写操作系统、驱动程序和其他系统软件的流行选择。许多复杂的应用程序、语言和可重用模块都包含用 C 编写的部分,连接到高级组件上,使用其他语言编写。
- C API
-
C API 代码与 MySQL 一起分发。它包含在 libmysqlclient 库中,允许 C 程序访问数据库。
另见 API,C,libmysqlclient。
- C#
-
一种编程语言,结合了强类型和面向对象特性,在 Microsoft .NET 框架或其开源对应项 Mono 中运行。经常用于创建使用 ASP.net 框架的应用程序。其语法与 C、C++ 和 Java 开发者熟悉。
- C++
-
一个核心语法与 C 开发者熟悉的编程语言。提供了低级操作的访问权限,以提高性能,同时结合了高级数据类型、面向对象特性和垃圾回收。要编写 MySQL 的 C++ 应用程序,您使用 Connector/C++ 组件。
另见 C, Connector/C++。
- cache
- 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
命令。以前称为 插入缓冲区。
- change buffering
-
一般术语,指涉及 更改缓冲区 的功能,包括 插入缓冲、删除缓冲 和 清除缓冲。索引更改来自 SQL 语句,可能涉及随机 I/O 操作,这些操作将被延迟并由后台 线程 定期执行。该序列操作可以更高效地写入磁盘块,以便于一系列索引值。由
innodb_change_buffering
和innodb_change_buffer_max_size
配置选项控制。 - checkpoint
-
当对缓存在 缓冲池 中的数据页进行更改时,这些更改将在稍后写入 数据文件,这称为 刷新。检查点是记录最新更改(以 LSN 值表示)的记录,这些更改已经成功写入数据文件。
- checksum
-
在
InnoDB
中,用于检测磁盘上 页 的腐败的验证机制,当从磁盘读取到InnoDB
缓冲池 中时。该功能由innodb_checksums
配置选项控制,在 MySQL 5.5 中有效。innodb_checksums
在 MySQL 5.6.3 中已弃用,取而代之的是innodb_checksum_algorithm
。命令 innochecksum 帮助诊断腐败问题,通过测试指定的 表空间 文件的 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)到 数据文件 中。与 脏页 相反。 - clean shutdown
-
一个 关闭,它在完成时不出错,并在完成前将所有更改应用于
InnoDB
表,相比之下是一个 崩溃 或 快速关闭。同义词为 慢关闭。 - client
-
一个在数据库服务器外运行的程序,通过发送请求通过 Connector 或通过 API made available 通过 客户端库 与数据库通信。它可以在与数据库服务器相同的物理机器上运行,也可以在远程机器上通过网络连接。它可以是一个特殊目的数据库应用程序,也可以是一个通用程序,如 mysql 命令行处理器。
- client libraries
-
包含数据库函数集合的文件。通过编译程序与这些库,或者在同一系统上安装它们,您可以在没有 MySQL 服务器安装的机器上运行数据库应用程序(也称为 客户端); 应用程序通过网络访问数据库。使用 MySQL,您可以使用来自 MySQL 服务器的 libmysqlclient 库。
另请参阅 客户端、libmysqlclient。
- client-side prepared statement
-
一种类型的 预备语句,其中缓存和重用是本地管理的,模拟 服务器端预备语句 的功能。历史上,一些 Connector/J、Connector/ODBC 和 Connector/PHP 开发者使用它来解决服务器端存储过程的问题。随着现代 MySQL 服务器版本的出现,服务器端预备语句被推荐用于性能、可扩展性和内存效率。
- CLOB
-
一个 SQL 数据类型 (
TINYTEXT
、TEXT
、MEDIUMTEXT
或LONGTEXT
),用于存储任意大小的字符数据,具有关联的字符集和排序顺序。处理 CLOBs 的技术因 Connector 和 API 而异。MySQL Connector/ODBC 将TEXT
值定义为LONGVARCHAR
。对于存储二进制数据,等效类型是 BLOB。 - 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 语句后提交。
- 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
。在备份过程开始时应用压缩有助于避免存储开销和网络开销,当将备份文件传输到另一个服务器时。应用二进制日志的过程需要更长时间,并需要解压缩备份文件。
- 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产品。
- 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
配置选项。 - concatenated index
-
另请参阅 复合索引。
- concurrency
-
多个操作(在数据库术语中,事务)可以同时运行,不会相互干扰。并发也涉及性能,因为理想情况下,多个事务的保护机制应该具有最小的性能开销,使用高效的锁机制。
- 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 的 plain C 应用程序开发成为可能。它还使得使用 Connector/C++ 1.1 的 JDBC-based API 的 C++ 应用程序开发成为可能。详见 MySQL Connector/C++ 8.4 开发者指南。
- Connector/J
-
一个 JDBC 驱动程序,为 客户端 应用程序开发在 Java 编程语言中提供连接性。MySQL Connector/J 是一个 JDBC Type 4 驱动程序:一个纯 Java 实现的 MySQL 协议,不依赖于 MySQL 客户端库。详见 MySQL Connector/J 开发者指南。
- Connector/NET
-
一个 MySQL 连接器,为使用语言、技术和框架如 C#、.NET、Mono、Visual Studio、ASP.net 和 ADO.net 的开发者提供连接性。
- Connector/ODBC
-
MySQL ODBC 驱动程序家族,为使用行业标准开放数据库连接 (ODBC) API 访问 MySQL 数据库提供连接性。以前称为 MyODBC 驱动程序。详见 MySQL Connector/ODBC 开发者指南。
- Connector/PHP
- consistent read
-
使用快照信息来呈现查询结果的读操作,基于某个时间点,不管其他事务同时运行的更改。如果查询的数据被其他事务更改,原始数据将根据 撤销日志 的内容重建。这种技术避免了一些可能减少 并发性 的锁定问题,迫使事务等待其他事务完成。
使用 可重复读 隔离级别,快照基于第一次读操作的时间。使用 已提交读 隔离级别,快照将重置为每个一致读操作的时间。
一致读是
InnoDB
处理SELECT
语句的默认模式,在 已提交读 和 可重复读 隔离级别中。因为一致读不锁定访问的表,其他会话可以在一致读执行时修改这些表。有关适用隔离级别的技术细节,请参阅 第 17.7.2.3 节,“一致非锁定读取”。
- constraint
-
自动测试,可以阻止数据库更改,以防止数据变得不一致。(在计算机科学术语中,关于不变条件的断言。)约束是 ACID 哲学的关键组件,以维护数据一致性。MySQL 支持的约束包括 外键约束 和 唯一约束。
- counter
-
特定
InnoDB
操作递增的值。有助于衡量服务器的繁忙程度、排除性能问题的来源,并测试配置设置或查询使用的索引是否产生了预期的低级别效果。不同的计数器可通过 性能架构 表和 信息架构 表获得,特别是INFORMATION_SCHEMA.INNODB_METRICS
。 - covering index
-
包含查询检索的所有列的 索引。而不是使用索引值作为指针来查找完整的表行,查询从索引结构中返回值,节省磁盘 I/O。
InnoDB
可以将这种优化技术应用于更多的索引,而不是 MyISAM,因为InnoDB
次要索引 也包括 主键 列。InnoDB
不能将这种技术应用于事务修改的表,直到事务结束。任何 列索引 或 复合索引 都可以作为覆盖索引,给定正确的查询。尽可能地设计索引和查询,以利用这种优化技术。
- CPU-bound
-
一种类型的 工作负载,其中主要的 瓶颈 是 CPU 操作在内存中。通常涉及读取密集型操作,其中的结果都可以缓存在 缓冲池 中。
- crash
-
MySQL 使用术语 “崩溃” 来泛指任何意外的 关闭 操作,其中服务器无法执行正常的清理操作。例如,崩溃可能是由于数据库服务器机器或存储设备上的硬件故障;电源故障;潜在的数据不匹配导致 MySQL 服务器停止;DBA 发起的 快速关闭 ;或许多其他原因。InnoDB 表的强大、自动 崩溃恢复 确保了在服务器重新启动时数据的一致性,不需要 DBA 的额外工作。
- crash recovery
-
MySQL 在崩溃后重新启动时的清理活动。对于 InnoDB 表,使用 重做日志 中的数据来重放未完成的事务更改。在崩溃前提交但尚未写入 数据文件 的更改,从 双写缓冲区 中重建。当数据库正常关闭时,这种活动在关闭期间由 清理 操作执行。
在正常操作期间,已提交的数据可以存储在 更改缓冲区 中一段时间,然后写入数据文件。总是存在一个 tradeoff,即保持数据文件最新,引入了正常操作期间的性能开销,或者缓冲数据,使崩溃恢复时间更长。
- CRUD
-
缩写为 “创建、读取、更新、删除”,数据库应用程序中的一般操作序列。通常表示具有相对简单数据库使用(基本 DDL、DML 和 查询 语句在 SQL 中)的应用程序,可以快速在任何语言中实现。
- cursor
-
MySQL 的内部数据结构,表示 SQL 语句的结果集。通常与 预备语句 和 动态 SQL 一起使用。它像其他高级语言中的迭代器一样,根据请求产生结果集中的每个值。
尽管 SQL 通常为您处理游标的处理,但是在处理性能关键代码时,您可能需要深入了解游标的内部工作机制。
- data definition language
-
另见 DDL。
- data dictionary
-
跟踪数据库对象的元数据,如 表、 索引 和表 列。对于 MySQL 数据字典,从 MySQL 8.0 开始,元数据物理位于
InnoDB
每表文件 表空间文件中,在mysql
数据库目录中。对于InnoDB
数据字典,元数据物理位于InnoDB
系统表空间 中。因为 MySQL Enterprise Backup 产品总是备份
InnoDB
系统表空间,因此所有备份都包括InnoDB
数据字典的内容。 - 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 相比。
- database
-
在 MySQL 的 数据目录 中,每个数据库由单独的目录表示。InnoDB 系统表空间,可以存储来自多个数据库的表数据,在 MySQL 实例 中,位于单独的数据文件中。当 每表文件 模式启用时,InnoDB 表的 .ibd 文件 将存储在数据库目录中,除非使用
DATA DIRECTORY
子句创建在其他位置。通用表空间,引入于 MySQL 5.7.6,也将表数据存储在 .ibd 文件 中。与每表文件 .ibd 文件 不同,通用表空间 .ibd 文件 可以存储来自多个数据库的表数据,并可以分配到相对于或独立于 MySQL 数据目录的目录中。对于长期使用 MySQL 的用户,数据库是一个熟悉的概念。来自 Oracle Database 背景的用户可能会发现 MySQL 中的数据库概念更接近于 Oracle Database 中的 模式。
- DCL
-
数据控制语言,一组用于管理权限的 SQL 语句。在 MySQL 中,包括
GRANT
和REVOKE
语句。与 DDL 和 DML 相比。 - 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 相比。
- deadlock
-
在不同 事务 无法继续进行,因为每个事务都持有锁,另一个事务需要该锁。由于两个事务都在等待资源可用,因此它们都不会释放它们持有的锁。
死锁可能发生在事务锁定多个表中的行(通过语句如
UPDATE
或SELECT ... FOR UPDATE
),但顺序相反。死锁也可能发生在锁定索引记录和 间隙 时,每个事务获取一些锁,但由于计时问题而不获取其他锁。有关死锁自动检测和处理的背景信息,请参阅 第 17.7.5.2 节,“死锁检测”。有关避免和恢复死锁条件的提示,请参阅 第 17.7.5.3 节,“如何最小化和处理死锁”。
- deadlock detection
-
一种机制,自动检测死锁的发生,并自动 回滚 其中一个参与的事务(受害者)。死锁检测可以使用
innodb_deadlock_detect
配置选项禁用。 - delete
-
当
InnoDB
处理DELETE
语句时,行将被标记为删除,并且不再被查询返回。存储空间稍后在周期性垃圾回收操作中被回收,称为 清除 操作。对于删除大量数据,相关操作及其性能特征是 TRUNCATE 和 DROP。 - delete buffering
-
将次要索引页的更改,来自
DELETE
操作,在 更改缓冲区 中存储,而不是立即写入,以便将物理写入最小化为随机 I/O。(因为删除操作是一个两步过程,这个操作将写入通常标记索引记录以供删除缓冲。)这是 更改缓冲 的一种类型;其他类型是 插入缓冲 和 清除缓冲。 - denormalized
-
一种数据存储策略,在不同的表中复制数据,而不是使用 外键 和 连接 查询。通常用于 数据仓库 应用程序中,其中数据在加载后不再更新。在这些应用程序中,查询性能比维护更新时的一致性更重要。与 标准化 相比。
- descending index
-
一种类型的 索引,其中索引存储被优化以处理
ORDER BY
子句。列
DESC另见 索引。
- dictionary object cache
-
字典对象缓存将以前访问的 数据字典 对象存储在内存中,以启用对象重用和最小化磁盘 I/O。使用基于 LRU 的驱逐策略来驱逐内存中最少最近使用的对象。缓存由存储不同对象类型的多个分区组成。
有关更多信息,请参阅 第 16.4 节,“字典对象缓存”。
- dirty page
- dirty read
-
一个操作,检索不可靠的数据,即由另一个事务更新但尚未 提交 的数据。仅在 隔离级别 为 读未提交 时可能发生。
这种操作不遵守数据库设计的 ACID 原则。它被认为非常危险,因为数据可能会 回滚,或在提交前被进一步更新;然后,执行脏读的事务将使用从未确认的数据。
其对应的是 一致读,其中
InnoDB
确保事务不读取其他事务更新的信息,即使其他事务在此期间提交。 - 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 相比。
- 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()
调用操作系统。 - drop
-
一种 DDL 操作,通过语句如
DROP TABLE
或DROP INDEX
删除模式对象。它内部映射到ALTER TABLE
语句。从InnoDB
的角度看,性能考虑的操作涉及到锁定 数据字典 以确保相关对象的更新,以及更新内存结构如 缓冲池 的时间。对于 表,删除操作的特征与 截断 操作 (TRUNCATE TABLE
语句) 略有不同。 - DSN
-
“数据库源名称”的缩写。它是 连接 信息在 Connector/ODBC 中的编码。请参阅 在 Windows 上配置 Connector/ODBC DSN 以获取详细信息。它是 连接字符串 的等同物,用于 Connector/NET。
另见 连接, 连接字符串, Connector/NET, Connector/ODBC。
- dynamic cursor
-
一种 光标 类型,支持 ODBC,可以在读取行时获取新的和更改的结果。是否及何时更改可见取决于表类型(事务或非事务)和事务表的隔离级别。动态光标支持必须被明确启用。
- dynamic row format
-
InnoDB
行格式。由于长变长列值存储在行数据所在的页面之外,因此对于包含大对象的行非常高效。由于大字段通常不被访问以评估查询条件,因此它们不太可能被带入 缓冲池,从而减少 I/O 操作并更好地利用缓存内存。从 MySQL 5.7.9 开始,默认行格式由
innodb_default_row_format
定义,默认值为DYNAMIC
。有关
InnoDB
DYNAMIC
行格式的更多信息,请参阅 DYNAMIC 行格式。 - dynamic SQL
-
允许使用更健壮、安全和高效的方法来代替参数值,而不是简单地将语句的各部分连接到字符串变量中,以创建和执行 预备语句。
另见 预备语句。
- dynamic statement
- early adopter
-
软件产品测试阶段,类似于 beta 阶段,在非关键任务设置中评估性能、功能和兼容性。
另见 beta。
- Eiffel
-
一个包含许多面向对象特性的编程语言。一些概念对 Java 和 C# 开发者来说很熟悉。对于开源 Eiffel API for MySQL,请参阅 第 31.13 节,“MySQL Eiffel Wrapper”。
- embedded
-
嵌入式 MySQL 服务器库 (libmysqld) 使得可以在客户端应用程序中运行完整的 MySQL 服务器。主要优点是提高速度和简化嵌入式应用程序的管理。
- error log
-
一种类型的 日志,显示 MySQL 启动和关键运行时错误的信息,以及 崩溃 信息。详细信息,请参阅 第 7.4.2 节,“错误日志”。
- eviction
-
从缓存或其他临时存储区域中删除项目的过程,例如
InnoDB
缓冲池。通常(但不总是)使用 LRU 算法来确定要删除的项目。当 脏页 被驱逐时,其内容将被 刷新 到磁盘,可能还会刷新邻近的 页。 - exception interceptor
-
一种类型的 拦截器,用于跟踪、调试或增强数据库应用程序遇到的 SQL 错误。例如,拦截器代码可以发出
SHOW WARNINGS
语句来检索附加信息,并添加描述性文本或甚至更改返回给应用程序的异常类型。因为拦截器代码仅在 SQL 语句返回错误时被调用,因此它不会对应用程序的正常(无错误)操作产生性能损失。在使用 Java 的应用程序中,设置这种类型的拦截器涉及实现
com.mysql.jdbc.ExceptionInterceptor
接口,并将exceptionInterceptors
属性添加到 连接字符串 中。在使用 Visual Studio 的应用程序中,设置这种类型的拦截器涉及定义继承自
BaseExceptionInterceptor
类的类,并将该类名称指定为连接字符串的一部分。 - 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。
- .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=INNODB
或INSERT INTO ... SELECT * FROM ...
,然后创建索引。在 MySQL 5.6 中,该功能变得更加通用。您可以在创建索引时读取和写入表,而许多其他类型的
ALTER TABLE
操作可以在不复制表、不阻塞 DML 操作或同时执行的情况下执行。因此,在 MySQL 5.6 及更高版本中,该功能集被称为 在线 DDL 而不是快速索引创建。有关信息,请参阅 第 17.12 节,“InnoDB 和在线 DDL”。
- fast shutdown
-
默认的 shutdown 程序为
InnoDB
,基于配置设置innodb_fast_shutdown=1
。为了节省时间,一些 flush 操作被跳过。这种shutdown 在正常使用中是安全的,因为 flush 操作将在下一次启动时执行,使用与 崩溃恢复 相同的机制。在升级或降级数据库时,请执行 慢速shutdown,以确保所有相关更改在shutdown 时应用于 数据文件。另见 崩溃恢复, 数据文件, flush, shutdown, 慢速shutdown。
- file format
- 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
内部 迷你事务 频繁更新,并因此受到其自己的 互斥锁 保护,以允许并发访问缓冲池。 - foreign key
-
在分离的
InnoDB
表之间的一种指针关系。外键关系是在 父表 和 子表 中的一列上定义的。此外,外键还帮助实施 参照完整性,防止这些指针在数据插入、更新和删除时变得无效。这项实施机制是一种 约束。如果一行指向另一个表,但关联的外键值不存在于另一个表中,那么该行不能被插入。如果一行被删除或其外键值被更改,而另一个表中的行指向该外键值,那么外键可以被设置为防止删除,导致另一个表中的相应列值变为 空,或自动删除另一个表中的相应行。
设计 规范化 数据库的一步是识别重复的数据,将其分离到一个新表中,并设置外键关系,以便多个表可以像单个表一样被查询,使用 连接 操作。
- FOREIGN KEY constraint
-
类型的 约束,通过 外键 关系维护数据库一致性。像其他类型的约束一样,它可以防止数据插入或更新,以免数据变得不一致;在这种情况下,防止的不一致是多个表之间的不一致。另外,当执行 DML 操作时,
FOREIGN KEY
约束可以导致 子行 中的数据被删除、更改为不同的值或设置为 空,基于创建外键时指定的ON CASCADE
选项。 - FTS
- full backup
- full table scan
-
需要读取整个表的内容,而不是使用 索引 仅读取选定的部分。通常在小查找表或数据仓库情况下使用大表,所有可用数据都被聚合和分析。这些操作的频率和表的大小相对于可用内存的影响,对查询优化算法和管理 缓冲池 的影响。
索引的目的是允许在大表中查找特定值或值范围,从而避免了全表扫描。
- full-text search
-
MySQL 的一个功能,用于在表数据中查找单词、短语、布尔组合单词等,以一种更快、更方便、更灵活的方式,而不是使用 SQL
LIKE
运算符或编写自己的应用程序级搜索算法。它使用 SQL 函数MATCH()
和 FULLTEXT 索引。另见 FULLTEXT 索引。
- FULLTEXT index
-
MySQL 全文搜索 机制中的特殊索引,持有 搜索索引。从列值中表示单词,忽略指定的 停用词。最初仅适用于
MyISAM
表。从 MySQL 5.6.4 开始,也适用于 InnoDB 表。 - fuzzy checkpointing
- GA
-
“一般可用”,软件产品离开 beta 阶段并可供销售、官方支持和生产使用时的阶段。
另见 beta。
- GAC
-
“全球程序集缓存” 的缩写。是一个中央存储库,用于存储 程序集(assemblies)在 .NET 系统中。物理上由嵌套文件夹组成,.NET CLR 将其视为单个虚拟文件夹。
- 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 锁 相比。间隙锁是性能和 并发 之间的权衡,并且在某些事务 隔离级别 中使用,而在其他级别中不使用。
- 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
- generated stored column
-
另见 存储生成列。
- generated virtual column
-
另见 虚拟生成列。
- Glassfish
-
另见 J2EE。
- global temporary tablespace
-
一个 临时表空间,用于存储 回滚段,用于用户创建的临时表的更改。
另见 临时表空间。
- global transaction
-
一种 事务,涉及 XA 操作。它由多个操作组成,这些操作本身是事务性的,但所有操作都必须成功完成,或者所有操作都回滚。从本质上讲,这扩展了 ACID 属性“上一级”,以便多个 ACID 事务可以作为组件执行,作为一个全局操作的组件。
- 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
表中。 - HDD
-
“硬盘驱动器” 的缩写。指的是使用旋转盘的存储介质,通常是在比较和对比固态驱动器(SSD)时使用。其性能特征可以影响基于磁盘的工作负载的吞吐量。
- heartbeat
-
定期发送的消息,以表明系统正常运行。在复制上下文中,如果源停止发送这些消息,则其中一个副本可以取代它。类似的技术可以在集群环境中使用,以确认所有服务器都在正常运行。
- high-water mark
-
一个表示上限的值,或者是一个记录的最大值,或者是一个记录的实际达到值。与 低水位标记 相比。
另见 低水位标记。
- history list
-
一个待处理的 事务 列表,其中包含标记为删除的记录,计划由
InnoDB
清除 操作处理。记录在 撤销日志 中。历史列表的长度由命令SHOW ENGINE INNODB STATUS
报告。如果历史列表的长度超过了innodb_max_purge_lag
配置选项的值,每个 DML 操作将被略微延迟,以允许清除操作完成 刷新 删除的记录。也称为 清除延迟。
- hole punching
-
从页面中释放空块。
InnoDB
透明页压缩 功能依赖于 hole punching 支持。有关更多信息,请参阅 第 17.9.2 节,“InnoDB 页压缩”。 - host
-
数据库服务器的网络名称,用于建立 连接。通常与 端口 一起指定。在某些情况下,IP 地址
127.0.0.1
比特殊名称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
-
一组文件,名称如
ibdata1
、ibdata2
等,组成InnoDB
系统表空间。有关系统表空间ibdata
文件中的结构和数据,请参阅 第 17.6.3.1 节,“系统表空间”。ibdata
文件的增长受到innodb_autoextend_increment
配置选项的影响。 - 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 查询缓存。 - 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
-
一个 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 TABLE
和TRUNCATE 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 的功能,例如 插入缓冲区 在 更改缓冲 中的使用,以及 自动递增 列。
- insert buffer
-
之前的名称是 更改缓冲区。在 MySQL 5.5 中,添加了对次要索引页的更改缓冲支持,以便在
DELETE
和UPDATE
操作中缓冲更改。以前,只有来自INSERT
操作的更改被缓冲。现在,首选术语是 更改缓冲区。 - insert buffering
-
将次要索引页的更改存储在 更改缓冲区 中,而不是立即写入,以便将物理写入最小化随机 I/O。这是一种 更改缓冲 类型;其他类型包括 删除缓冲 和 清除缓冲。
如果次要索引是 唯一的,则不使用插入缓冲,因为无法在写入新条目之前验证新值的唯一性。其他类型的更改缓冲适用于唯一索引。
- insert intention lock
-
一种 间隙锁 类型,由
INSERT
操作在插入行之前设置。这种锁类型表明了插入意图,以便在同一个间隙中插入的多个事务不需要等待对方,如果它们不是在同一个位置插入。有关更多信息,请参阅 第 17.7.1 节,“InnoDB 锁定”。 - instance
-
一个单独的 mysqld 守护进程管理着一个 数据目录,该目录代表一个或多个 数据库,其中包含一组 表。在开发、测试和某些 复制 场景中,在同一 服务器 机器上运行多个实例,每个实例管理其自己的数据目录,并监听其自己的端口或套接字。使用一个实例运行磁盘绑定的工作负载时,服务器可能仍然有额外的 CPU 和内存容量来运行其他实例。
- instrumentation
-
在源代码级别对性能数据进行修改,以便进行调整和调试。在 MySQL 中,通过 SQL 接口使用
INFORMATION_SCHEMA
和PERFORMANCE_SCHEMA
数据库来公开收集的数据。另见 INFORMATION_SCHEMA, 性能模式。
- intention exclusive lock
-
另见 意图锁。
- intention lock
-
一种 锁,应用于表,用于指示事务在表中的行上要获取的锁类型。不同的事务可以在同一个表上获取不同的意图锁,但第一个获取 意图排他 (IX) 锁的事务将阻止其他事务在该表上获取任何 S 或 X 锁。相反,第一个获取 意图共享 (IS) 锁的事务将阻止其他事务在该表上获取任何 X 锁。这个两阶段过程允许锁请求按顺序解析,不会阻塞锁和相应的操作,这些操作是兼容的。有关这个锁机制的更多信息,请参阅 第 17.7.1 节,“InnoDB 锁机制”。
- intention shared lock
-
另见 意图锁。
- interceptor
- intrinsic temporary table
-
另见 优化器。
- inverted index
-
用于文档检索系统的数据结构,用于
InnoDB
全文搜索 的实现。InnoDB
FULLTEXT 索引,实现为倒排索引,记录文档中的每个单词的位置,而不是表行的位置。单个列值(文档存储为文本字符串)由倒排索引中的多个条目表示。另见 全文搜索、FULLTEXT 索引、ilist。
- IOPS
-
缩写为 每秒输入/输出操作数。忙碌系统的常见度量,特别是 OLTP 应用程序。如果这个值接近存储设备可以处理的最大值,应用程序可能会变成 磁盘绑定,限制 可扩展性。
- isolation level
-
数据库处理的基础之一。隔离是 ACID 缩写中的 I;隔离级别是调整性能和可靠性、一致性和结果可重复性的设置,当多个 事务 同时进行更改和查询时。
从最高的一致性和保护到最低,InnoDB 支持的隔离级别是:SERIALIZABLE、REPEATABLE READ、READ COMMITTED 和 READ UNCOMMITTED。
对于
InnoDB
表,大多数用户可以将默认隔离级别(REPEATABLE READ)用于所有操作。高级用户可能会选择 READ COMMITTED 级别,以推动 OLTP 处理的可扩展性边界,或者在数据仓库操作中,minor 不一致不会影响大量数据的聚合结果。在边缘(SERIALIZABLE 和 READ UNCOMMITTED)级别改变处理行为,以至于它们很少使用。查看 ACID, OLTP, READ COMMITTED, READ UNCOMMITTED, REPEATABLE READ, SERIALIZABLE, 事务。
- J2EE
-
Java 平台,企业版:Oracle 的企业 Java 平台。它由 API 和企业级 Java 应用程序的运行时环境组成。有关详细信息,请参阅 http://www.oracle.com/technetwork/java/javaee/overview/index.html。在 MySQL 应用程序中,您通常使用 Connector/J 进行数据库访问,并使用应用程序服务器如 Tomcat 或 JBoss 处理中间层工作,并可选使用框架如 Spring。数据库相关功能通常在 J2EE 堆栈中提供,包括 连接池 和 故障转移 支持。
- Java
-
一种编程语言,结合了高性能、丰富的内置功能和数据类型、面向对象机制、广泛的标准库和大量可重用的第三方模块。企业开发支持许多框架、应用服务器和其他技术。大多数语法与 C 和 C++ 开发者熟悉。要编写 Java 应用程序与 MySQL 一起使用,您使用 JDBC 驱动程序,称为 Connector/J。
查看 C, Connector/J, C++, JDBC。
- JBoss
-
查看 J2EE。
- JDBC
-
“Java 数据库连接” 的缩写,用于从 Java 应用程序访问数据库的 API。Java 开发者编写 MySQL 应用程序时,使用 Connector/J 组件作为其 JDBC 驱动程序。
查看 API, Connector/J, J2EE, Java。
- JNDI
-
查看 Java。
- join
-
一个从多个表中检索数据的 查询,通过引用表中的相同值列。理想情况下,这些列是
InnoDB
外键 关系的一部分,这确保了 参照完整性 并且连接列是 索引 的。通常用于节省空间和改善查询性能,通过在 标准化 数据设计中将重复字符串替换为数字 ID。
- KDC
-
查看 密钥分发中心。
- key distribution center
- keystore
-
查看 SSL。
- KEY_BLOCK_SIZE
-
在使用 压缩行格式 的
InnoDB
表中指定数据页的大小的选项。默认值为 8 千字节。较低的值可能会遇到内部限制,这取决于行大小和压缩百分比的组合。对于
MyISAM
表,KEY_BLOCK_SIZE
可选地指定索引键块的大小(以字节为单位)。该值被视为提示;如果必要,可能会使用不同的大小。单个索引定义中的KEY_BLOCK_SIZE
值将覆盖表级KEY_BLOCK_SIZE
值。另见 压缩行格式。
- latch
-
InnoDB
用于实现锁的轻量级结构,通常持有很短的时间,测量单位为毫秒或微秒。通用术语,包括 互斥锁(用于独占访问)和 读写锁(用于共享访问)。某些闩是InnoDB
性能调整的焦点。通过 性能模式 接口可以获取闩的使用和争用统计信息。 - libmysql
-
另见 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 技术的变体。 - 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
语句,例如SELECT ... FOR UPDATE
或SELECT ... LOCK IN SHARE MODE
。它可能会产生 死锁,取决于事务的 隔离级别。与 非锁定读取 相反。在只读事务中不允许对全局表进行锁定。SELECT... FOR SHARE
在 MySQL 8.0.1 中取代了SELECT... LOCK IN SHARE MODE
,但LOCK IN SHARE MODE
仍然可用于向后兼容。 - log
-
在 InnoDB 上下文中,“日志” 或 “日志文件” 通常指的是由 重做日志 代表的 ib_logfile
N
文件。另一种 InnoDB 日志类型是 撤销日志,它是一个存储区域,用于存储活动事务修改的数据副本。MySQL 中的其他重要日志类型包括 错误日志(用于诊断启动和运行时问题)、二进制日志(用于复制和执行点时恢复)、通用查询日志(用于诊断应用程序问题) 和 慢查询日志(用于诊断性能问题)。
- log buffer
-
将要写入 日志文件 的内存区域,组成 重做日志。它由
innodb_log_buffer_size
配置选项控制。 - log file
-
ib_logfile
N
文件之一,组成 重做日志。数据从 日志缓冲区 内存区域写入这些文件。另见 ib_logfile、日志缓冲区、重做日志。
- log group
-
组成 重做日志 的文件集,通常命名为
ib_logfile0
和ib_logfile1
。(因此,有时统称为 ib_logfile。)另见 ib_logfile、重做日志。
- logical
-
一种涉及高级、抽象方面的操作,如表、查询、索引和其他 SQL 概念。逻辑方面通常对数据库管理和应用程序开发非常重要。与 物理 相对。
- logical backup
-
一种 备份,它重现表结构和数据,而不复制实际数据文件。例如,
mysqldump
命令生成逻辑备份,因为其输出包含诸如CREATE TABLE
和INSERT
语句的语句,可以重新创建数据。与 物理备份 相对。逻辑备份提供了灵活性(例如,您可以在恢复之前编辑表定义或插入语句),但恢复时间可能比物理备份长。 - 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。
- LTS Series
-
具有相同主要版本号的 LTS 版本形成一个 LTS 系列。例如,所有 MySQL 8.4.x 版本形成 MySQL 8.4 LTS 系列。
注意:MySQL 8.0 是一个 Bugfix 系列,先于 LTS 发布模型。
另见 创新系列。
- .MRG file
-
一个包含对其他表的引用的文件,用于
MERGE
存储引擎。具有该扩展名的文件总是包含在 mysqlbackup 命令的备份中,来自 MySQL Enterprise Backup 产品。 - .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 INDEX
和DROP INDEX
对于InnoDB
表)在其他事务查询、更新表时继续进行。 - metrics counter
-
在 MySQL 5.6 及更高版本中,
INNODB_METRICS
表中的一个功能,在 INFORMATION_SCHEMA 中实现的。您可以查询 计数器 和总数的低级InnoDB
操作,并将结果与 性能模式 的数据结合使用,以进行性能调整。 - midpoint insertion strategy
-
将 页 初始加载到
InnoDB
缓冲池 中,不是在列表的“最新”端,而是在中间某个点上。该点的确切位置取决于innodb_old_blocks_pct
选项的设置。该技术的目的是使只读一次的页(例如在 全表扫描 期间),可以比严格的 LRU 算法更快地从缓冲池中淘汰出去。有关更多信息,请参阅 第 17.5.1 节,“缓冲池”。 - mini-transaction
-
InnoDB
处理的内部阶段,在 物理 级别上对内部数据结构进行更改期间的 DML 操作。小事务(mtr)没有 回滚 的概念;多个小事务可以在单个 事务 中发生。小事务将信息写入 重做日志,用于 崩溃恢复。小事务也可以在常规事务之外发生,例如在后台线程的 清理 处理期间。 - 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
- multi-core
- multiversion concurrency control
-
见 MVCC。
- mutex
-
非正式缩写为““互斥变量”。(Mutex本身是““互斥排除”的缩写。)InnoDB使用的低级对象,用于表示和实施对内部内存数据结构的独占访问锁。一旦获取锁,就会阻止其他进程、线程等获取相同的锁。与rw-locks相比,InnoDB使用rw-locks来表示和实施对内部内存数据结构的共享访问锁。Mutexes和rw-locks统称为闩。
- MVCC
-
缩写为““多版本并发控制”。该技术允许InnoDB事务在某些隔离级别下执行一致读取操作;即查询正在被其他事务更新的行,并看到更新前的值。这是一种强大的技术,可以增加并发性,因为它允许查询在不等待锁的情况下继续执行。
该技术在数据库世界中不是普遍的。一些其他数据库产品和一些其他MySQL存储引擎不支持它。
- my.cnf
- my.ini
- MyODBC drivers
-
另见 Connector/ODBC。
- mysql
-
该mysql程序是 MySQL 数据库的命令行解释器。它处理SQL语句,并且还处理 MySQL 特定的命令,如
SHOW TABLES
,通过将请求传递给mysqld守护进程。 - MySQL Enterprise Backup
-
一个授权产品,执行 MySQL 数据库的热备份。它在备份
InnoDB
表时提供了最高效率和灵活性,但也可以备份MyISAM
和其他类型的表。 - mysqlbackup command
-
该MySQL Enterprise Backup产品的命令行工具。它对
InnoDB
表执行热备份操作,对MyISAM
和其他类型的表执行温备份操作。请参阅第 32.1 节,“MySQL Enterprise Backup 概述”以获取关于该命令的更多信息。 - mysqlclient
- mysqld
-
mysqld,也称为 MySQL 服务器,是 MySQL 安装中的单个多线程程序。它不spawn 附加进程。MySQL 服务器管理 MySQL 数据目录,该目录包含数据库、表和其他信息,如日志文件和状态文件。
mysqld 作为 Unix 守护进程或 Windows 服务,恒久等待请求并在后台执行维护工作。
- MySQLdb
-
开源Python模块的名称,该模块是 MySQL Python API的基础。
另见Python,Python API。
- mysqldump
-
一个命令,执行某些数据库、表和表数据的逻辑备份。结果是重现原始架构对象、数据或两者的 SQL 语句。对于大量数据,使用MySQL Enterprise Backup等物理备份解决方案,特别是在恢复操作中更快。
- .NET
- native C API
-
另见 libmysql。
- natural key
-
-
如果值需要更改,可能需要对 聚簇索引 进行大量维护,并更新每个 次要索引 中的主键值副本。
-
即使看似稳定的值也可能以不可预测的方式更改,难以在数据库中正确表示。例如,一个国家可能分裂成两个或多个,使原始国家代码过时。或者,关于唯一值的规则可能有例外。例如,即使纳税人 ID 号码旨在单个人员唯一,但数据库可能需要处理违反该规则的记录,例如身份盗用案例。纳税人 ID 号码和其他敏感 ID 号码也使得主键不良,因为它们可能需要加密、加密和与其他列不同的处理。
因此,通常更好地使用任意数字值来形成 合成键,例如使用 自动递增 列。
-
- neighbor page
-
在同一个 范围 中的任何 页。当一页被选择以被 刷新 时,任何邻近页如果是 脏页 也将被刷新,以便在传统硬盘上进行 I/O 优化。在 MySQL 5.6 及更高版本中,该行为可以通过配置变量
innodb_flush_neighbors
控制;您可能需要为 SSD 驱动器关闭该设置,因为它们不具有相同的写入小批量数据的开销。 - next-key lock
-
在索引记录上的 记录锁 和索引记录前的 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 原则。在事务中,数据应该是一致的,具有可预测的和稳定的关系。
在不同的 隔离级别 中,不可重复读取被 可序列化读取 和 可重复读取 级别所防止,而在 一致读取 和 未提交读取 级别中被允许。
- nonblocking I/O
-
industry术语,表示与异步I/O相同。
另请参阅 异步I/O。
- normalized
-
数据库设计策略,其中数据被拆分为多个表,并将重复值压缩到单行中,使用ID表示,以避免存储、查询和更新冗长或冗长的值。它通常用于OLTP应用程序中。
例如,地址可能被赋予唯一的ID,以便人口普查数据库可以通过关联该ID来表示居住在该地址关系,而不是存储多个副本的复杂值,如123 Main Street, Anytown, USA。
例如,虽然简单的地址簿应用程序可能将每个电话号码存储在同一个表中的人名和地址中,但电话公司数据库可能会给每个电话号码分配特殊的ID,并将号码和ID存储在单独的表中。这种规范化表示可以简化大规模更新时的区域代码拆分。
规范化并不总是推荐的。主要用于查询的数据,并且仅通过删除整个重新加载来更新,通常保持在较少的、较大的表中,具有冗长的副本值。这种数据表示形式称为非规范化,经常出现在数据仓库应用程序中。
- NoSQL
-
广义术语,指不使用SQL语言作为主要机制来读取和写入数据的一组数据访问技术。一些NoSQL技术充当键值存储,只接受单值读取和写入;一些放松了ACID方法的限制;还有一些不需要预先规划的模式。MySQL用户可以通过使用memcached API直接访问某些MySQL表来结合NoSQL风格的处理速度和简单性与SQL操作的灵活性和便捷性。
- NOT NULL constraint
-
一种约束,指定列不能包含任何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
。
- .OPT file
-
包含数据库配置信息的文件。具有该扩展名的文件包含在由 mysqlbackup 命令生成的备份中,该命令来自 MySQL Enterprise Backup 产品。
- ODBC
-
Open Database Connectivity 的缩写,一个行业标准 API。通常用于 Windows 基础服务器或需要使用 ODBC 与 MySQL 通信的应用程序。MySQL 的 ODBC 驱动程序称为 Connector/ODBC。
另见 Connector/ODBC。
- off-page column
-
包含可变长度数据(例如
BLOB
和VARCHAR
)的列,该数据太长无法存储在 B-tree 页上。数据存储在 溢出页 中。DYNAMIC 行格式比旧的 COMPACT 行格式更适合这种存储。 - OLTP
-
缩写为“在线事务处理”。数据库系统或数据库应用程序,运行大量事务的工作负载,同时具有频繁的写入和读取操作,通常影响小量数据。例如,航空公司预订系统或处理银行存款的应用程序。数据可能以 标准化 形式组织,以平衡 DML(插入/更新/删除)效率和 查询 效率。与 数据仓库 相比。
由于其 行级锁定 和 事务 能力,InnoDB 是 MySQL 表用于 OLTP 应用程序的理想存储引擎。
- online
-
一种不需要停机、阻塞或限制数据库操作的操作。通常应用于 DDL。例如,快速索引创建 等操作已经演变为 MySQL 5.6 中的一组更广泛的 在线 DDL 操作。
在备份的上下文中,热备份是一个在线操作,而温备份则部分是在线操作。
- online DDL
-
一个改进了
InnoDB
表性能、并发性和可用性的功能,主要用于 DDL(主要是ALTER TABLE
)操作。详见第17.12节,“InnoDB和在线DDL”。细节根据操作类型而异。在某些情况下,表可以在
ALTER TABLE
进行时被修改。操作可能可以在不复制表的情况下进行,或者使用特殊优化的表复制方式。DML日志空间使用情况由innodb_online_alter_log_max_size
配置选项控制。该功能是 MySQL 5.5 中 快速索引创建 功能的增强。
- optimistic
-
关系数据库系统的低级实现决策指南。性能和 并发性 的要求意味着操作必须快速启动或分派。一致性和 参照完整性 的要求意味着任何操作都可能失败:事务可能回滚,DML 操作可能违反约束,锁请求可能导致死锁,网络错误可能导致超时。乐观策略是指大多数请求或尝试都成功,因此数据库不需要做太多无用的工作;当请求失败时,需要做额外的工作来清理和撤销更改。
InnoDB
使用乐观策略来处理锁定和 提交 操作。例如,在事务提交之前,可以将更改的数据写入数据文件,使提交本身非常快,但需要更多的工作来撤销更改如果事务回滚。乐观策略的对立面是 悲观 策略,其中系统被优化以处理不可靠和频繁失败的操作。这在数据库系统中很少见,因为选择了可靠的硬件、网络和算法。
- optimizer
- option
-
MySQL 配置参数,存储在 选项文件 中或通过命令行传递。
对于 InnoDB 表的选项,每个选项名称以
innodb_
前缀开头。 - option file
-
该文件持有 MySQL 实例的 选项。传统上,在 Linux 和 Unix 中该文件名为
my.cnf
,在 Windows 中名为my.ini
。 - overflow page
-
单独分配的磁盘 页,用于存储变长列(如
BLOB
和VARCHAR
)这些列太长,无法容纳在 B 树 页上。这些列被称为 离页列。
- .par file
-
包含分区定义的文件。该扩展名文件包含在由
mysqlbackup
命令生成的备份中,该命令来自 MySQL 企业备份 产品。随着 MySQL 5.7.6 中引入的原生分区支持,
.par
文件不再为分区的InnoDB
表创建。在 MySQL 5.7 中,分区的MyISAM
表继续使用.par
文件。从 MySQL 8.0 开始,分区支持仅由InnoDB
存储引擎提供。因此,.par
文件不再使用自 MySQL 8.0 起。 - 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 应用程序。当单个行被更新时,少量数据被复制到内存中,写入磁盘,重新组织,锁定等。
- parent table
-
在 外键 关系中,持有初始列值的表,指向 子表。根据
ON UPDATE
和ON DELETE
子句在外键定义中,删除或更新父表中的行可能会自动删除或更新子表中的行,或者将这些列设置为NULL
,或者阻止操作。 - partial backup
- partial index
- 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 语言。通过
DBI
和DBD::mysql
模块实现。详细信息,请参阅 第 31.9 节,“MySQL Perl API”。 - 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。
- PHP API
-
多个 API 可用于编写 MySQL 应用程序在 PHP 语言中:原始 MySQL API (
Mysql
) MySQL Improved Extension (Mysqli
) MySQL Native Driver (Mysqlnd
) MySQL 函数 (PDO_MYSQL
), 和 Connector/PHP。有关详细信息,请参阅 MySQL 和 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 连接的端口。
- prefix
-
另见 索引前缀。
- prepared backup
-
由 MySQL Enterprise Backup 产品生成的一组备份文件,在应用 二进制日志 和 增量备份 的所有阶段后。结果文件准备好被 恢复。在应用步骤之前,这些文件被称为 原始备份。
- prepared statement
-
预先分析的 SQL 语句,以确定高效的执行计划。它可以多次执行,而不需要每次都进行解析和分析。每次可以通过使用占位符将不同的值替换到 WHERE 子句中,这种替换技术可以提高安全性,防止某些类型的 SQL 注入攻击。您还可以减少将返回值复制到程序变量中的开销。
虽然您可以直接通过 SQL 语法使用预备语句,但是各种 连接器 都有编程接口来操作预备语句,这些 API 比通过 SQL 更高效。
- primary key
-
一组可以唯一标识表中每一行的列——因此,它必须是一个唯一索引,不包含任何
NULL
值。InnoDB
需要每个表都有这样的索引(也称为 聚簇索引 或 簇索引),并根据主键的列值组织表存储。选择主键值时,考虑使用任意值(一个 合成键)而不是依赖于其他来源的值(一个 自然键)。
- principal
- 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
- query
-
在 SQL 中,从一个或多个 表 中读取信息的操作。根据数据的组织方式和查询参数,查找可能通过咨询 索引 来优化。如果涉及多个表,则查询称为 连接。
出于历史原因,有时讨论语句的内部处理使用 “查询” 一词,以涵盖 MySQL 语句的其他类型,例如 DDL 和 DML 语句。
- query execution plan
-
优化器关于如何最有效地执行 查询 的一系列决定,包括哪些 索引 或索引使用,以及连接表的顺序。计划稳定性 涉及到对给定查询的一致选择。
- query log
-
另请参阅 通用查询日志。
- quiesce
-
为了减少数据库活动,通常是在准备某些操作之前,如
ALTER TABLE
,备份,或关闭。可能或不可能涉及尽可能多地执行刷新,以便InnoDB不再执行后台I/O。在MySQL 5.6及更高版本中,语法
FLUSH TABLES... FOR EXPORT
将一些数据写入磁盘,以便备份InnoDB表格时可以通过复制数据文件。
- R-tree
-
一个树形数据结构,用于多维数据的空间索引,如地理坐标、矩形或多边形。
另见B-tree。
- 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
仍然可用于向后兼容。 - read phenomena
- READ UNCOMMITTED
-
该隔离级别提供了最少的保护之间的事务。查询采用锁定策略,允许它们在通常情况下等待另一个事务的情况下继续进行。然而,这种额外的性能来换取的是结果的可靠性较低,包括尚未提交的数据(也称为 脏读)。请谨慎使用该隔离级别,并注意结果可能不一致或不可重复,取决于其他事务同时执行的情况。通常,具有该隔离级别的事务仅执行查询,而不是插入、更新或删除操作。
- read view
-
InnoDB
的 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 值表示通过重做日志传输的累积重做数据量。 - redo log
-
一个基于磁盘的数据结构,在 崩溃恢复 期间用于纠正不完整 事务 写入的数据。在正常操作期间,它对
InnoDB
表数据的更改请求进行编码,这些更改来自 SQL 语句或低级 API 调用。在意外 shutdown 之前未完成更新 数据文件 的修改将自动重放。重做日志在磁盘上以一组重做日志文件形式存在。重做日志数据以受影响记录的形式编码,这些数据统称为 重做。数据通过重做日志的传输由不断增加的 LSN 值表示。
更多信息,请参见 第 17.6.5 节,“重做日志”。
- 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 行格式”。
- referential integrity
-
一种保持数据始终一致的技术,是 ACID 哲学的一部分。特别是,通过使用 外键约束,数据在不同的表中保持一致,这些约束可以防止更改或自动将更改传播到所有相关表。相关机制包括 唯一约束,它防止重复值被插入错误,以及 NOT NULL 约束,它防止空值被插入错误。
- relational
-
现代数据库系统的一个重要方面。数据库服务器编码和执行关系,如一对一、一对多、多对一和唯一性。例如,在地址数据库中,一人可能有零、一个或多个电话号码;单个电话号码可能与多个家庭成员相关。在财务数据库中,一个人可能需要有一个唯一的纳税人ID,每个纳税人ID只能与一个人相关。
数据库服务器可以使用这些关系来防止坏数据的插入,并找到查找信息的高效方式。例如,如果一个值被声明为唯一,服务器可以在找到第一个匹配时停止搜索,并拒绝插入第二个副本的相同值。
在数据库级别,这些关系通过SQL功能表达,如表中的列、唯一和
NOT NULL
约束、外键和不同的连接操作。复杂的关系通常涉及多个表之间的数据分割。通常,数据是规范化的,以便在一对多关系中存储唯一值。在数学上下文中,数据库中的关系来自集合理论。例如,
WHERE
子句中的OR
和AND
运算符表示union和交集的概念。 - 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
仍然可用于向后兼容。 - repertoire
-
库是字符集的一个术语。字符集库是集合中的字符集。见 第 12.2.1 节,“字符集库”。
- replica
-
在复制拓扑结构中,一个数据库服务器机器,它从另一个服务器(源)接收更改,并应用相同的更改。因此,它维护与源相同的内容,尽管可能落后一些。
在 MySQL 中,副本通常用于灾难恢复,以取代失败的源服务器。它们也常用于测试软件升级和新设置,以确保数据库配置更改不会导致性能或可靠性问题。
副本通常具有高工作负载,因为它们处理来自源的所有 DML(写)操作,以及用户查询。为了确保副本可以快速应用来自源的更改,它们通常具有快速的 I/O 设备和足够的 CPU 和内存,以在同一服务器上运行多个数据库实例。例如,源可能使用硬盘存储,而副本使用 SSDs。
- replication
-
从 源 将更改发送到一个或多个 副本,以便所有数据库具有相同的数据。这项技术有广泛的应用,例如负载均衡以提高可扩展性、灾难恢复、测试软件升级和配置更改。这些更改可以通过称为 行 기반复制 和 语句基于复制 的方法在数据库之间发送。
- restore
-
将 MySQL Enterprise Backup 产品的备份文件集置于 MySQL 使用的过程。这项操作可以用于修复损坏的数据库、返回到某个早期时间点或(在 复制 上下文中)设置新的 副本。在 MySQL Enterprise Backup 产品中,这项操作由
copy-back
选项的mysqlbackup
命令执行。另见 热备份, MySQL Enterprise Backup, mysqlbackup 命令, 预备备份, 副本, 复制。
- rollback
-
一条 SQL 语句,结束一个 事务,撤销事务中的所有更改。这是 提交 的反义词,后者使事务中的所有更改永久化。
默认情况下,MySQL 使用 自动提交 设置,该设置在每个 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. AsInnoDB
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 theROW_FORMAT
option or by theinnodb_default_row_format
configuration option (introduced in MySQL 5.7.9). Row formats includeREDUNDANT
,COMPACT
,COMPRESSED
, andDYNAMIC
. To view the row format of anInnoDB
table, issue theSHOW TABLE STATUS
statement or queryInnoDB
table metadata in theINFORMATION_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 onInnoDB
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).
- Ruby
- Ruby API
-
基于 libmysqlclient API 库的
mysql2
,适用于 Ruby 程序员开发 MySQL 应用程序。有关更多信息,请参阅 第 31.11 节,“MySQL Ruby APIs”。 - 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_size
和innodb_buffer_pool_instances
。与水平扩展相对。 - 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 及更高版本中,
InnoDB
和MyISAM
表都支持FULLTEXT
索引;以前,这些索引仅适用于MyISAM
表。See Also 全文搜索, 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
的默认隔离级别是下一个最严格的,可重复读取。 - serialized dictionary information (SDI)
-
字典对象元数据的序列化形式。SDI 以
JSON
格式存储。从 MySQL 8.0.3 开始,SDI 存在于所有
InnoDB
表空间文件中,除了临时表空间文件和撤销表空间文件。表空间文件中的 SDI 提供了元数据冗余。例如,使用 ibd2sdi 实用程序可以从表空间文件中提取字典对象元数据,如果数据字典不可用。对于
MyISAM
表,SDI 存储在模式目录中的.sdi
元数据文件中。SDI 元数据文件是执行IMPORT TABLE
操作所需的。 - server
-
一种程序,持续运行,等待从另一个程序(客户端)接收和处理请求。因为通常整个计算机都是专门运行一个或多个服务器程序(如数据库服务器、Web 服务器、应用服务器或这些的组合),因此术语“服务器”也可以指运行服务器软件的计算机。
- server-side prepared statement
-
由 MySQL 服务器管理的准备语句。历史上,服务器端准备语句的问题导致 Connector/J 和 Connector/PHP 开发人员有时使用客户端准备语句。使用现代 MySQL 服务器版本,服务器端准备语句被推荐用于性能、可扩展性和内存效率。
另见 客户端准备语句, Connector/J, Connector/PHP, 准备语句。
- service principal name
-
另见 principal。
- service ticket
- servlet
-
另见 Connector/J。
- session temporary tablespace
- shared lock
- shared tablespace
-
另一种方式,指系统表空间或通用表空间。通用表空间是在 MySQL 5.7 中引入的。多个表可以驻留在共享表空间中。只有一个表可以驻留在每个文件表空间中。
- sharp checkpoint
-
将所有脏缓冲池页面刷新到磁盘,这些页面的重做日志条目包含在某个重做日志部分中。发生在 InnoDB 重用日志文件的一部分之前;日志文件以循环方式使用。通常发生在写入密集型工作负载中。
- shutdown
-
停止 MySQL 服务器的过程。默认情况下,该过程清理 InnoDB 表的操作,因此 InnoDB 可能慢慢关闭,但下次启动速度很快。如果跳过清理操作,关闭速度将很快,但下次启动时必须执行清理。
InnoDB 的关闭模式由
innodb_fast_shutdown
选项控制。 - 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
。在传输表空间文件时,需要传输的信息包含在 .cfg 文件 中。请参阅 第 17.6.1.3 节,“导入 InnoDB 表” 了解详细信息。 - 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 特定的函数用于查询。
- SQLState
-
由 JDBC 标准定义的错误代码,用于应用程序使用 Connector/J 的异常处理。
另见 Connector/J, JDBC。
- SSD
-
“固态驱动器”的缩写。是一种存储设备,具有与传统硬盘驱动器(HDD)不同的性能特征:较小的存储容量,随机读取速度更快,无移动部件,并且写入性能受到多种因素的影响。其性能特征可能会影响磁盘绑定的工作负载的吞吐量。
- SSL
- ST
-
另见 服务票据。
- startup
-
启动 MySQL 服务器的过程。通常由 第 6.3 节,“服务器和服务器启动程序” 中列出的程序之一完成。与 shutdown 相反。
另见 shutdown。
- statement interceptor
-
一种用于跟踪、调试或增强数据库应用程序所发出的 SQL 语句的 拦截器。有时也称为 命令拦截器。
在使用 Connector/J 的 Java 应用程序中,设置这种类型的拦截器涉及实现
com.mysql.jdbc.StatementInterceptorV2
接口,并将statementInterceptors
属性添加到 连接字符串 中。在使用 Connector/NET 的 Visual Studio 应用程序中,设置这种类型的拦截器涉及定义继承自
BaseCommandInterceptor
类的类,并将该类名指定为连接字符串的一部分。另见 命令拦截器, 连接字符串, Connector/J, Connector/NET, 拦截器, Java, Visual Studio。
- statement-based replication
-
一种形式的 复制,其中 SQL 语句从 源 发送并在 副本 上重放。它需要对
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
-
在表示 缓冲池 的列表结构中,相对老的和相对新的页面由列表的不同部分表示。一些参数控制这些部分的大小和老页面与新页面之间的分界点。
- 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 forInnoDB
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 useInnoDB
features that rely onDYNAMIC
andCOMPRESSED
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 usingCREATE 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
表在每表文件表空间中可以使用 DYNAMIC 或 COMPRESSED 行格式。这些行格式启用InnoDB
功能,如 压缩、非页列的高效存储和大索引键前缀。通用表空间支持所有行格式。系统表空间支持使用 REDUNDANT、COMPACT 和 DYNAMIC 行格式的表。系统表空间对 DYNAMIC 行格式的支持是在 MySQL 5.7.6 中添加的。
InnoDB 表的 行 按照 聚簇索引 结构组织,按照表的 主键 列排序。数据访问针对主键列的查询和排序进行了优化,每个索引包含关联主键列的副本。修改主键列的值是一个昂贵的操作。因此,InnoDB 表设计的重要方面是选择一个主键,以便在最重要的查询中使用,并保持主键短小,具有不常更改的值。
也见 备份、聚簇索引、紧凑行格式、压缩行格式、压缩、动态行格式、快速索引创建、每表文件、.ibd 文件、索引、非页列、主键、冗余行格式、行、系统表空间、表空间。
-
- table lock
-
防止其他任何 事务 访问表的锁。
InnoDB
通过使用诸如 在线 DDL、行锁 和 一致读取 等技术来尽量减少这种锁的使用。在 SQL 中,您可以使用LOCK TABLE
语句创建这种锁;在从其他数据库系统或 MySQL 存储引擎迁移到时,需要尽量删除这些语句。 - table scan
-
另见 全表扫描。
- table statistics
-
另见 统计信息。
- table type
- 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 脚本世界的编程语言。有时由 C、C++ 或 Java 代码扩展。对于 MySQL 的开源 Tcl API,请参阅 第 31.12 节,“MySQL Tcl API”。
另见 API。
- temporary table
-
一个不需要永久保存的表。例如,临时表可能用作复杂计算或转换的中间结果存储区域;这些中间数据在崩溃后不需要恢复。数据库产品可以采取各种捷径来提高临时表操作的性能,例如减少对磁盘的写入和其他保护数据的措施。
有时,数据本身会在设定的时间自动删除,例如事务结束或会话结束时。一些数据库产品还会自动删除表本身。
参见 表。
- temporary tablespace
-
InnoDB
使用两种类型的临时表空间。会话临时表空间 存储用户创建的临时表和优化器创建的内部临时表。全局临时表空间 存储用户创建的临时表的回滚段。 - text collection
-
参见 FULLTEXT 索引。
- TGS
-
一个 Kerberos 票据授予服务器。TGS 也可以指票据授予服务器提供的票据授予服务。
参见 票据授予服务器。
- TGT
-
参见 票据授予票据。
- thread
- 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属性,即原子性、一致性、隔离性和持久性。
- transaction ID
- transparent page compression
-
MySQL 5.7.8 中添加的一个功能,允许对
InnoDB
表进行页面级压缩,该表驻留在 每个表文件 表空间中。页面压缩可以通过指定COMPRESSION
属性与CREATE TABLE
或ALTER TABLE
实现。更多信息,请参阅 第 17.9.2 节,“InnoDB 页面压缩”。 - transportable tablespace
-
允许将 表空间 从一个实例迁移到另一个实例。传统上,这在
InnoDB
表空间中是不可能的,因为所有表数据都是 系统表空间 的一部分。在 MySQL 5.6 及更高版本中,使用FLUSH TABLES ... FOR EXPORT
语法可以准备InnoDB
表以便复制到另一个服务器;在另一个服务器上运行ALTER TABLE ... DISCARD TABLESPACE
和ALTER TABLE ... IMPORT TABLESPACE
可以将复制的数据文件导入到另一个实例中。一个单独的 .cfg 文件,与 .ibd 文件 一起复制,用于更新表元数据(例如 空间 ID)当表空间被导入时。请参阅 第 17.6.1.3 节,“导入 InnoDB 表” 获取使用信息。 - troubleshooting
- truncate
-
一种 DDL 操作,它删除表的所有内容,同时保留表和相关索引不变。与 drop 相比。虽然概念上它与
DELETE
语句无WHERE
子句相同,但是在幕后它的工作方式不同:InnoDB
创建一个新的空表,删除旧表,然后将新表重命名为旧表的名称。因为这是一个 DDL 操作,所以它不能 回滚。如果被截断的表包含 外键,引用另一个表,截断操作使用较慢的操作方式,逐行删除,以便在需要时删除相关表中的行,根据
ON DELETE CASCADE
子句。(MySQL 5.5 及更高版本不允许这种较慢的截断形式,并在涉及外键时返回错误。 在这种情况下,使用DELETE
语句 instead。 - truststore
-
另见 SSL。
- tuple
-
一个技术术语,指的是一个有序元素集。这是一个抽象概念,用于数据库理论的正式讨论。在数据库领域,元组通常由表行的列表示。它们也可以由查询结果集表示,例如,仅检索表的一些列,或者来自连接表的列。
另见 游标。
- two-phase commit
-
分布式 事务 的一部分,根据 XA 规范。(有时缩写为 2PC。)当多个数据库参与事务时,或者所有数据库 提交 更改,或者所有数据库 回滚 更改。
- 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 驱动程序。
另请参阅:ANSI、Connector/ODBC、ODBC。
- unique constraint
-
一种 约束,断言某列不能包含任何重复值。在关系代数中,它用于指定 1 对 1 的关系。为了检查某个值是否可以插入(即该值不在该列中已经存在),唯一约束由一个底层 唯一索引 支持。
- unique index
-
在某列或一组列上具有 唯一约束 的索引。因为该索引已知不包含任何重复值,因此某些查找和计数操作比普通索引更高效。大多数对该类型索引的查找只是为了确定某个值是否存在。该索引中的值数量与表中的行数相同,或者至少是该列的非空值数量。
更改缓冲 优化不适用于唯一索引。作为解决方法,可以在批量加载数据到
InnoDB
表时临时将unique_checks=0
。 - unique key
-
由一个或多个列组成的 唯一索引。当您可以定义一个精确匹配一行的
WHERE
条件,并且查询可以使用关联的唯一索引时,查找和错误处理可以非常高效地执行。 - UPN
-
另见 用户主体名称。
- user principal name
-
另见 主体。
- variable-length type
-
变长数据类型。
VARCHAR
、VARBINARY
和BLOB
和TEXT
类型是变长类型。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/NET:Connector/NET 版本
-
Connector/C++ 8.0:平台支持和先决条件
-
- wait
-
当操作,如获取 锁、互斥体 或 闩,无法立即完成时,
InnoDB
会暂停并重试。这种机制足够复杂,以至于这个操作有了自己的名称,即 等待。单个线程使用内部InnoDB
调度、操作系统wait()
调用和短期 自旋 循环暂停。在系统负载重且有许多事务的情况下,您可能使用
SHOW INNODB STATUS
命令或 性能模式 来确定线程是否花费太多时间等待,如果是这样,您可以如何改善 并发性。 - warm backup
-
在数据库运行时采取的 备份,但限制了一些数据库操作的过程。例如,表可能变为只读。对于繁忙的应用程序和网站,您可能更喜欢 热备份。
- warm up
-
在系统启动后,让系统在典型的 工作负载 下运行一段时间,以便 缓冲池 和其他内存区域像正常情况下那样填充。这过程自然地发生在 MySQL 服务器重新启动或受到新工作负载时。
通常,您在性能测试前让工作负载运行一段时间,以便缓冲池预热,以确保多次运行的结果一致;否则,性能可能在第一次运行时人为地降低。
在 MySQL 5.6 中,您可以通过启用
innodb_buffer_pool_dump_at_shutdown
和innodb_buffer_pool_load_at_startup
配置选项来加速预热过程,以便在重新启动后将缓冲池的内容带回内存中。这些选项在 MySQL 5.7 中默认启用。另见 第 17.8.3.6 节,“保存和恢复缓冲池状态”。 - workload
-
数据库应用程序在典型或峰值使用时的 SQL 和其他数据库操作的组合和体积。在性能测试中,您可以对数据库施加特定的工作负载,以确定 瓶颈,或在容量规划中。
- write combining
-
一种优化技术,减少了从
InnoDB
缓冲池 中刷新 脏页 时的写操作。如果一页上的行被多次更新,或者一页上的多行被更新,那么所有这些更改都将在单个写操作中存储到数据文件中,而不是每个更改一个写操作。
- young
-
页在
InnoDB
缓冲池中的一个特征,表示它最近被访问过,因此在缓冲池数据结构中被移动,以免被 LRU 算法太快地 刷新。该术语用于某些与缓冲池相关的 INFORMATION_SCHEMA 表的列名中。另请参阅:缓冲池、刷新、INFORMATION_SCHEMA、LRU、页。