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

另请参阅 .ARZ文件 ， MySQL Enterprise Backup ， mysqlbackup命令 。

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

另请参见 .ARM文件 ， MySQL Enterprise Backup ， mysqlbackup命令 。

代表原子性，一致性，隔离性和耐久性的首字母缩略词。 这些属性在数据库系统中都是可取的，并且都与 事务 的概念密切相关 。 InnoDB 遵守ACID原则 的交易特征 。

事务是 可以 提交 或 回滚的 原子 工作单元 。 当事务对数据库进行多次更改时，要么在提交事务时所有更改都成功，要么在事务回滚时撤消所有更改。

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

交易在进行过程中受到保护（隔离）; 他们不能互相干扰或看到彼此未提交的数据。 这种隔离是通过 锁定 机制 实现的 。 经验丰富的用户可以调整 隔离级别 ，在 保证事务确实不会相互干扰的情况下， 减少保护以支持提高性能和 并发性 。

事务的结果是持久的：一旦提交操作成功，该事务所做的更改就可以避免电源故障，系统崩溃，竞争条件或许多非数据库应用程序易受攻击的其他潜在危险。 耐用性通常涉及写入磁盘存储，具有一定的冗余以防止写入操作期间的电源故障或软件崩溃。 （在 InnoDB ， 双重写入缓冲区 有助于提高耐用性。）

另请参阅 原子 ， 提交 ， 并发 ， 双写缓冲区 ， 隔离级别 ， 锁定 ， 回滚 ， 事务 。

InnoDB 表 的算法， 可以平滑 检查点 引入的I / O开销 。 取而代之的 冲洗 所有已修改 页面 从 缓冲池 的 数据文件 一次，MySQL的定期刷新小套修改页面。 自适应刷新算法通过基于刷新率和 生成 重做 信息的 速度来估计执行这些周期性刷新的最佳速率来扩展该过程 。

另请参阅 缓冲池 ， 检查点 ， 数据文件 ， 刷新 ， InnoDB ， 页面 ， 重做日志 。

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

哈希索引始终基于表上的现有 B树 索引 构建 。 MySQL可以在为B树定义的任意长度的密钥的前缀上构建哈希索引，具体取决于针对索引的搜索模式。 哈希索引可以是部分的; 整个B树索引不需要缓存在缓冲池中。

在MySQL 5.6及更高版本中，利用表的快速单值查找的另一种方法 InnoDB 是使用 InnoDB memcached 插件。 有关 详细信息 ， 请参见 第15.19节“InnoDB memcached插件” 。

另请参见 B树 ， 缓冲池 ， 哈希索引 ， memcached ， 页面 ， 二级索引 。

异步I / O的 缩写 。 您可能会在 InnoDB 消息或关键字中 看到此首字母缩略词 。

另请参见 异步I / O 。

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

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

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

另请参阅 热备份 ， ibbackup_logfile ， MySQL Enterprise Backup ， 准备备份 ， 原始备份 。

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

过去， InnoDB 仅在Windows系统上使用异步I / O. 从InnoDB Plugin 1.1和MySQL 5.5开始， InnoDB 在Linux系统上使用异步I / O. 此更改引入了依赖性 libaio 。 Linux系统上的异步I / O使用 innodb_use_native_aio 默认启用 的 选项进行 配置 。 在其他类Unix系统上，InnoDB仅使用同步I / O.

另请参阅 缓冲池 ， 非阻塞I / O 。

在SQL上下文中， 事务 是完全成功（ 提交时 ）或完全没有效果（ 回滚时 ）的工作单元。 事务的不可分割（“原子”）属性是 首字母缩写词 ACID中 的 “ A ” 。

另请参见 ACID ， 提交 ， 回滚 ， 事务 。

原子 DDL 语句将 数据字典 更新， 存储引擎 操作和 与DDL操作关联的 二进制日志 写入组合到单个原子事务中。 即使服务器在操作期间暂停，事务也可以完全提交或回滚。 MySQL 8.0中添加了Atomic DDL支持。 有关更多信息，请参见 第13.1.1节“原子数据定义语句支持” 。

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

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

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

它为开发人员节省了工作，而不必在插入新行时生成新的唯一值。 它为查询优化器提供了有用的信息，因为已知该列不为null且具有唯一值。 来自这样一列的值可以在各种上下文中用作查找键，并且因为它们是自动生成的，所以没有理由改变它们。 因此，主键列通常被指定为自动递增。

使用基于语句的复制可能会出现自动增量列的问题，因为由于计时问题，重播从站上的语句可能不会产生与主服务器上相同的列值集。 如果有自动递增主键，则只能使用基于语句的复制设置 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 ， 主键 ， 基于行的复制 ， 基于语句的复制 。

自动增量 主键 的便利性 涉及一些与并发的权衡。 在最简单的情况下，如果一个事务正在向表中插入值，则任何其他事务必须等待对该表执行自己的插入，以便第一个事务插入的行接收连续的主键值。 InnoDB 包括优化和 innodb_autoinc_lock_mode 选项，以便您可以在可预测的自动增量值序列和 插入操作的 最大 并发 之间配置和实现最佳平衡 。

另请参见 auto-increment ， concurrency ， innodb_autoinc_lock_mode 。

在每个 SQL 语句 之后 导致 提交 操作的 设置 。 不建议使用这种工作模式 表与 交易 跨越几个语句。 它可以帮助表现为 只读事务 上 的表，它从开销减少 锁定 和生成的 撤销 数据，尤其是在MySQL 5.6.4及以上。 它也适用于处理 不适用交易的表格。 InnoDB InnoDB MyISAM

另请参见 commit ， locking ， 只读事务 ， SQL ， 事务 ， 撤消 。

能够应对主机上的故障，并在必要时从中恢复故障，包括MySQL，操作系统或可能导致停机的硬件和维护活动的故障。 通常将 可伸缩性 与大规模部署的关键方面相结合。

另请参见 可伸缩性 。

一种在数据库索引中很常用的树数据结构。 结构始终保持排序，从而能够快速查找完全匹配（等于运算符）和范围（例如，大于，小于和 BETWEEN 运算符）。 这种类型的索引可用于大多数存储引擎，例如 InnoDB 和 MyISAM 。

因为B树节点可以有许多子节点，所以B树与二叉树不同，二叉树每个节点限制为2个子节点。

与 哈希索引 形成 对比， 哈希索引 仅在 MEMORY 存储引擎中 可用 。 该 MEMORY 存储引擎也可以用B-tree索引，你应该选择B树索引 MEMORY 的表，如果某些查询使用范围经营。

术语B树的使用旨在作为一般索引设计类的参考。 由于经典B树设计中不存在的复杂性，MySQL存储引擎使用的B树结构可以被视为变体。 有关相关信息，请参阅 MySQL Internals Manual 的 InnoDB 页面结构 Fil Header 部分 。

另请参见 哈希索引 。

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

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

另请参见 SQL 。

从MySQL实例复制部分或全部表数据和元数据的过程，以便妥善保管。 也可以参考复制文件集。 这对DBA来说是一项至关重要的任务。 此过程的反向是 还原 操作。

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

备份进一步分为 热 ， 暖 或 冷， 具体取决于它们对正常数据库操作的干扰程度。 （热备份干扰最小，冷备份最多。）

另请参阅 冷备份 ， 热备份 ， 逻辑备份 ， MySQL企业备份 ， mysqldump ， 物理备份 ， 热备份 。

存储生成的列或虚拟生成列所基于的非生成表列。 换句话说，基本列是非生成的表列，它是生成的列定义的一部分。

另请参见 生成列 ， 存储生成列 ， 虚拟生成列 。

软件产品生命周期的早期阶段，当它仅用于评估时，通常没有明确的版本号或小于1的数字。 InnoDB 不使用beta标识，更喜欢 可以延伸到几个点 的 早期采用者 阶段发布，导致 GA 发布。

另见 早期采用者 ， GA 。

包含尝试更改表数据的所有语句的记录的文件。 可以重播这些语句，以便在 复制 方案 中使从属服务器保持最新 ，或者在从备份还原表数据后使数据库保持最新。 可以打开和关闭二进制日志记录功能，但如果您使用复制或执行备份，Oracle建议始终启用它。

您可以使用 mysqlbinlog 命令 检查二进制日志的内容，或在复制或恢复期间重播这些语句 。 有关二进制日志的完整信息，请参见 第5.4.4节“二进制日志” 。 有关与二进制日志相关的MySQL配置选项，请参见 第17.1.6.4节“二进制日志记录选项和变量” 。

对于 MySQL Enterprise Backup 产品，二进制日志的文件名和文件中的当前位置是重要的详细信息。 要在复制上下文中进行备份时记录主服务器的此信息，可以指定该 --slave-info 选项。

在MySQL 5.0之前，可以使用类似的功能，称为更新日志。 在MySQL 5.0及更高版本中，二进制日志替换了更新日志。

另请参阅 binlog ， MySQL Enterprise Backup ， 复制 。

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

另请参见 二进制日志 。

由 子句 启用的 特殊 全文搜索 模式 WITH QUERY EXPANSION 。 它执行两次搜索，其中第二次搜索的搜索短语是与来自第一次搜索的少数最高度相关的文档连接的原始搜索短语。 该技术主要适用于短搜索短语，可能只有一个单词。 它可以发现文档中未出现精确搜索词的相关匹配。

另请参见 全文搜索 。

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

另请参见 缓冲池 ， 并发 。

一个 关机 操作，紧接着将进行重新启动。 理想情况下， 预热 时间 相对较短， 因此性能和吞吐量很快就会恢复到较高水平。

另见 shutdown 。

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

另请参见 缓冲池 ， 页面 ， 页面大小 。

用于临时存储的内存或磁盘区域。 数据缓冲在内存中，因此可以通过一些大的I / O操作而不是许多小的I / O操作有效地写入磁盘。 数据在磁盘上缓冲以获得更高的可靠性，因此即使 在最糟糕的时间发生 崩溃 或其他故障 ，也可以恢复数据 。 InnoDB使用的主要缓冲区类型是 缓冲池 ， 双写缓冲区 和 更改缓冲区 。

另请参见 缓冲池 ， 更改缓冲区 ， 崩溃 ， 双写缓冲区 。

保存 InnoDB 表和索引的 高速缓存 数据 的内存区域 。 为了提高大容量读取操作的效率，缓冲池被分成 可以容纳多行的 页面 。 为了提高缓存管理的效率，缓冲池被实现为链接的页面列表; 使用 LRU 算法 的变体，很少使用的数据在缓存中老化 。 在具有大内存的系统上，可以通过将缓冲池划分为多个 缓冲池实例 来提高并发性 。

多个 InnoDB 状态变量， INFORMATION_SCHEMA 表和 performance_schema 表有助于监视缓冲池的内部工作方式。 从MySQL 5.6开始，通过在服务器关闭时保存缓冲池状态并在服务器启动时将缓冲池恢复到相同状态，可以在重新启动服务器后避免冗长的预热期，特别是对于具有大缓冲池的实例。 请参见 第15.8.3.7节“保存和恢复缓冲池状态” 。

另请参见 缓冲池实例 ， LRU ， 页面 ， 预热 。

缓冲池 可以划分 的多个区域中的任何一个 ，由 innodb_buffer_pool_instances 配置选项 控制 。 指定的总内存大小 innodb_buffer_pool_size 在所有缓冲池实例之间划分。 通常，具有多个缓冲池实例适用于为缓冲池分配多个千兆字节的系统， InnoDB 每个实例为1千兆字节或更大。 在从多个并发会话加载或查找缓冲池中的大量数据的系统上，具有多个缓冲池实例减少了对管理缓冲池的数据结构的独占访问的争用。

另请参见 缓冲池 。

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

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

另请参见 InnoDB 。

构成商业软件基础的行为的关系和顺序，用于经营商业公司。 有时这些规则由法律规定，有时则由公司政策规定。 仔细规划可确保数据库编码和实施的关系以及通过应用程序逻辑执行的操作能够准确反映公司的实际策略并能够处理实际情况。

例如，离开公司的员工可能会触发人力资源部门的一系列操作。 人力资源数据库可能还需要灵活地表示有关已被雇用但尚未开始工作的人的数据。 关闭在线服务的帐户可能会导致数据从数据库中删除，或者数据可能会被移动或标记，以便在重新打开帐户时可以恢复数据。 除了基本的健全性检查（例如工资不是负数）之外，公司可能会制定有关最高工资，最低工资和调整的政策。 零售数据库可能不允许使用相同序列号的购买多次返回，

另请参阅 关系 。

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

另请参见 .ibd文件 ， 空间ID ，可 传输表空间 。

存储区域的通用术语，用于存储频繁或高速检索的数据副本。 在 InnoDB ，缓存 池 的主要类型是 缓冲池 。

另请参见 buffer ， buffer pool 。

表 列中 的不同值的数量 。 当查询引用具有关联 索引 的列时，每列的基数会影响哪种访问方法最有效。 例如，对于具有 唯一约束 的列 ，不同值的数量等于表中的行数。 如果一个表有一百万行但只有一个特定列的10个不同值，则每个值（平均）发生100,000次。 SELECT c1 FROM t1 WHERE c1 = 50; 因此， 诸如此类的查询 可能返回1行或大量行，并且数据库服务器可能会根据基数来不同地处理查询 c1 。

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

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

另请参见 列 ， 复合索引 ， 索引 ， 索引提示 ， 随机潜水 ， 选择性 ， 唯一约束 。

一个特殊的数据结构，记录更改 网页 中 的辅助索引 。 这些值可能会导致从SQL INSERT ， UPDATE 或 DELETE 语句（ DML ）。 涉及更改缓冲区的一组功能统称为 更改缓冲 ，包括 插入缓冲 ， 删除缓冲 和 清除缓冲 。

当二级索引中的相关页面不在 缓冲池中 时，更改仅记录在更改缓冲区中 。 当相关索引页面进入缓冲池而关联更改仍在更改缓冲区中时，该页面的更改 将 使用更改缓冲区中的数据 应用于缓冲池（ 合并 ）。 在系统大部分空闲时或在慢速关闭期间运行 的 清除 操作会 定期 将新索引页写入磁盘。 与每个值立即写入磁盘的情况相比，清除操作可以更有效地写入一系列索引值的磁盘块。

物理上，更改缓冲区是 系统表空间的 一部分 ，因此索引更改在数据库重新启动时保持缓冲。 由于某些其他读取操作，当页面进入缓冲池时， 仅应用（ 合并 ） 更改 。

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

以前称为 插入缓冲区 。

另请参阅 缓冲池 ， 更改缓冲 ， 删除缓冲 ， DML ， 插入缓冲区 ， 插入缓冲 ， 合并 ， 页面 ， 清除 ， 清除缓冲 ， 二级索引 ， 系统表空间 。

涉及 更改缓冲区 的功能的通用术语 ，包括 插入缓冲 ， 删除缓冲 和 清除缓冲 。 SQL语句导致的索引更改（通常可能涉及随机I / O操作）会被后台 线程 保留并定期执行 。 与将每个值立即写入磁盘的情况相比，这一系列操作可以更有效地为一系列索引值写入磁盘块。 由控制 innodb_change_buffering 和 innodb_change_buffer_max_size 配置选项。

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

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

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

In InnoDB ，一种验证机制，用于 在将 表空间中 的 页面 从磁盘读入 缓冲池 时检测损坏 。 此功能由 MySQL 5.5中 的 配置选项 控制 。 在MySQL 5.6.3中被弃用，取而代之的是 。 InnoDB innodb_checksums innodb_checksums innodb_checksum_algorithm

该 innochecksum 命令有助于为指定的测试校验值诊断腐败问题 的表空间 ，而MySQL服务器关闭文件。

MySQL还使用校验和进行复制。 有关详细信息，请参阅配置选项 binlog_checksum ， master_verify_checksum 和 slave_sql_verify_checksum 。

另请参见 缓冲池 ， 页面 ， 表空间 。

在一个 外键 关系，一个子表是其行参考（或点）的行与另一个表中与一个特定的列相同的值。 这是包含 FOREIGN KEY ... REFERENCES 子句和可选 ON UPDATE 和 ON DELETE 子句的表。 在 可以在子表中创建行之前 ， 父表中 的相应行 必须存在。 子表中的值可以阻止对父表执行删除或更新操作，或者可以根据 ON CASCADE 创建外键时使用 的 选项 在子表中导致自动删除或更新 。

另请参见 外键 ， 父表 。

缓冲池中的 一个 页面 ， 其中所有在内存中进行的更改也已写入（ 刷新 ）到 数据文件中 。 脏页面 的反面 。 InnoDB

另请参见 缓冲池 ， 数据文件 ， 脏页 ， 刷新 ， 页面 。

一 关机 即完成，没有错误，适用所有更改 InnoDB 完成之前的表，而不是一个 崩溃 或 快速关机 。 慢关机的 同义词 。

另请参见 崩溃 ， 快速关闭 ， 关闭 ， 慢速关闭 。

一种程序，用于将请求发送到 服务器 ，并解释或处理结果。 客户端软件可能只在某些时候运行（例如邮件或聊天程序），并且可能以交互方式运行（例如 mysql 命令处理器）。

另见 mysql ， server 。

主键 索引 的 InnoDB 术语 。 表存储是根据主键列的值组织的，以加快涉及主键列的查询和排序。 为获得最佳性能，请根据性能最关键的查询仔细选择主键列。 因为修改聚簇索引的列是一项昂贵的操作，所以选择很少或从不更新的主列。 InnoDB

在Oracle数据库产品中，此类表称为 索引组织表 。

另请参见 索引 ， 主键 ， 二级索引 。

一个 备份 数据库的同时关闭服用。 对于繁忙的应用程序和网站，这可能不实用，您可能更喜欢 热备份 或 热备份 。

另请参阅 备份 ， 热备份 ， 热备份 。

一个内的数据项 的行 ，其存储和语义由数据类型进行定义。 每个 表 和 索引 主要由它包含的列集定义。

每列都有一个 基数 值。 列可以是 其表 的 主键 ， 也可以是 主键 的一部分。 列可以受 唯一约束 ， NOT NULL约束 或两者 约束 。 不同列中的值（甚至跨不同的表）可以通过 外键 关系 链接 。

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

另请参见 基数 ， 外键 ， 索引 ， NOT NULL约束 ， 主键 ， 行 ， 表 ， 唯一约束 。

单列 的 索引 。

另请参见 复合索引 ， 索引 。

当一个 索引 与一个长度规范，诸如创建 CREATE INDEX idx ON t1 (c1(N)) ，仅列值的所述第一N个字符被存储在索引中。 保持索引前缀较小使索引紧凑，内存和磁盘I / O节省有助于提高性能。 （虽然使索引前缀太小可能会阻碍查询优化，因为查询优化器会使重复的行具有不同的值。）

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

另见 索引 。

一个 SQL 语句结束的 交易 ，使得永久事务中做任何更改。 它与 回滚 相反 ，它撤消了在事务中所做的任何更改。

InnoDB 使用 乐观 机制进行提交，以便在提交实际发生之前将更改写入数据文件。 这种技术使提交本身更快，并且在回滚的情况下需要做更多的工作。

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

另请参见 autocommit ， optimistic ， rollback ， SQL ， transaction 。

一个 行格式 的InnoDB表。 这是从MySQL 5.0.3到MySQL 5.7.8的默认行格式。 在MySQL 8.0中，默认行格式由 innodb_default_row_format 配置选项 定义 ，其默认设置为 DYNAMIC 。 的 COMPACT 行格式提供空值和可变长度列比一个更紧凑的表示 冗余 行格式。

有关 InnoDB COMPACT 行格式的 其他信息 ，请参见 第15.10节“InnoDB行格式” 。

另请参见 动态行格式 ， 文件格式 ， 冗余行格式 ， 行格式 。

包含多个列 的 索引 。

另见 索引 。

MySQL Enterprise Backup 产品 的压缩功能生成 每个表空间的压缩副本，将扩展名更改 .ibd 为 .ibz 。 通过压缩备份数据，您可以保留更多备份，并缩短将备份传输到其他服务器的时间。 在还原操作期间，数据未压缩。 当压缩备份操作处理已经压缩的表时，它会跳过该表的压缩步骤，因为再次压缩会导致很少或没有空间节省。

由 MySQL Enterprise Backup 产品 生成的一组文件 ，其中每个 表空间都 被压缩。 压缩文件使用 .ibz 文件扩展名 重命名 。

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

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

一种 行格式 ， 用于为 表 启用数据和索引 压缩 InnoDB 。 大字段存储在远离保存其余行数据的页面的位置，如 动态行格式 。 索引页面和大字段都被压缩，从而节省了内存和磁盘。 根据数据的结构，内存和磁盘使用量的减少可能会或可能不会超过在使用时解压缩数据的性能开销。 有关 使用详细信息 ， 请参见 第15.9节“InnoDB表和页面压缩” 。

有关 InnoDB COMPRESSED 行格式的 其他信息 ，请参阅 DYNAMIC行格式 。

另请参见 压缩 ， 动态行格式 ， 行格式 。

以压缩形式存储数据的表。 因为 InnoDB ，它是一个创建的表 ROW_FORMAT=COMPRESSED 。 有关 更多信息 ， 请参见 第15.9节“InnoDB表和页面压缩” 。

另请参见 压缩行格式 ， 压缩 。

具有广泛优势的功能包括使用更少的磁盘空间，执行更少的I / O以及使用更少的内存进行缓存。

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

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

另请参见 缓冲池 ， 压缩备份 ， 压缩行格式 ， DML ， 透明页面压缩 。

实际上并不是错误，而是在将 压缩 与 DML 操作 结合使用 时可能发生的昂贵 操作。 它出现在：对压缩 页面的 更新 溢出保留用于记录修改的页面上的区域; 页面再次压缩，所有更改都应用于表格数据; 重新压缩的数据不适合原始页面，要求MySQL将数据拆分为两个新页面并分别压缩每个页面。 要检查此条件的频率，请查询该 INFORMATION_SCHEMA.INNODB_CMP 表并检查 COMPRESS_OPS 列的值超过该值的值 COMPRESS_OPS_OK 柱。 理想情况下，压缩失败不会经常发生; 当他们这样做，你可以调整 innodb_compression_level ， innodb_compression_failure_threshold_pct 和 innodb_compression_pad_pct_max 配置选项。

另请参见 compression ， DML ， page 。

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

另请参见 ACID ， 锁定 ， 事务 。

包含 MySQL在启动时使用 的 选项 值 的文件 。 传统上，在Linux和Unix上，这个文件被命名 my.cnf ，在Windows上它被命名 my.ini 。 您可以 [mysqld] 在文件部分 下设置与InnoDB相关的许多选项 。

有关 MySQL搜索配置文件的位置的信息 ， 请参见 第4.2.2.2节“使用选项文件” 。

当您使用 MySQL Enterprise Backup 产品时，通常使用两个配置文件：一个指定数据的来源以及数据的结构（可能是服务器的原始配置文件），以及仅包含数据的精简配置文件。一小组选项，用于指定备份数据的位置以及结构的方式。 与 MySQL Enterprise Backup 产品 一起使用的配置文件 必须包含通常不在常规配置文件中的某些选项，因此您可能需要向现有配置文件添加选项以与 MySQL Enterprise Backup一起使用 。

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

一种读取操作，它使用 快照 信息基于某个时间点显示查询结果，而不管同时运行的其他事务所执行的更改。 如果查询数据已被另一个事务更改，则基于 撤消日志 的内容重建原始数据 。 此技术 通过强制事务等待其他事务完成 来避免一些 可能降低 并发 性的 锁定 问题 。

使用 REPEATABLE READ 隔离级别 ，快照基于执行第一次读取操作的时间。 使用 READ COMMITTED 隔离级别，快照将重置为每次一致读取操作的时间。

一致性读取是 READ COMMITTED 和 REPEATABLE READ 隔离级别中的 InnoDB 进程 SELECT 语句 的缺省模式 。 由于一致读取不会对其访问的表设置任何锁定，因此在对表执行一致读取时，其他会话可以自由修改这些表。

有关适用隔离级别的技术详细信息，请参见 第15.7.2.3节“一致性非锁定读取” 。

另请参见 并发 ， 隔离级别 ， 锁定 ， READ COMMITTED ， REPEATABLE READ ， 快照 ， 事务 ， 撤消日志 。

一种自动测试，可以阻止数据库更改以防止数据变得不一致。 （在计算机科学术语中，一种与不变条件相关的断言。）约束是 ACID 哲学的 一个关键组成部分 ，用于保持数据的一致性。 MySQL支持的约束包括 FOREIGN KEY约束 和 唯一约束 。

另请参见 ACID ， 外键 ， 唯一约束 。

由特定类型的 InnoDB 操作 递增的值 。 用于测量服务器的繁忙程度，对性能问题的来源进行故障排除，以及测试更改（例如，配置设置或查询使用的索引）是否具有所需的低级别效果。 通过 Performance Schema 表和 INFORMATION_SCHEMA 表 可以使用不同类型的计数器 INFORMATION_SCHEMA.INNODB_METRICS 。

另请参阅 INFORMATION_SCHEMA ， 度量计数器 ， 性能架构 。

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

在 给定正确的查询的情况下， 任何 列索引 或 复合索引 都可以充当覆盖索引。 设计索引和查询以尽可能利用此优化技术。

另请参见 列索引 ， 组合索引 ， 索引 ， 主键 ， 辅助索引 。

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

另请参见 瓶颈 ， 缓冲池 ， 工作负载 。

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

另请参阅 崩溃恢复 ， 快速关闭 ， InnoDB ， 关闭 。

崩溃 后再次启动MySQL时发生的清理活动 。 对于 InnoDB 表，使用 重做日志中的 数据重放未完成事务的更改 。 这是变化 致力于 在飞机坠毁前，但尚未写入到 数据文件 ，从重建 双写缓冲 。 当数据库正常关闭时，在 清除 操作 期间执行此类活动 。

在正常操作期间，提交的数据可以在 写入数据文件之前 存储在 更改缓冲区 中一段时间​​。 在保持数据文件是最新的，在正常操作期间引入性能开销以及缓冲数据之间总是存在权衡，这可能使关闭和崩溃恢复需要更长时间。

另请参阅 更改缓冲区 ， 提交 ， 崩溃 ， 数据文件 ， 双写缓冲区 ， InnoDB ， 清除 ， 重做日志 。

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

另请参见 DDL ， DML ， 查询 ， SQL 。

内部数据结构，用于表示 查询 的结果集 或使用SQL WHERE 子句 执行搜索的其他操作 。 它的工作方式类似于其他高级语言中的迭代器，根据请求从结果集中生成每个值。

尽管SQL通常会为您处理游标处理，但在处理性能关键代码时，您可能会深入研究内部工作。

请参阅 查询 。

跟踪数据库对象（如 表 ， 索引 和表 列）的元数据 。 对于MySQL 8.0中引入的MySQL数据字典，元数据实际上位于 数据库目录 中的 InnoDB 每 表文件 表 空间文件中 mysql 。 对于 InnoDB 数据字典，元数据实际位于 InnoDB 系统表空间中 。

由于 MySQL Enterprise Backup 产品始终备份 InnoDB 系统表空间，因此所有备份都包含 InnoDB 数据字典 的内容 。

另请参见 column ， table-per-table ， .frm文件 ， index ， MySQL Enterprise Backup ， 系统表空间 ， 表 。

该目录下的每个MySQL的 情况下 保持 数据文件 的 InnoDB ，并表示各个数据库的目录。 由 datadir 配置选项控制。

另请参见 数据文件 ， 实例 。

物理上包含 表 和 索引 数据 的文件 。

的 InnoDB 系统表 ，它保存 InnoDB 数据字典 和能够保持数据的多个 InnoDB 表，由一个或多个表示的 .ibdata 数据文件。

保存单个 InnoDB 表的 数据的每表文件表空间 由 .ibd 数据文件 表示 。

可以保存多个 InnoDB 表的 数据的通用表空间（在MySQL 5.7.6中引入） 也由 .ibd 数据文件 表示 。

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

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

另请参见 非规范化 ， OLTP ， 查询 ， 只读事务 。

在MySQL 数据目录中 ，每个数据库由一个单独的目录表示。 InnoDB 系统表空间 可以保存MySQL 实例中 多个数据库的表数据 ，它保存在 驻留在各个数据库目录之外的 数据文件 中。 当 文件的每个表的 启用模式时， 的.ibd文件 代表个人InnoDB表存储在数据库目录中，除非使用创建别处 DATA DIRECTORY 条款。 MySQL 5.7.6中引入的常规表空间也在 .ibd文件中 保存表数据 。 与文件每表 .ibd文件不同 ，通用表空间 .ibd文件 可以保存MySQL 实例中 多个数据库的表数据 ，并且可以分配给相对于MySQL数据目录或独立于MySQL数据目录的目录。

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

另请参阅 数据文件 ， 文件的每个表 ， 的.ibd文件 ， 例如 ， 架构 ， 系统表空间 。

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

另请参见 DDL ， DML ， SQL 。

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

DDL语句自动 提交 当前 事务 ; 他们无法 回滚 。

该 InnoDB 在线DDL 功能增强了性能 CREATE INDEX ， DROP INDEX 以及多种类型的 ALTER TABLE 操作。 有关 更多信息 ， 请参见 第15.12节“InnoDB和在线DDL” 。 此外， InnoDB 每表文件 设置可能会影响 DROP TABLE 和 TRUNCATE TABLE 操作 的行为 。

与 DML 和 DCL 对比 。

另请参阅 commit ， DCL ， DML ， 每表文件 ， 回滚 ， SQL ， 事务 。

不同 事务 无法继续的情况，因为每个 事务 都持有 另一个需要 的 锁 。 因为两个事务都在等待资源变得可用，所以它们都不会释放它所拥有的锁。

当事务锁定多个表中的行（通过诸如 UPDATE 或之类的 语句 SELECT ... FOR UPDATE ），但顺序相反 时，可能会发生死锁 。 当这样的语句锁定索引记录和 间隙的 范围时，也会发生死锁 ，每个事务由于时序问题而获取某些锁而不是其他锁。

有关如何自动检测和处理死锁的背景信息，请参见 第15.7.5.2节“死锁检测和回滚” 。 有关避免和从死锁条件中恢复的提示，请参见 第15.7.5.3节“如何最小化和处理死锁” 。

另见 gap ， lock ， transaction 。

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

另请参见 死锁 ， 回滚 ， 事务 ， 受害者 。

当 InnoDB 处理一个 DELETE 声明，该行立即被标记为删除并不再被查询返回的。 在称为 清除 操作 的定期垃圾收集期间，稍后将回收存储 。 为了删除大量数据，具有自己的性能特征的相关操作是 TRUNCATE 和 DROP 。

另请参见 drop ， purge ， truncate 。

将 DELETE 操作 产生的二级索引页 的 更改存储 在 更改缓冲区中 而不是立即写入更改的技术，以便可以执行物理写入以最小化随机I / O. （因为删除操作分为两步，所以此操作会缓冲通常标记为删除索引记录的写入。）它是 更改缓冲 的类型之一 ; 其他是 插入缓冲 和 清除缓冲 。

另请参阅 更改缓冲区 ， 更改缓冲 ， 插入缓冲区 ， 插入缓冲 ， 清除缓冲 。

一种数据存储策略，它跨不同的表复制数据，而不是将表与 外键 和 连接 查询相关联。 通常用于 数据仓库 应用程序，其中数据在加载后不会更新。 在此类应用程序中，查询性能比在更新期间维护一致数据更简单更重要。 与 标准化 对比 。

另请参见 数据仓库 ， 外键 ， 连接 ， 规范化 。

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

另见 索引 。

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

有关更多信息，请参见 第14.4节“字典对象高速缓存” 。

请参见 数据字典 ， LRU 。

一个 页面 的 InnoDB 缓冲池 已在内存中，这里的变化没有写被更新（ 刷新 ）的 数据文件 。 与 干净页面 相反 。

另请参见 缓冲池 ， 清理页面 ， 数据文件 ， 刷新 ， 页面 。

检索不可靠数据的操作，由另一个事务更新但尚未 提交的数据 。 只有 隔离级别 称为 read uncommitted 才有可能 。

这种操作不符合 ACID 数据库设计原则。 它被认为是非常危险的，因为数据可以 在提交之前 回滚 或更新; 然后，执行脏读的事务将使用从未确认为准确的数据。

它的反面是 一致读取 ， InnoDB 确保事务不会读取由另一个事务更新的信息，即使其他事务同时提交也是如此。

另请参见 ACID ， 提交 ， 一致性读取 ， 隔离级别 ， READ UNCOMMITTED ， 回滚 。

一种主要在磁盘存储上组织数据的数据库（硬盘驱动器或等效驱动器）。 数据在磁盘和存储器之间来回传递以进行操作。 它与 内存数据库 相反 。 虽然它 InnoDB 是基于磁盘的，但它还包含诸如 缓冲池 ，多个缓冲池实例和 自适应哈希索引等功能 ，这些功能允许某些类型的工作负载主要从内存中工作。

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

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

另请参见 瓶颈 ， 缓冲池 ， 工作负载 。

数据操纵语言，一组 SQL 执行语句 INSERT ， UPDATE 和 DELETE 操作。 该 SELECT 声明有时被认为是一个DML语句，因为 SELECT ... FOR UPDATE 形式是受到了同样的考虑 锁定 为 INSERT ， UPDATE 和 DELETE 。

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

与 DDL 和 DCL形成 对比 。

另请参阅 commit ， DCL ， DDL ， 锁定 ， 回滚 ， SQL ， 事务 。

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

另请参见 全文搜索 ， FULLTEXT索引 ， ilist 。

InnoDB 使用称为doublewrite的文件刷新技术。 在写之前 的页面 的 数据文件 ， InnoDB 第一次将它们写入称为双写缓冲区中的连续区域。 只有在写入和刷新到doublewrite缓冲区之后，才会 InnoDB 将页面写入数据文件中的正确位置。 如果 在页面写入过程中 存在操作系统，存储子系统或 mysqld 进程崩溃，则 InnoDB 可以在 崩溃恢复 期间从doublewrite缓冲区中找到该页面的良好副本 。

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

要关闭doublewrite缓冲区，请指定该选项 innodb_doublewrite=0 。

另请参阅 崩溃恢复 ， 数据文件 ， 页面 ， 清除 。

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

另请参见 缓冲池 ， 数据字典 ， DDL ， 表 ， truncate 。

一个 InnoDB 行格式。 由于长的可变长度列值存储在保存行数据的页面之外，因此对于包含大对象的行非常有效。 由于通常不访问大字段来评估查询条件，因此它们不会 经常 进入 缓冲池 ，从而导致更少的I / O操作和更好的缓存内存利用率。

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

有关 InnoDB DYNAMIC 行格式的 其他信息 ，请参阅 DYNAMIC行格式 。

另请参见 缓冲池 ， 文件格式 ， 行格式 。

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

另见 beta 。

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

另见 crash ， log 。

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

另请参见 缓冲池 ， 脏页 ， 刷新 ， LRU ， 邻居页面 。

A类 锁 ，以防止任何其他 交易 从锁定同一行。 根据事务 隔离级别 ，这种锁可能会阻止其他事务写入同一行，或者也可能阻止其他事务读取同一行。 默认 InnoDB 隔离级别 REPEATABLE READ 通过允许事务读取具有独占锁的行来 实现更高的 并发性 ，这种技术称为 一致读取 。

另请参见 并发 ， 一致性读取 ， 隔离级别 ， 锁定 ， REPEATABLE READ ， 共享锁定 ， 事务 。

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

InnoDB MySQL 5.7.6中增加了 对32KB和64KB 页面大小的 支持 。 对于32KB的页面大小，范围大小为2MB。 对于64KB的页面大小，范围大小为4MB。

InnoDB 功能，如 段 ， 预读 请求和 双写缓冲器 使用I / O操作读，写，分配，或在一个时间免费数据的一个程度。

另请参见 doublewrite buffer ， page ， page size ， read-ahead ， segment ， tablespace 。

包含MySQL表的元数据（如表定义）的文件。 .frm 在MySQL 8.0中删除了文件，但仍在早期的MySQL版本中使用。 在MySQL 8.0中，先前存储在 .frm 文件中的 数据 存储在 数据字典 表中。

另请参见 数据字典 ， MySQL Enterprise Backup ， 系统表空间 。

InnoDB插件中首次引入的功能，现在是5.5及更高版本的MySQL的一部分，可以 通过避免完全重写相关表 来加速 InnoDB 二级索引 的 创建 。 加速也适用于删除二级索引。

由于索引维护可能会增加许多数据传输操作的性能开销，因此请考虑执行诸如 ALTER TABLE ... ENGINE=INNODB 或 INSERT INTO ... SELECT * FROM ... 不执行任何二级索引的操作，然后再创建索引。

在MySQL 5.6中，此功能变得更加通用。 您可以在创建索引时读取和写入表，并且 ALTER TABLE 可以在不复制表的情况下执行 更多种类的 操作，而不会阻止 DML 操作，或两者兼而有之。 因此，在MySQL 5.6及更高版本中，这组功能称为 在线DDL， 而不是快速索引创建。

有关相关信息，请参阅 InnoDB快速索引创建 和 第15.12节“InnoDB和在线DDL” 。

另请参见 DML ， 索引 ， 在线DDL ， 二级索引 。

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

另请参阅 崩溃恢复 ， 数据文件 ， 刷新 ， 关闭 ， 慢速关闭 。

InnoDB 表格 的文件格式 。

另请参见 file-per-table ， .ibd文件 ， ibdata文件 ， 行格式 。

由 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企业备份 产品是那些在自己的文件表的更灵活。 例如，可以从备份中排除表，但仅限于它们位于单独的文件中。 因此，此设置适用于较少备份或不同计划的表。

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

在一个 InnoDB 索引 ，一个比例 页面 被页面之前采取了由索引数据被分割。 索引数据首先在页面之间划分时未使用的空间允许使用更长的字符串值更新行，而无需昂贵的索引维护操作。 如果填充因子太低，索引会占用比所需更多的空间，从而在读取索引时会产生额外的I / O开销。 如果填充因子太高，任何增加列值长度的更新都可能导致索引维护的额外I / O开销。 有关 更多信息 ， 请参见 第15.6.2.2节“InnoDB索引的物理结构” 。

另见 索引 ， 页面 。

此行格式由 MyISAM 存储引擎使用，而不是由 InnoDB 。 如果 InnoDB 使用 ROW_FORMAT=FIXED MySQL 5.7.6或更早版本中 的选项 创建 表，则 InnoDB 使用 紧凑行格式 ，尽管该 FIXED 值仍可能显示在输出（如 SHOW TABLE STATUS 报表）中。 从MySQL 5.7.7开始， InnoDB 如果 ROW_FORMAT=FIXED 指定 则返回错误 。

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

将更改写入已在内存区域或临时磁盘存储区域中缓冲的数据库文件。 InnoDB 定期刷新 的 存储结构包括 重做日志 ， 撤消日志 和 缓冲池 。

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

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

内部 InnoDB 跟踪数据结构 脏页 在 缓冲池 ：那就是， 网页 已更改，并需要写回到磁盘。 此数据结构经常由 InnoDB 内部 小型事务 更新 ，因此受其自身的 互斥锁 保护， 以允许并发访问缓冲池。

请参阅 缓冲池 ， 脏页 ， LRU ， 迷你事务 ， 互斥 ， 页面 ， 页面清理 。

一种指针关系，位于不同 InnoDB 表中的 行之间 。 外键关系在 父表 和 子表中的 一列上定义 。

除了能够快速查找相关信息外，外键还可以 防止这些指针在插入，更新和删除数据时变为无效，从而 有助于强制 引用完整性 。 此强制机制是一种 约束 。 如果另一个表中不存在关联的外键值，则无法插入指向另一个表的行。 如果删除了一行或更改了其外键值，并且另一个表中的行指向该外键值，则可以设置外键以防止删除，从而导致另一个表中的相应列值变为 null ，或自动删除另一个表中的相应行。

设计 规范化 数据库的 一个阶段 是识别复制的数据，将数据分成新表，并设置外键关系，以便可以使用 连接 操作 像单个表一样查询多个表 。

另请参见 子表 ， FOREIGN KEY约束 ， 连接 ， 规范化 ， NULL ， 父表 ， 参照完整性 ， 关系 。

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

另请参见 子表 ， 约束 ， DML ， 外键 ， NULL 。

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

另请参见 全表扫描 ， 全文搜索 。

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

另请参见 备份 ， 数据库 ， 实例 ， 部分备份 ， 表 。

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

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

另请参见 缓冲池 ， 索引 。

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

另请参见 FULLTEXT索引 。

在MySQL 全文搜索 机制 中保存 搜索索引 的特殊 索引 。 表示列值的单词，省略任何指定为 停用 词的单词 。 最初，仅适用于 桌子。 从MySQL 5.6.4开始，它也可用于 InnoDB 表。 MyISAM

另请参见 全文搜索 ， 索引 ， InnoDB ， 搜索索引 ， 停用词 。

一种 从 缓冲池中 刷新 小批量 脏页的 技术 ，而不是一次刷新所有脏页，这会破坏数据库处理。

另请参见 缓冲池 ， 脏页 ， 刷新 。