MySQL 术语表

这些术语通常用于有关 MySQL 数据库服务器的信息中。该词汇表起源于关于 InnoDB 存储引擎的术语的引用,并且大多数定义是 InnoDB-related。

一个


  • .ARM 文件


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

另见.ARZ 文件MySQL 企业备份mysqlbackup 命令


  • .ARZ 文件


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

另见.ARM 文件MySQL 企业备份mysqlbackup 命令



    • 代表原子性,一致性,隔离性和耐久性的首字母缩略词。这些 properties 在数据库系统中都是可取的,并且都与transaction的概念密切相关。 InnoDB的 transactional features 遵守 ACID 原则。

Transactions 是原子工作单位,可以承诺回滚。当 transaction 对数据库进行多次更改时,要么在提交 transaction 时所有更改都成功,要么在回滚 transaction 时撤消所有更改。

数据库始终保持一致的 state - 在每次提交或回滚之后,并且 transactions 正在进行中。如果跨多个表更新相关数据,查询将查看所有旧值或所有新值,而不是旧值和新值的混合。

Transactions 在进行过程中受到保护(隔离);他们不能互相干扰或看到彼此未提交的数据。这种隔离是通过lock机制实现的。经验丰富的用户可以调整隔离 level,减少保护,支持增加 performance 和并发,当他们可以确定 transactions 真的不会相互干扰。

transactions 的结果是持久的:一旦提交操作成功,该 transaction 所做的更改就可以避免电源故障,系统崩溃,竞争条件或许多 non-database 应用程序易受攻击的其他潜在危险。耐用性通常涉及写入磁盘存储,具有一定的冗余以防止写入操作期间的电源故障或软件崩溃。 (在InnoDB中,双写缓冲区辅助 durability.)

另请参见原子承诺并发双写缓冲区隔离 level锁定回滚交易


  • 自适应冲洗


    • InnoDB表的算法,用于平滑检查点引入的 I/O 开销。而不是将所有已修改的页面缓冲池同时刷新到数据文件**,MySQL 不定期刷新小的修改页面集.自适应刷新算法通过基于刷新率和生成重做信息的速度来估计执行这些周期性刷新的最佳速率来扩展该 process。

另请参见缓冲池检查站data files红晕InnoDB重做 log


  • 自适应哈希索引


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

哈希索引始终基于 table 上的现有B-tree索引构建。 MySQL 可以在为 B-tree 定义的 key 的任意长度的前缀上构建哈希索引,具体取决于对索引的搜索的 pattern。哈希索引可以是部分的;整个 B-tree 索引不需要缓存在缓冲池中。

在 MySQL 5.6 及更高版本中,利用InnoDB表快速 single-value 查找的另一种方法是使用InnoDB memcached插件。有关详细信息,请参阅第 14.20 节,“InnoDB memcached 插件”

另请参见B-tree缓冲池哈希索引memcached二级指数


  • AIO


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

另见异步 I/O


  • 羚羊

    • 原始InnoDB 文件格式的 code name。它支持REDUNDANTCOMPACT行格式,但不支持Barracuda文件格式中较新的DYNAMICCOMPRESSED行格式。

另请参见梭子鱼紧凑的行格式压缩行格式动态行格式文件格式innodb_file_format冗余行格式


  • application 编程接口(API)


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

  • 应用


    • MySQL Enterprise Backup产品生成的备份不包括备份正在进行时发生的最新更改时,更新备份 files 以包含这些更改的 process 称为apply step 。它由mysqlbackup命令的apply-log选项指定。

在应用更改之前,我们将 files 称为原始备份。应用更改后,我们将 files 称为准备备份。更改记录在ibbackuplogfile文件中;一旦 apply step 完成,就不再需要这个文件了。

另请参见热备份ibbackuplogfileMySQL 企业备份准备备份原始备份


  • 异步 I/O


    • 一种 I/O 操作,允许在 I/O 完成之前继续进行其他处理。也称为nonblocking I/O,缩写为AIOInnoDB使用这种类型的 I/O 进行某些操作,这些操作可以在 parallel 中运行而不会影响数据库的可靠性,例如将页面读入缓冲池但实际上并未被请求,但很快就可能需要。

从历史上看,InnoDB仅在 Windows 系统上使用异步 I/O。从 InnoDB Plugin 1.1 和 MySQL 5.5 开始,InnoDB在 Linux 系统上使用异步 I/O。此更改引入了对libaio的依赖性。 Linux 系统上的异步 I/O 是使用innodb_use_native_aio选项配置的,默认情况下启用该选项。在其他 Unix-like 系统上,InnoDB 仅使用同步 I/O。

另见缓冲池无阻塞 I/O


  • 原子


    • 在 SQL context 中,transactions是完全成功的工作单元(当已提交时)或根本没有效果(当回滚时)。 transactions 的不可分割(“原子”)属性是首字母缩写词ACID中的“A”。

另请参见承诺回滚交易


  • 原子 DDL


    • 原子 DDL 语句将数据字典更新,存储引擎操作和与 DDL 操作关联的二进制 log 写入组合到单个原子 transaction 中。即使服务器在操作期间停止,transaction 也会完全提交或回滚。 MySQL 8.0 中添加了原子 DDL 支持。有关更多信息,请参阅原子数据定义声明支持

另请参见二进制 log数据字典DDL存储引擎


  • 原子指令


    • CPU 提供的特殊指令,确保关键的 low-level 操作不会被中断。

  • auto-increment


    • table 列的 property(由AUTO_INCREMENT关键字指定),它会自动在列中添加一系列升序值。

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

Auto-increment 列在 statement-based 复制时可能会出现问题,因为由于时序问题,重播从站上的 statements 可能不会产生与 master 上相同的列值集。如果有 auto-incrementing 主 key,则只能使用 statement-based 复制设置innodb_autoinc_lock_mode=1。如果你有innodb_autoinc_lock_mode=2,它允许 insert 操作具有更高的并发性,那么使用row-based replication而不是statement-based replication。除兼容性目的外,不应使用innodb_autoinc_lock_mode=0设置。

连续锁定模式(innodb_autoinc_lock_mode=1)是 MySQL 8.0.3 之前的默认设置。从 MySQL 8.0.3 开始,交错锁定模式(innodb_autoinc_lock_mode=2)是默认值,它反映了从 statement-based 到 row-based 复制的更改作为默认复制类型。

另请参见auto-increment 锁定innodb_autoinc_lock_mode首要的关键row-based 复制statement-based 复制


  • auto-increment 锁定

    • auto-increment primary key 的便利性涉及一些与并发的权衡。在最简单的情况下,如果一个 transaction 将值插入 table,则任何其他 transactions 必须等待自己插入到 table 中,以便第一个 transaction 插入的行接收连续的主 key 值。 InnoDB包括优化和innodb_autoinc_lock_mode选项,以便您可以为 insert 操作配置 auto-increment 值的可预测 sequences 和最大并发之间的最佳平衡。

另见auto-increment并发innodb_autoinc_lock_mode


  • 自动提交


    • 在每个SQL语句之后导致commit操作的设置。建议不要使用此模式来处理带有transactionsInnoDB表_s 几个 statements。它可以帮助InnoDB表上read-only transactions的 performance,它可以最大限度地减少锁定undo数据的开销,特别是在 MySQL 5.6.4 及更高版本中。它也适用于MyISAM 数据表,其中 transactions 不适用。

另请参见承诺锁定read-only transactionSQL交易解开


  • 可用性


    • 能够处理 host 上的故障,并在必要时从中恢复故障,包括 MySQL,操作系统或可能导致停机的硬件和维护活动的故障。通常与可伸缩性配对,作为 large-scale 部署的关键方面。

另见可扩展性


  • B-tree


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

因为 B-tree 节点可以有许多 children,所以 B-tree 与二叉树不同,二进制树每个节点限制为 2 个 children。

哈希索引对比,后者仅在记忆存储引擎中可用。 MEMORY存储引擎也可以使用 B-tree 索引,如果某些查询使用范围 operators,则应为MEMORY表选择 B-tree 索引。

术语 B-tree 的使用旨在作为索引设计的一般 class 的参考。由于经典 B-tree 设计中不存在的复杂性,MySQL 存储引擎使用的 B-tree 结构可能被视为变体。有关相关信息,请参阅MySQL 内部手册InnoDB页面结构Fil Header部分。

另见哈希索引


  • 反引号


    • MySQL SQL statements 中的标识符必须使用反引号字符(“+268++269+`的列,您应将标识符指定为FOO#BARSELECT。由于反引号提供了额外的级安全性,因此它们在 program-generated SQL 语句中被广泛使用,其中标识符名称可能事先不知道。

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

另见SQL


  • 备用


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

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

备份进一步分为,具体取决于它们对正常数据库操作的干扰程度。 (热备份干扰最小,冷备份 most.)

另请参见冷备份热备份逻辑备份MySQL 企业备份mysqldump物理备份热备份


  • 梭子鱼


    • code name 为InnoDB 文件格式,支持COMPRESSED行格式,支持 InnoDB table 压缩,DYNAMIC行格式,可改善 long variable-length 列的存储布局。

MySQL Enterprise Backup产品 version 3.5 及更高版本支持备份使用 Barracuda 文件格式的表空间。

另请参见羚羊紧凑的行格式压缩行格式动态行格式文件格式file-per-table一般表空间innodb_file_formatMySQL 企业备份行格式系统表空间


  • 基本栏目

    • non-generated table 列,存储的生成列或虚拟生成列基于该列。换句话说,基本列是 non-generated table 列,它是生成的列定义的一部分。

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


  • 公测


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

另见早期采用者GA


  • 二进制 log


    • 包含所有 statements 的 record 的文件,它尝试更改 table 数据。可以重播这些语句,以便在复制方案中将从属服务器升级到 date,或者在从备份恢复 table 数据后将数据库升级到 date。二进制 logging feature 可以打开和关闭,但 Oracle 建议在使用复制或执行备份时始终启用它。

您可以使用mysqlbinlog 可以命令检查二进制 log 的内容,或在复制或恢复期间重播这些 statements。有关二进制 log 的完整信息,请参阅第 5.4.4 节,“二进制 Log”。有关与二进制 log 相关的 MySQL configuration 选项,请参阅Section 16.1.6.4,“Binary Logging Options and Variables”

对于MySQL Enterprise Backup产品,二进制 log 的文件 name 和文件中的当前位置是重要的细节。要在复制 context 中进行备份时记录 master 服务器的此信息,您可以指定--slave-info选项。

在 MySQL 5.0 之前,可以使用类似的功能,称为 update log。在 MySQL 5.0 及更高版本中,binary log 替换了 update log。

另见二进制日志MySQL 企业备份复制


  • 二进制日志


    • binary log文件的非正式 name。例如,您可能会在 e-mail 消息或论坛讨论中看到此缩写。

另见二进制 log


  • 盲目查询扩展


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

另见full-text 搜索


  • 瓶颈


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

另见缓冲池并发


  • 弹跳


    • 一个关闭操作,然后立即重启。理想情况下,**预热时间相对较短,因此性能和吞吐量很快就会回升到高水平。

另见关掉


  • 伙伴分配器


    • 在 InnoDB 缓冲池中管理 different-sized的机制

另见缓冲池页面大小


  • 缓冲


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

另请参见缓冲池改变缓冲区紧急双写缓冲区


  • 缓冲池


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

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

另请参见缓冲池实例LRU暖身


  • 缓冲池实例


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

另见缓冲池


  • built-in


    • MySQL 中的 built-in InnoDB存储引擎是存储引擎的原始分发形式。与InnoDB 插件对比。从 MySQL 5.5 开始,InnoDB 插件作为 built-in InnoDB存储引擎(称为 InnoDB 1.1)合并回 MySQL code 基础。

这种区别主要在 MySQL 5.1 中很重要,其中 feature 或 bug 修复可能适用于 InnoDB 插件但不适用于 built-in InnoDB,反之亦然。

另见InnoDB


  • 商业规则


    • 构成商业软件基础的行为的关系和序列,用于运营商业公司。有时这些规则是由法律规定的,有时则由公司政策决定。仔细规划可确保数据库编码和实施的关系以及通过 application 逻辑执行的操作能够准确反映公司的真实政策并能够处理 real-life 情况。

例如,离开公司的员工可能会触发人力资源部门的一系列操作。人力资源数据库可能还需要灵活地表示有关已被雇用但尚未开始工作的人的数据。关闭在线服务的帐户可能会导致数据从数据库中删除,或者数据可能会被移动或标记,以便在帐户为 re-opened 时可以恢复。除了基本的健全性检查(例如工资不是负数)之外,公司可能会建立关于工资最高额,最低工资和调整的政策。零售数据库可能不允许多次返回具有相同序列号的购买,或者可能不允许购买超过特定值的信用卡,而用于检测欺诈的数据库可能允许这些类型的事物。

另见相关

C


  • .cfg 文件


    • InnoDB 可传输表空间feature 一起使用的元数据文件。它由命令FLUSH TABLES ... FOR EXPORT生成,将一个或多个表放在一致的 state 中,可以将其复制到另一个服务器。 .cfg文件与相应的** .ibd 文件一起被复制,并用于在ALTER TABLE ... IMPORT TABLESPACE step 期间调整.ibd文件的内部值,例如空格 ID**。

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


  • 高速缓存


    • 任何 memory 区域的通用术语,用于存储频繁或 high-speed 检索的数据副本。在InnoDB中,主要的缓存结构类型是缓冲池

另见缓冲缓冲池


  • 基数


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

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

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

另请参见综合指数指数索引提示持久统计随机潜水选择性独特的约束


  • 改变缓冲区


    • 一种特殊的数据结构,记录二级索引的变化。这些值可能来自 SQL 插入UPDATE删除 statements(DML)。涉及更改缓冲区的 features 集合统称为change buffering,包括insert bufferingdelete bufferingpurge buffering

当二级索引中的相关页面不在缓冲池中时,更改仅记录在更改缓冲区中。当相关索引页面进入缓冲池而相关更改仍在更改缓冲区中时,该页面的更改将使用更改缓冲区中的数据应用于缓冲池(merged)。在系统主要处于 idle 期间或在慢速关闭期间运行的purge操作会定期将新索引页写入磁盘。与每个 value 立即写入磁盘的情况相比,清除操作可以更有效地写入一系列索引值的磁盘块。

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

存储在更改缓冲区中的数据种类和数量由innodb_change_bufferinginnodb_change_buffer_max_size configuration 选项控制。要查看有关更改缓冲区中当前数据的信息,请发出显示发动机创新状态命令。

以前称为插入缓冲区

另请参见缓冲池改变缓冲删除缓冲DMLinsert 缓冲区insert 缓冲合并清除清除缓冲二级指数系统表空间


  • 改变缓冲


    • 涉及更改缓冲区的 features 的一般术语,包括插入缓冲删除缓冲清除缓冲。由 SQL statements 引起的索引更改(通常可能涉及随机 I/O 操作)将被后台线程保留并定期执行。与每个 value 立即写入磁盘的情况相比,这一系列操作可以更有效地为一系列索引值写入磁盘块。由innodb_change_bufferinginnodb_change_buffer_max_size configuration 选项控制。

另请参见改变缓冲区删除缓冲insert 缓冲清除缓冲


  • 检查站


    • 当对缓冲池中缓存的数据页进行更改时,这些更改将在稍后的某个时间写入data files**,这称为刷新.检查点是已成功写入数据 files 的最新更改(由LSN value 表示)的记录。

另请参见缓冲池data files红晕模糊检查点LSN


  • 校验


    • InnoDB中,一种验证机制,用于在表空间中的页面从磁盘读入InnoDB缓冲池时检测到损坏。此 feature 由 MySQL 5.5 中的innodb_checksums configuration 选项控制。 innodb_checksums在 MySQL 5.6.3 中已弃用,取而代之的是innodb_checksum_algorithm

innochecksum命令通过在 MySQL 服务器关闭时测试指定的表空间文件的校验和值来帮助诊断损坏问题。

MySQL 还使用校验和进行复制。有关详细信息,请参阅 configuration 选项binlog_checksummaster_verify_checksumslave_sql_verify_checksum

另见缓冲池表空间


  • child table


    • foreign key关系中,child table 是一个行,它引用(或指向)另一个 table 中的行,并为特定列提供相同的 value。这是包含FOREIGN KEY ... REFERENCES子句和可选ON UPDATEON DELETE子句的 table。 parent table中的相应行必须存在才能在 child table 中创建行。 child table 中的值可以阻止 parent table 上的删除或更新操作,或者可以根据_创建外部 key 时使用的ON CASCADE选项在 child table 中导致自动删除或更新。

另见外国 keyparent table


  • 干净的页面


    • InnoDB 缓冲池中的,其中 memory 中所做的所有更改也已写入(刷新)到data files.脏页的反面。

另请参见缓冲池data files脏页红晕


  • 干净关机


    • 一个关闭完成没有错误,并在完成之前对InnoDB表应用所有更改,而不是崩溃快速关闭.**slow shutdown **的同义词。

另请参见紧急快速关机关掉慢关机


  • 客户

    • 一种程序,它将请求发送到服务器,并解释或处理结果。 client 软件可能只运行某些 time(例如邮件或聊天程序),并且可能以交互方式运行(例如MySQL命令处理器)。

另见MySQL服务器


  • 聚集索引


    • 主 key索引的InnoDB术语。 InnoDB table 存储基于主 key 列的值进行组织,以加快涉及主 key 列的查询和排序。为获得最佳性能,请根据最 performance-critical 查询仔细选择主 key 列。因为修改聚簇索引的列是一项昂贵的操作,所以选择很少或从不更新的主列。

在 Oracle 数据库产品中,这种类型的 table 称为index-organized table

另见指数首要的关键二级指数


  • 冷备份


    • 在数据库关闭时进行备份。对于繁忙的应用程序和网站,这可能不实用,您可能更喜欢热备份热备份

另见备用热备份热备份



    • 中的数据 item,其存储和语义由数据类型定义。每个tableindex主要由它包含的列集定义。

每列都有基数value。列可以是其 table 的** primary key**,也可以是 primary key 的一部分。列可以受唯一约束NOT NULL 约束或两者的约束。不同列中的值,即使是跨不同的表,也可以通过foreign key关系链接。

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

另请参见基数外国 key指数NOT NULL 约束首要的关键独特的约束


  • 列索引


    • 单列上的索引

另见综合指数指数


  • 列前缀


    • 当使用长度规范(例如CREATE INDEX idx ON t1 (c1(N)))创建索引时,只有列 value 的前 N 个字符存储在索引中。保持索引前缀小使索引紧凑,memory 和 disk I/O savings 帮助 performance。 (虽然使索引前缀太小会阻碍查询优化,方法是使查询优化器的行显示为 duplicates.)

对于包含二进制值或 long text strings 的列,其中排序不是主要考虑因素并且将整个 value 存储在索引中会浪费空间,索引会自动使用 value 的前 N 个(通常为 768 个)字符进行查找和排序。

另见指数


  • 承诺


    • 一个**_** 语句结束事务**,永久地进行 transaction 所做的任何更改.它与rollback相反,它撤消了 transaction 中所做的任何更改。

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

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

另请参见自动提交乐观回滚SQL交易


  • 紧凑的行格式


    • 从 MySQL 5.0.3 到 MySQL 5.7.8 的 InnoDB 表的默认InnoDB 行格式。从 MySQL 5.7.9 开始,默认行格式由innodb_default_row_format configuration 选项定义,其默认设置为DYNAMICCOMPACT行格式为空值和 variable-length 列提供了比先前默认(REDUNDANT行格式)更紧凑的表示。

有关InnoDB COMPACT行格式的其他信息,请参阅第 14.11 节,“InnoDB 行格式”

另请参见羚羊动态行格式文件格式冗余行格式行格式


  • 综合指数


    • 包含多列的索引

另见指数


  • 压缩备份


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

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

在 backup process 开始时应用compression有助于避免压缩 process 期间的存储开销,并避免在将备份 files 传输到另一台服务器时的网络开销。 **应用****二进制 log **的 process 需要更长时间,并且需要解压缩备份 files。

另请参见应用二进制 log压缩热备份MySQL 企业备份表空间


  • 压缩行格式


    • 行格式,为InnoDB表启用数据和索引压缩。它是在InnoDB插件中引入的,作为Barracuda文件格式的一部分提供。大字段存储在远离保存行数据的 rest 的页面中,如动态行格式。索引页面和大字段都被压缩,从而节省了 memory 和磁盘。根据数据的结构,memory 和磁盘使用量的减少可能会或可能不会超过在使用时解压缩数据的性能开销。有关使用详情,请参阅第 14.9 节,“InnoDB Table 和 Page Compression”

有关InnoDB COMPRESSED行格式的其他信息,请参阅动态行格式

另请参见梭子鱼压缩动态行格式行格式

另见压缩行格式压缩


  • 压缩


    • 具有 wide-ranging 的 feature 受益于使用较少的磁盘空间,执行较少的 I/O,以及使用较少的 memory 进行缓存。

    InnoDB支持 table-level 和 page-level 压缩。 InnoDB页面压缩也称为透明页面压缩。有关InnoDB压缩的更多信息,请参阅第 14.9 节,“InnoDB Table 和 Page Compression”

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

另请参见梭子鱼缓冲池压缩备份压缩行格式DML透明页面压缩


  • 压缩失败


    • 实际上并不是错误,而是在使用压缩DML操作时可能发生的昂贵操作。它发生在:对压缩的页面的更新溢出为__cording 修改保留的页面上的区域;页面再次压缩,所有更改都应用于 table 数据; re-compressed 数据不适合原始页面,要求 MySQL 将数据拆分为两个新页面并分别压缩每个页面。要检查此条件的频率,请查询INFORMATIONSCHEMA.INNODB_CMP table 并检查COMPRESS_OPS列的 value 超出COMPRESS_OPS_OK列的 value 的程度。理想情况下,压缩失败不会经常发生;当他们这样做时,您可以调整innodb_compressionlevelinnodb_compression_failure_threshold_pctinnodb_compression_pad_pct_max configuration 选项。

另见压缩DML


  • 连锁索引


  • 并发


    • 多个操作(在数据库术语中,事务)同时运行的能力,而不会相互干扰。并发性也与 performance 有关,因为理想情况下,对多个同时 transactions 的保护使用最小的 performance 开销,使用锁定的有效机制。

另见锁定交易


  • configuration 文件


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

有关 MySQL 搜索 configuration files 的位置的信息,请参阅第 4.2.2.2 节,“使用选项文件”

当您使用MySQL Enterprise Backup产品时,通常使用两个 configuration files:一个指定数据来自何处以及如何构造(可能是服务器的原始 configuration 文件),以及 stripped-down 一个仅包含一小组选项,用于指定备份数据的位置及其结构。与MySQL Enterprise Backup产品一起使用的 configuration files 必须包含通常不在常规 configuration files 中的某些选项,因此您可能需要在现有的 configuration 文件中添加选项以用于MySQL Enterprise Backup

另请参见my.cnfMySQL 企业备份选项选项文件


  • 一致阅读


    • 一种读取操作,使用snapshot信息基于 time 中的某个点显示查询结果,而不管其他 transactions 在同一 time 运行时所执行的更改。如果查询的数据已被另一个 transaction 更改,则原始数据将根据undo log的内容进行重建。这种技术通过强制 transactions 等待其他 transactions 完成来避免一些锁定问题,这些问题可以减少并发性

使用REPEATABLE READ isolation level,快照基于执行第一次读取操作时的 time。使用READ COMMITTED isolation level,快照将重置为每个一致读取操作的 time。

一致性读取是默认模式,其中InnoDB处理READ COMMITTEDREPEATABLE READ隔离级别中的SELECT statements。由于一致读取不会对其访问的表设置任何锁定,因此在对 table 执行一致读取时,其他会话可以自由修改这些表。

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

另请参见并发隔离 level锁定阅读提交可重复阅读快照交易撤消 log


  • 约束


    • 一种自动测试,可以阻止数据库更改以防止数据变得不一致。 (在计算机科学术语中,一种与不变的 condition.)约束相关的断言是ACID哲学的关键组成部分,以保持数据的一致性.MySQL 支持的约束包括FOREIGN KEY 约束唯一约束

另见外国 key独特的约束


  • 计数器


    • 由特定类型的InnoDB操作递增的 value。用于测量服务器的繁忙程度,对 performance 问题的来源进行故障排除,以及测试更改(例如,对于 configuration 设置或查询使用的索引)是否具有所需的 low-level 效果。通过Performance Schema表和INFORMATIONSCHEMA表可以获得不同类型的计数器,尤其是INFORMATION_SCHEMA.INNODB_METRICS

另见INFORMATIONSCHEMAmetrics counterPerformance Schema


  • 覆盖指数


    • 索引,包括查询检索的所有列。查询不是使用索引值作为指针来查找完整的 table 行,而是从索引结构返回值,从而节省磁盘 I/O。 InnoDB可以将此优化技术应用于比 MyISAM 更多的索引,因为InnoDB二级索引还包括primary key列。 InnoDB无法将此技术应用于针对 transaction 修改的表的查询,直到 transaction ends 为止。

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

另请参见列索引综合指数指数首要的关键二级指数


  • CPU-bound


    • 一种工作负载,其中主要的瓶颈是 memory 中的 CPU 操作。通常涉及 read-intensive 操作,其中结果都可以缓存在缓冲池中。

另见瓶颈缓冲池工作量


  • 紧急


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

另请参见崩溃恢复快速关机InnoDB关掉


  • 崩溃恢复


    • 崩溃后再次启动 MySQL 时发生的清理活动。对于InnoDB表,使用来自redo log的数据重放来自不完整 transactions 的更改。在崩溃之前承诺但尚未写入数据 files的更改将从doublewrite buffer重建。当数据库正常关闭时,这种类型的活动在关闭期间通过purge操作执行。

在正常操作期间,提交的数据可以在写入数据 files 之前存储在更改缓冲区中一段时间。在保持数据 files up-to-date(在正常操作期间引入 performance 开销)和缓冲数据(这可能使关闭和崩溃恢复需要更长时间)之间总是需要权衡。

另请参见改变缓冲区承诺紧急data files双写缓冲区InnoDB清除重做 log


  • CRUD


    • “创建,读取,更新,删除”的缩写,是数据库应用程序中的 common 操作序列。通常表示 class 的 applications 具有相对简单的数据库用法(基本DDLDML查询statements in** SQL **),可以用任何语言快速实现。

另请参见DDLDML询问SQL


  • 光标

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

虽然 SQL 通常会为您处理游标,但在处理 performance-critical code 时您可能会深入研究内部工作。

另见询问

d


  • 数据定义语言


  • 数据字典


    • 跟踪 InnoDB-related objects 的元数据,例如索引和 table。此元数据实际位于InnoDB系统表空间中。由于历史原因,它在某种程度上与存储在**.frm files**中的信息重叠。

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

另请参见file-per-table.frm 文件指数MySQL 企业备份系统表空间


  • 数据目录


    • 每个 MySQL 实例保存InnoDB数据 files和代表各个数据库的目录的目录。由DATADIR configuration 选项控制。

另见data files


  • data files


    • 物理上包含tableindex数据的 files。

InnoDB 系统表空间包含InnoDB数据字典并且能够保存多个InnoDB表的数据,由一个或多个.ibdata数据文件表示。

File-per-table 表空间(包含单个InnoDB table 的数据)由.ibd数据文件表示。

一般表空间(在 MySQL 5.7.6 中引入)可以保存多个InnoDB表的数据,也由.ibd数据文件表示。

另请参见数据字典file-per-table一般表空间.ibd 文件ibdata 文件指数系统表空间表空间


  • 数据操纵语言


  • 数据仓库


    • 主要运行大型查询的数据库系统或应用程序。可以以非规范化形式组织 read-only 或 read-mostly 数据以提高查询效率。可以从 MySQL 5.6 及更高版本中的read-only transactions的优化中受益。与OLTP对比。

另请参见非规范化OLTP询问read-only transaction


  • 数据库


    • 在 MySQL 数据目录中,每个数据库由一个单独的目录表示。 InnoDB系统表空间,可以从 MySQL实例中的多个数据库中保存 table 数据,保存在位于各个数据库目录之外的data files中。当启用file-per-table模式时,表示单个 InnoDB 表的**.ibd files存储在数据库目录中,除非使用DATA DIRECTORY子句在其他地方创建。 MySQL 5.7.6 中引入的常规表空间也在.ibd files中保存 table 数据。与 file-per-table .ibd files不同,通用表空间.ibd files**可以从 MySQL 实例中的多个数据库中保存 table 数据,并且可以分配给相对于 MySQL 数据目录或独立于 MySQL 数据目录的目录。

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

另请参见data filesfile-per-table.ibd 文件schema系统表空间


  • DCL


    • 数据控制语言,一组用于管理权限的SQL statements。在 MySQL 中,由GRANT撤消 statements 组成。与DDLDML对比。

另见DDLDMLSQL


  • DDL


    • 数据定义语言,一组SQL statements,用于操作数据库本身而不是单独的 table 行。包括所有形式的CREATEALTERDROP 语句。还包括TRUNCATE语句,因为它的工作方式与DELETE FROM table_name语句不同,即使最终效果相似。

DDL statements 自动提交当前事务;他们不能回滚

InnoDB 在线 DDL feature 增强了创建指数DROP INDEX和许多类型的ALTER TABLE操作的 performance。有关更多信息,请参见第 14.13 节,“InnoDB 和在线 DDL”。此外,InnoDB file-per-table设置可能会影响DROP TABLETRUNCATE TABLE操作的行为。

DMLDCL对比。

另请参见承诺DCLDMLfile-per-table回滚SQL交易


  • 僵局


    • 不同的交易无法进行的情况,因为每个交易都持有另一个需要的。因为两个 transactions 都在等待资源可用,所以它们都不会释放它所拥有的锁。

当 transactions 锁定多个表中的行(通过 statements,如UPDATESELECT ... FOR UPDATE),但是在相反的 order 中时,可能会发生死锁。当这样的语句锁定索引记录的范围和间隙时,也会发生死锁,每个 transaction 都会获取一些锁,但由于计时问题而不会获取其他锁。

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

另见间隙交易


  • 死锁检测


    • 一种机制,可以自动检测死锁何时发生,并自动回滚所涉及的交易之一(受害者)。可以使用innodb_deadlock_detect configuration 选项禁用死锁检测。

另请参见僵局回滚交易受害者


  • 删除


    • InnoDB处理DELETE语句时,行会立即标记为删除,查询不再返回。在称为purge操作的定期垃圾收集期间,存储将在稍后的某个时间回收。为了删除大量数据,具有自己的 performance 特性的相关操作是TRUNCATEDROP

另见下降清除截短


  • 删除缓冲


    • 更改缓冲区中存储由DELETE操作产生的二级索引页面的更改而不是立即写入更改的技术,以便可以执行物理写入以最小化随机 I/O。 (因为删除操作是 two-step process,此操作缓冲通常标记为 deletion.)的索引 record 的写入。它是更改缓冲的类型之一;其他是插入缓冲清除缓冲

另请参见改变缓冲区改变缓冲insert 缓冲区insert 缓冲清除缓冲


  • 非规范化


    • 一种数据存储策略,它跨不同的表复制数据,而不是使用外键连接查询链接表。通常用于数据仓库applications,其中数据在 loading 之后不会更新。在这样的应用程序中,查询 performance 比在更新期间维护一致数据更简单更重要。与标准化对比。

另请参见数据仓库外国 key加入标准化


  • 下降指数


    • 一种索引,可用于某些数据库系统,其中索引存储优化为 process ORDER BY column DESC子句。目前,虽然 MySQL 允许创建 TABLE语句中的DESC关键字,但它不会对结果索引使用任何特殊的存储布局。

另见指数


  • 脏页


    • me 缓冲池中的页面已在 memory 中更新,其中更改尚未写入(刷新)到data files**.干净页面的反面。

另请参见缓冲池干净的页面data files红晕


  • 脏读


    • 检索不可靠数据的操作,由另一个 transaction 更新但尚未提交的数据。只有隔离 level才能被称为read uncommitted

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

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

另请参见承诺一致阅读隔离 level阅读不满意回滚


  • disk-based


    • 一种主要在磁盘存储上组织数据的数据库(硬盘驱动器或等效驱动器)。数据在磁盘和 memory 之间来回传递以进行操作。它与in-memory 数据库相反。虽然InnoDB是 disk-based,但它还包含 features,例如他的缓冲池**,多个缓冲池实例和自适应哈希索引,它们允许某些类型的工作负载主要来自 memory。

另见自适应哈希索引缓冲池in-memory 数据库


  • disk-bound


    • 一种工作负载,其中主要瓶颈是磁盘 I/O。 (也称为I/O-bound .)通常涉及频繁写入磁盘,或随机读取的数据超出缓冲池

另见瓶颈缓冲池工作量


  • DML

    • 数据操作语言,一组用于执行插入UPDATE删除操作的SQL statements。 选择语句有时被视为 DML 语句,因为SELECT ... FOR UPDATE表单与锁定的注意事项相同插入UPDATE删除

InnoDB table 的 DML statements 在transaction的 context 中运行,因此它们的效果可以****回滚**作为一个单元。

DDLDCL对比。

另请参见承诺DCLDDL锁定回滚SQL交易


  • 文件 ID


    • InnoDB full-text search feature 中,table 中包含FULLTEXT 索引的特殊列,用于唯一标识与每个ilist value 关联的文档。它的 name 是FTS_DOC_ID(需要大写)。列本身必须是BIGINT UNSIGNED NOT NULL类型,具有名为FTS_DOC_ID_INDEX的唯一索引。最好在创建 table 时定义此列。如果必须在_创建FULLTEXT索引时将列添加到 table,则索引操作要贵得多。

另见full-text 搜索FULLTEXT 指数i 列表


  • 双写缓冲区


    • InnoDB使用名为 doublewrite 的文件刷新技术。在将写入data files之前,InnoDB首先将它们写入称为 doublewrite buffer 的连续区域。只有在写入和刷新到 doublewrite 缓冲区完成后,InnoDB才会将页面写入数据文件中的正确位置。如果在页面写入过程中存在操作系统,存储子系统或mysqld process 崩溃,InnoDB以后可以在崩溃恢复期间从 doublewrite 缓冲区中找到页面的良好副本

虽然数据总是写入两次,但是 doublewrite 缓冲区不需要两倍的 I/O 开销或两倍的 I/O 操作。数据作为一个大的顺序块写入缓冲区本身,只需对操作系统进行一次fsync()调用。

要关闭 doublewrite 缓冲区,请指定选项innodbdoublewrite=0

另请参见崩溃恢复data files清除


  • 下降


    • 一种DDL操作,通过DROP TABLEDROP INDEX等语句删除 schema object。它 maps 内部到ALTER TABLE语句。从InnoDB的角度来看,此类操作的 performance 考虑因素涉及数据字典被锁定以确保相互关联的 objects 全部更新的 time,以及更新 memory 结构的 time,例如缓冲池。对于table,drop 操作与truncate操作(TRUNCATE TABLE语句)有一些不同的特性。

另请参见缓冲池数据字典DDL截短


  • 动态行格式


    • InnoDB插件中引入的行格式,作为Barracuda 文件格式的一部分提供。由于 long variable-length 列值存储在保存行数据的页面之外,因此对于包含大型 objects 的行非常有效。由于通常不会访问大字段来评估查询条件,因此它们不会经常进入缓冲池,从而导致更少的 I/O 操作和更好地利用缓存 memory。

从 MySQL 5.7.9 开始,默认行格式由innodb_default_row_format定义,其默认 value 为DYNAMIC

有关InnoDB DYNAMIC行格式的其他信息,请参阅动态行格式

另请参见梭子鱼缓冲池文件格式行格式

Ë


  • 早期采用者


    • 类似于beta的阶段,当通常在 non-mission-critical 设置中评估软件产品的性能,功能和兼容性时。

另见公测


  • 错误 log

另见紧急log


  • 赶出


    • 从缓存或其他临时存储区域(例如InnoDB 缓冲池)中删除 item 的 process。通常,但并非总是如此,使用LRU算法来确定要删除的 item。当一个脏页被驱逐时,其内容被刷新到磁盘,任何脏邻居页面**也可能被刷新。

另请参见缓冲池脏页红晕LRU邻居页面


  • 独家锁


    • 一种,可防止任何其他事务锁定同一行。根据 transactionisolation level ,这种锁可能阻止其他 transactions 写入同一行,或者也可能阻止其他 transactions 读取同一行。默认的InnoDB isolation level,REPEATABLE READ通过允许 transactions 读取具有独占锁的行来实现更高的并发性,这种技术称为一致读取

另请参见并发一致阅读隔离 level可重复阅读共享锁交易


  • 程度


    • 表空间中的组。对于 16KB 的默认页面大小,扩展区包含 64 页。在 MySQL 5.6 中,InnoDB实例的页面大小可以是 4KB,8KB 或 16KB,由innodb_page_size configuration 选项控制。对于 4KB,8KB 和 16KB 页面大小,扩展区大小始终为 1MB(或 1048576 字节)。

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

InnoDB features,例如read-ahead请求和doublewrite 缓冲区使用 I/O 操作,在 time 时读取,写入,分配或释放一个范围的数据。

另请参见双写缓冲区页面大小read-ahead分割表空间

F


  • .frm 文件


    • 包含 MySQL table 的元数据(如 table 定义)的文件。

对于备份,必须始终保留完整的.frm files 和备份数据,以便能够还原备份后更改或删除的表。

虽然每个InnoDB table 都有一个.frm文件,但InnoDB系统表空间中维护自己的 table 元数据。 InnoDB不需要.frm files 来操作InnoDB表。

.frm files 由MySQL Enterprise Backup产品备份。在进行备份时,不能通过ALTER TABLE操作修改这些 files,这就是为什么包含非InnoDB表的备份执行带读锁的冲洗表操作以在备份.frm files 时冻结此类活动的原因。还原备份可能会导致.frm files 被创建,更改或删除,以便在备份的 time 时匹配数据库的 state。

另见数据字典MySQL 企业备份系统表空间


  • 快速创建索引


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

因为索引维护可以为许多数据传输操作添加 performance 开销,所以考虑执行诸如ALTER TABLE ... ENGINE=INNODBINSERT INTO ... SELECT * FROM ...之类的操作,而不使用任何二级索引,并且之后创建索引。

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

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

另请参见DML指数在线 DDL二级指数


  • 快速关机


    • InnoDB的默认shutdown过程,基于 configuration 设置innodb_fast_shutdown=1。要保存 time,将跳过某些flush操作。这种类型的关闭在正常使用期间是安全的,因为刷新操作在下次启动期间执行,使用与崩溃恢复相同的机制.如果数据库正在关闭以进行升级或降级,请执行slow shutdown**,以确保在关闭期间将所有相关更改应用于data files

另请参见崩溃恢复data files红晕关掉慢关机


  • 文件格式


    • InnoDB表的文件格式,使用innodb_file_format configuration 选项启用。支持的文件格式是AntelopeBarracuda。 Antelope 是原始的InnoDB文件格式,支持REDUNDANTCOMPACT行格式。 Barracuda 是较新的InnoDB文件格式,支持COMPRESSEDDYNAMIC行格式。

另请参见羚羊梭子鱼file-per-table.ibd 文件ibdata 文件行格式


  • file-per-table


    • innodb_file_pertable选项控制的设置的常规 name,这是一个重要的 configuration 选项,它影响InnoDB文件存储的各个方面,features 的可用性和 I/O 特性。从 MySQL 5.6.7 开始,默认情况下启用innodb_file_pertable

启用innodb_file_pertable选项后,您可以在其自己的**.ibd 文件中创建 table,而不是在系统表空间的共享ibdata files中创建 table。当 table 数据存储在单独的.ibd 文件中时,您可以更灵活地选择 features 所需的行格式**,例如数据压缩TRUNCATE TABLE操作也更快,操作系统可以使用回收空间,而不是为InnoDB保留。

MySQL Enterprise Backup产品对于自己的 files 中的表更灵活。对于 example,可以从备份中排除表,但前提是它们位于单独的 files 中。因此,此设置适用于较少备份或不同计划的表。

另请参见压缩行格式压缩文件格式.ibd 文件ibdata 文件innodb_file_pertableMySQL 企业备份行格式系统表空间


  • 填充因子


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

另见指数


  • 固定行格式


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

另见紧凑的行格式行格式


  • 红晕


    • 将更改写入已在 memory 区域或临时磁盘存储区域中缓冲的数据库 files。定期刷新的InnoDB存储结构包括redo logundo logbuffer pool

刷新可能是因为 memory 区域变满并且系统需要释放一些空间,因为commit操作意味着可以最终确定 transaction 的更改,或者因为slow shutdown操作意味着所有未完成的工作应该最终确定。当一次刷新所有缓冲数据并不重要时,InnoDB可以使用一种称为模糊检查点的技术来刷新小批量页面以分散 I/O 开销。

另请参见缓冲池承诺模糊检查点重做 log慢关机撤消 log


  • 刷新清单


    • 一个内部InnoDB数据结构,用于跟踪缓冲池中的脏页:即页面已更改并需要写回磁盘。此数据结构经常由InnoDB internalmini-transactions 更新,因此受其自身的mutex保护,以允许并发访问缓冲池。

另请参见缓冲池脏页LRUmini-transactionmutex页面清洁


  • 外国 key


    • 一种指针关系,位于单独的InnoDB表中的行之间。外部 key 关系在parent tablechild table中的一列上定义。

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

设计规范化数据库的一个阶段是识别复制的数据,将数据分成新的 table,并建立外部 key 关系,以便可以像单个 table 一样查询多个表,使用 a加入操作。

另请参见child tableFOREIGN KEY 约束加入标准化空值parent table参照完整性相关


  • FOREIGN KEY 约束


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

另请参见child table约束DML外国 key空值


  • FTS

    • 在大多数情况下,full-text 搜索的首字母缩写词。有时在性能讨论中,完整 table 扫描的首字母缩写。

另见完整 table 扫描full-text 搜索


  • 完整备份


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

另请参见备用数据库部分备份


  • 完整 table 扫描


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

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

另见缓冲池指数


  • full-text 搜索


    • MySQL feature 用于在 table 数据中查找单词,短语,Boolean 组合等,比使用 SQL LIKE operator 或编写自己的 application-level 搜索算法更快,更方便,更灵活。它使用 SQL function MATCH()FULLTEXT 索引

另见FULLTEXT 指数


  • FULLTEXT 指数


    • 一种特殊的索引,它在 MySQLfull-text search 机制中保存搜索索引。表示列值的单词,省略任何指定为stopwords的单词。最初,仅适用于MyISAM表。从 MySQL 5.6.4 开始,它也适用于InnoDB表。

另请参见full-text 搜索指数InnoDB搜索索引停用词


  • 模糊检查点


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

另见缓冲池脏页红晕

G


  • GA


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

另见公测


  • 间隙


    • InnoDB index数据结构中可以插入新值的位置。使用SELECT ... FOR UPDATE等语句锁定一组行时,InnoDB可以创建适用于间隙的锁以及索引中的实际值。例如,如果您为更新选择了大于 10 的所有值,则间隙锁定会阻止另一个 transaction 插入大于 10 的新值.supremum recordinfimum record表示包含所有的空白大于或小于所有当前索引值的值。

另请参见并发差距锁定指数infimum record隔离 levelsupremum record


  • 差距锁定


    • 在索引记录之间的间隙上锁定**,或者在第一个索引 record 之前或之后的间隙上锁定**。对于 example,SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE;阻止其他 transactions 将 value 15 插入列t.c1,无论列中是否已存在任何此类 value,因为该范围内所有现有值之间的间隙都被锁定。与记录锁next-key 锁对比。

间隙锁是 performance 和并发之间权衡的一部分,用于某些 transaction隔离级别而不是其他级别。

另请参见间隙infimum recordnext-key 锁record 锁supremum record


  • 一般 log


  • 一般查询 log


    • 一种log,用于 MySQL 服务器处理的 SQL 语句的诊断和故障排除。可以存储在文件或数据库 table 中。您必须通过generallog configuration 选项启用此 feature 才能使用它。您可以通过sqllog_off configuration 选项为特定连接禁用它。

记录比慢查询 log更广泛的查询。与用于复制的binary log不同,通用查询 log 包含选择 statements 并且不维护严格的 ordering。有关更多信息,请参阅第 5.4.3 节,“一般查询 Log”

另见二进制 loglog慢查询 log


  • 一般表空间


    • 使用创建 TABLESPACE语法创建的共享InnoDB 表空间。一般表空间可以在 MySQL 数据目录之外创建,能够保存多个,并支持所有行格式的表。 MySQL 5.7.6 中引入了一般表空间。

使用CREATE TABLE tblname ... TABLESPACE [=] tablespacenameALTER TABLE tblname TABLESPACE [=] tablespacename语法将表添加到常规表空间。

系统表空间file-per-table表空间对比。

有关更多信息,请参阅第 14.6.3.3 节,“通用表空间”

另请参见file-per-table系统表空间表空间


  • 生成列


    • 一列,其值是根据列定义中包含的表达式计算的。生成的列可以是虚拟存储

另见基本栏目存储生成的列虚拟生成列


  • 生成存储列


  • 生成虚拟列


  • global transaction


    • 一种交易涉及XA操作。它由几个本身都是 transactional 的动作组成,但是所有动作必须作为 group 成功完成,或者全部作为 group 回滚。从本质上讲,这将ACID properties 扩展为“level”,以便多个 ACID transactions 可以作为 global 操作的组件同时执行,该操作也具有 ACID properties。

另见交易XA


  • group commit


    • 一个InnoDB优化,对一组commit操作执行一次 low-level I/O 操作(log write),而不是为每次提交单独刷新和同步。

另见二进制 log承诺

H


  • 哈希索引


    • 一种索引,用于使用相等操作符的查询,而不是范围操作符,如 greater-than 或BETWEEN。它适用于记忆表。虽然哈希索引是历史原因的记忆表的默认值,但该存储引擎还支持B-tree索引,这些索引通常是 general-purpose 查询的更好选择。

MySQL 包含此索引类型的变体,自适应哈希索引,如果需要,它将根据运行时条件自动构建InnoDB表。

另请参见自适应哈希索引B-tree指数InnoDB


  • 硬盘


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

另见disk-basedSSD


  • 心跳


    • 发送的周期性消息,指示系统正常运行。在replication context 中,如果master停止发送此类消息,则其中一个从属可以取代它。可以在 cluster 环境中的服务器之间使用类似的技术来确认所有服务器都正常运行。

另见master 服务器复制


  • high-water 马克


    • 表示上限的 value,可以是运行时不应超过的硬限制,也可以是实际达到的最大 value 的 record。与low-water 标记对比

另见low-water 标记


  • 历史清单


    • 计划由InnoDB 清除操作处理的具有 delete-marked 记录的事务列表。记录在undo log中。历史列表的长度由命令SHOW ENGINE INNODB STATUS报告。如果历史列表的长度超过innodb_max_purge_lag configuration 选项的 value,则每个DML操作会稍微延迟,以允许清除操作完成**刷新已删除的记录。

又称净化滞后

另请参见DML红晕清除清除滞后回滚段交易撤消 log

另见稀疏文件透明页面压缩



    • 如此频繁地访问行,table 或内部数据结构,需要某种形式的锁定或互斥的情况,这会导致性能或可伸缩性问题。

虽然“热”通常表示不良情况,但热备份是首选的备份类型。

另见热备份


  • 热备份


    • 在数据库运行 applications 正在读取和写入数据库时进行备份。备份不仅仅是复制数据 files:它必须包括备份在 process 时插入或更新的任何数据;它必须排除备份在 process 时删除的任何数据;它必须忽略任何未提交的更改。

执行热备份的 Oracle 产品,特别是InnoDB表,以及来自MyISAM和其他存储引擎的表,被称为MySQL Enterprise Backup

热备份 process 包含两个阶段。数据 files 的初始复制产生原始备份.apply ** step 包含备份 running 时发生的对数据库的任何更改。应用更改会生成准备**备份;这些 files 随时可以恢复。

另请参见应用MySQL 企业备份准备备份原始备份

一世


  • .ibd 文件

    • file-per-table表空间和一般表空间的数据文件。 File-per-table tablespace .ibd files 包含单个 table 和关联的索引数据。 常规表空间 .ibd files 可能包含多个表的 table 和索引数据。 MySQL 5.7.6 中引入了一般表空间。

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

如果使用DATA DIRECTORY =子句创建 file-per-table 表空间或通用表空间,则.ibd文件位于正常数据目录之外的指定路径上,并由**.isl 文件**指向。

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

另请参见数据库file-per-table一般表空间ibdata 文件.ibz 文件innodb_file_pertable.isl 文件MySQL 企业备份系统表空间


  • .ibz 文件


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

备份期间应用的压缩与压缩行格式不同,后者在正常操作期间保持 table 数据压缩。压缩备份操作会跳过已经处于压缩行格式的表空间的压缩 step,因为压缩第二个 time 会减慢备份速度,但几乎不会节省空间。

另请参见压缩备份压缩行格式file-per-table.ibd 文件MySQL 企业备份表空间


  • .isl 文件


    • 一个文件,用于指定文件的位置**,该InnoDB table 是使用 MySQL 5.6 及更高版本中的DATA DIRECTORY =子句创建的InnoDB table,或者是 MySQL 5.7.8 及更高版本中的CREATE TABLESPACE ... ADD DATAFILE子句.它的功能类似于符号链接,没有实际符号链接机制的平台限制.您可以在数据库目录外 store InnoDB表空间,例如,在特别大或快速的存储设备上,具体取决于 table 的用法。有关详细信息,请参阅部分 14.6.3.6,“在数据目录之外创建表空间”第 14.6.3.3 节,“通用表空间”

另请参见数据库.ibd 文件表空间


  • I/O-bound


  • ib-file 设定


    • 在 MySQL 数据库中由InnoDB管理的 files 集:系统表空间file-per-table表空间 files 和重做 logfiles。根据 MySQL version 和InnoDB configuration,还可能包括通用表空间临时表空间撤消表空间 files。这个术语有时用于InnoDB文件结构和格式的详细讨论,以引用 MySQL 数据库中由InnoDB管理的 files 集。

另请参见数据库file-per-table一般表空间重做 log系统表空间临时表空间撤消表空间


  • ibbackuplogfile


    • 热备份操作期间由MySQL Enterprise Backup产品创建的补充备份文件。它包含有关备份 running 时发生的任何数据更改的信息。初始备份 files(包括ibbackup_logfile)称为原始备份,因为备份操作期间发生的更改尚未合并。在执行apply step 到原始备份 files 之后,生成的 files 确实包含那些最终数据更改,并且被称为准备备份。在此阶段,不再需要ibbackup_logfile文件。

另请参见应用热备份MySQL 企业备份准备备份原始备份


  • ibdata 文件


    • 一组_file,其名称如ibdata1ibdata2等构成 InnoDB 系统表空间。这些 files 包含有关InnoDB表的元数据(InnoDB数据字典),以及一个或多个撤消日志更改缓冲区双写缓冲区的存储区域。它们也可以包含部分或全部 table 数据(取决于创建每个 table 时file-per-table模式是否有效)。启用innodb_file_pertable选项后,新创建的表的数据和索引将存储在单独的**.ibd files**中,而不是存储在系统表空间中。

ibdata files 的增长受innodb_autoextend_increment configuration 选项的影响。

另请参见改变缓冲区数据字典双写缓冲区file-per-table.ibd 文件innodb_file_pertable系统表空间撤消 log


  • ibtmp 文件


    • InnoDB 临时表空间****数据文件用于 non-compressed InnoDB临时表和相关的 objects。 configuration 文件选项innodb_temp_data_file_path允许用户定义临时表空间数据文件的相对路径。如果未指定innodb_temp_data_file_path,则默认行为是在数据目录中与ibdata1一起创建名为ibtmp1的单个 auto-extending 12MB 数据文件。

另见data files临时表临时表空间


  • iblogfile

    • 一组 files,通常名为ib_logfile0ib_logfile1,形成redo log。有时也称为log group。这些 files record statements 尝试更改InnoDB表中的数据。在崩溃后启动时,会自动重放这些语句以更正由不完整的 transactions 写入的数据。

此数据不能用于手动恢复;对于该类型的操作,请使用binary log

另见二进制 loglog group重做 log


  • i 列表


    • InnoDB FULLTEXT 索引内,数据结构由文档 ID 和令牌的位置信息(即特定单词)组成。

另见FULLTEXT 指数


  • 隐式行锁


    • InnoDB获取的行锁以确保一致性,而无需您特别请求它。

另见行锁


  • in-memory 数据库


    • 一种数据库系统,用于维护 memory 中的数据,以避免由于磁盘 I/O 和磁盘块与 memory 区域之间的转换而导致的开销。一些 in-memory 数据库牺牲了耐久性(ACID设计理念中的“D”)并且容易受到硬件,电源和其他类型的故障的影响,使它们更适合于 read-only 操作。其他 in-memory 数据库确实使用持久性机制,例如 logging 对磁盘的更改或使用 non-volatile memory。

处理相同类型的 memory-intensive 处理的 MySQL features 包括InnoDB 缓冲池自适应哈希索引read-only transaction优化,记忆存储引擎,MyISAM key 缓存和 MySQL 查询缓存。

另请参见自适应哈希索引缓冲池disk-basedread-only transaction


  • 增量备份


    • 一种热备份,由MySQL Enterprise Backup产品执行,仅保存自 time 中的某些点以来更改的数据。通过完整备份和一系列增量备份,您可以在_一段时间内重建备份数据,而无需保留几个完整备份的存储开销。您可以还原完整备份,然后连续应用每个增量备份,也可以通过将每个增量备份应用到它来保留完整备份 up-to-date,然后执行单个还原操作。

更改数据的粒度位于页面 level。页面实际上可能涵盖多行。每个更改的页面都包含在备份中。

另见热备份MySQL 企业备份


  • 指数


    • 一种数据结构,为table提供快速查找功能,通常通过形成表示特定或集合的所有值的树结构(**B-tree)**列。

    InnoDB表总是有一个聚集索引代表primary key。它们还可以在一列或多列上定义一个或多个二级索引。根据其结构,二级索引可以分为部分复合索引。

索引是查询performance 的重要方面。数据库架构师设计表,查询和索引,以允许快速查找 applications 所需的数据。理想的数据库设计在可行的情况下使用覆盖指数;查询结果完全从索引计算,而不读取实际的 table 数据。每个foreign key约束也需要一个索引,以有效地检查parentchild表中是否存在值。

虽然 B-tree 索引是最常见的 common,但哈希索引使用不同类型的数据结构,如MEMORY存储引擎和InnoDB自适应哈希索引.**R-tree **索引用于 multi-dimensional 信息的空间索引。

另请参见自适应哈希索引B-treechild table聚集索引列索引综合指数覆盖指数外国 key哈希索引parent table部分指数首要的关键询问R-tree二级指数


  • 索引缓存


    • 一个 memory 区域,用于保存InnoDB full-text search的令牌数据。当数据在作为FULLTEXT 索引的一部分的列中插入或更新时,它会缓冲数据以最小化磁盘 I/O。当索引缓存已满时,令牌数据将写入磁盘。每个InnoDB FULLTEXT索引都有自己独立的索引缓存,其大小由 configuration 选项innodb_ft_cache_size控制。

另见full-text 搜索FULLTEXT 指数


  • 指数条件下推


    • 索引条件下推(ICP)是一种优化,如果可以使用索引中的字段评估部分条件,则将WHERE条件的一部分推送到存储引擎。 ICP 可以减少存储引擎必须访问 base table 的次数以及 MySQL 服务器必须访问存储引擎的次数。有关更多信息,请参阅第 8.2.1.5 节,“索引条件下推优化”

另见指数存储引擎


  • 索引提示

    • 扩展 SQL 语法,用于覆盖优化程序建议的索引。对于 example,FORCE INDEXUSE INDEXIGNORE INDEX子句。通常在索引列具有不均匀分布的值时使用,导致基数估计不准确。

另见基数指数


  • 索引前缀


    • 在适用于多个列的索引(称为复合索引)中,索引的初始列或前导列。即使查询不引用索引中的所有列,查询复合索引的前 1,2,3 等列的查询也可以使用索引。

另见综合指数指数


  • 指数统计


  • infimum record


    • 指数中的pseudo-record,表示该指数中最小值以下的缺口。如果 transaction 具有SELECT ... FROM ... WHERE col < 10 FOR UPDATE;之类的语句,并且列中的最小 value 为 5,则它是 infimum record 上的锁定,阻止其他 transactions 插入更小的值,如 0,-10 等。

另请参见间隙指数pseudo-recordsupremum record


  • INFORMATIONSCHEMA


    • 数据库的 name,它提供 MySQL数据字典的查询接口。 (此 name 由 ANSI SQL standard.)定义要检查有关数据库的信息(元数据),您可以查询诸如INFORMATION_SCHEMA.TABLESINFORMATION_SCHEMA.COLUMNS之类的表,而不是使用产生非结构化输出的SHOW命令。

INFORMATION_SCHEMA数据库还包含特定于InnoDB的表,它们为InnoDB数据字典提供查询接口。您使用这些表不是为了查看数据库的结构,而是获取有关InnoDB表的工作方式的 real-time 信息,以帮助进行 performance 监视,调整和故障排除。

另见数据字典数据库InnoDB


  • InnoDB


    • 一个 MySQL component,它结合了高 performance 和transactional功能,可靠性,健壮性和并发访问。它体现了ACID的设计理念。代表存储引擎;它处理使用ENGINE=INNODB子句创建或更改的表。有关体系结构详细信息和管理过程,请参阅第 14 章,InnoDB 存储引擎,有关 performance 建议,请参阅第 8.5 节,“优化 InnoDB 表”

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

InnoDB表非常适合热备份。有关用于备份 MySQL 服务器的MySQL Enterprise Backup产品的信息,请参阅第 29.2 节,“MySQL 企业备份概述”,而不会中断正常处理。

另请参见热备份MySQL 企业备份存储引擎交易


  • innodb_autoinc_lock_mode


    • innodb_autoinc_lock_mode选项控制用于auto-increment 锁定的算法。如果有 auto-incrementing主 key ,则只能使用innodb_autoinc_lock_mode=1复制设置innodb_autoinc_lock_mode=1。此设置称为连续锁定模式,因为在 transaction 中插入 multi-row 会接收连续的 auto-increment 值。如果您有innodb_autoinc_lock_mode=2,它允许 insert 操作具有更高的并发性,请使用 row-based 复制而不是 statement-based 复制。此设置称为交错锁定模式,因为在同一 time 运行多个 multi-row 插入语句可以接收交错的auto-increment值。除兼容性目的外,不应使用innodb_autoinc_lock_mode=0设置。

连续锁定模式(innodb_autoinc_lock_mode=1)是 MySQL 8.0.3 之前的默认设置。从 MySQL 8.0.3 开始,交错锁定模式(innodb_autoinc_lock_mode=2)是默认值,它反映了从 statement-based 到 row-based 复制的更改作为默认复制类型。

另请参见auto-incrementauto-increment 锁定mixed-mode insert首要的关键


  • innodb_file_format


    • innodb_file_format选项定义文件格式以用于新的InnoDB file-per-table表空间。目前,您可以指定AntelopeBarracuda文件格式。

另请参见羚羊梭子鱼文件格式file-per-table一般表空间innodb_file_pertable系统表空间表空间


  • innodb_file_pertable


    • 一个重要的 configuration 选项,它影响InnoDB文件存储的许多方面,features 的可用性和 I/O 特性。在 MySQL 5.6.7 及更高版本中,默认情况下启用它。 innodb_file_pertable选项打开file-per-table模式。启用此模式后,新创建的InnoDB table 和关联索引可以存储在系统表空间之外的 file-per-table**.ibd 文件**中。

此选项会影响许多 SQL 语句的 performance 和存储注意事项,例如DROP TABLETRUNCATE TABLE

启用innodb_file_pertable选项可以利用MySQL Enterprise Backup中的 table 压缩和 named-table 备份等功能。

有关更多信息,请参阅innodb_file_pertable第 14.6.3.2 节,“File-Per-Table 表空间”

另请参见压缩file-per-table.ibd 文件MySQL 企业备份系统表空间


  • innodb_lock_waittimeout

    • innodb_lock_waittimeout选项设置等待以使共享资源可用,或放弃和处理错误,重试或在 application 中执行备用处理之间的平衡。回滚任何等待超过指定 time 的InnoDB transaction 以获取。如果死锁是由不同存储引擎控制的多个表的更新引起的,则特别有用;不会**自动检测到这种死锁。

另请参见僵局死锁检测等待


  • innodb_strict_mode


    • innodb_strict_mode选项控制InnoDB是否以严格模式运行,其中通常被视为警告的条件会导致错误(而基础语句失败)。

另见严格模式


  • 插入


    • SQL中的主要DML操作之一。插入的 performance 是数据仓库系统中的一个 key 因子,它将数百万行加载到表中,OLTP系统,其中许多并发连接可能行插入同一 table,任意 order。如果 insert performance 对您很重要,您应该了解InnoDB features,例如更改缓冲auto-increment列中使用的insert buffer

另请参见auto-increment改变缓冲数据仓库DMLInnoDBinsert 缓冲区OLTPSQL


  • insert 缓冲区


    • 更改缓冲区的前 name。在 MySQL 5.5 中,添加了支持以缓冲对删除UPDATE操作的二级索引页面的更改。以前,只缓冲由插入操作产生的更改。首选术语现在是更改缓冲区。

另见改变缓冲区改变缓冲


  • insert 缓冲


    • 更改缓冲区中存储由插入操作产生的二级索引页面的更改而不是立即写入更改的技术,以便可以执行物理写入以最小化随机 I/O。它是改变缓冲的类型之一;其他人是删除缓冲清除缓冲

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

另请参见改变缓冲区改变缓冲删除缓冲insert 缓冲区清除缓冲独特的指数


  • 插入意图锁


    • 一种间隙锁,由行插入前的插入操作设置。这种类型的表示插入的意图,即插入到同一索引间隙中的多个 transactions 如果不插入间隙内的相同位置,则不需要等待彼此。有关更多信息,请参阅第 14.7.1 节,“InnoDB 锁定”

另见差距锁定next-key 锁



    • 一个mysqld守护程序管理数据目录,代表一个或多个数据库,带有一组。在开发,测试和一些复制场景中,常见的是在同一个服务器机器上有多个实例,每个实例管理自己的数据目录并监听它自己的 port 或 socket。如果一个实例 running**disk-bound **工作负载,服务器可能仍有额外的 CPU 和 memory 容量来运行其他实例。

另请参见数据目录数据库disk-boundmysqld复制服务器


  • 仪器仪表


    • source code level 上的修改,用于收集 performance 数据以进行调整和调试。在 MySQL 中,使用INFORMATION_SCHEMAPERFORMANCE_SCHEMA数据库通过 SQL 接口公开由检测收集的数据。

另见INFORMATIONSCHEMAPerformance Schema


  • 意图独家锁


  • 意图锁定


    • 一种适用于 table 的,用于指示事务打算在 table 中的行上获取的锁类型。不同的 transactions 可以在同一个 table 上获取不同类型的意图锁,但第一个 transaction 获取意图在 table 上的独占(IX)锁定会阻止其他 transactions 获取 table 上的任何 S 或 X 锁。相反,在 table 上获取意图共享(IS)锁的第一个 transaction 会阻止其他 transactions 获取 table 上的任何 X 锁。 two-phase process 允许在 order 中解析锁定请求,而不会阻塞锁定和兼容的相应操作。有关此锁定机制的更多信息,请参阅第 14.7.1 节,“InnoDB 锁定”

另请参见锁定模式锁定交易


  • 意图共享锁


  • 内在的临时 table


    • 优化程序使用的优化内部InnoDB临时 table。

另见优化


  • 倒指数

    • 为文档检索系统优化的数据结构,用于InnoDB full-text 搜索的实现。实现为倒排索引的InnoDBFULLTEXT 索引记录文档中每个单词的位置,而不是 table 行的位置。单列 value(存储为 text string 的文档)由反向索引中的许多条目表示。

另见full-text 搜索FULLTEXT 指数i 列表


  • IOPS


    • 每秒I/O 次操作的缩写。繁忙系统的常见测量,尤其是OLTP applications。如果此 value 接近存储设备可以处理的最大值,则 application 可以变为disk-bound,从而限制可伸缩性

另见disk-boundOLTP可扩展性


  • 隔离 level


    • 数据库处理的基础之一。隔离是I的首字母缩写ACID;隔离 level 是在多个事务进行更改并在同一时间执行查询时性能与可靠性,一致性和结果可重复性之间的平衡的设置。

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

对于InnoDB表,许多用户可以为所有操作保留默认隔离 level(REPEATABLE READ)。专家用户可以选择READ COMMITTED level,因为它们通过OLTP处理推动可伸缩性的界限,或者在数据仓库操作期间,其中轻微的不一致性不会影响大量数据的聚合结果。边缘上的级别(SERIALIZABLEREAD UNCOMMITTED)将处理行为改变到很少使用它们的程度。

另请参见OLTP阅读提交阅读不满意可重复阅读SERIALIZABLE交易

Ĵ


  • 加入


    • 一个查询,它通过引用包含相同值的表中的列来从多个 table 中检索数据。理想情况下,这些列是InnoDB外部 key 关系的一部分,它确保参照完整性并且连接列被索引。通常用于在规范化数据设计中通过用数字 ID 替换重复的 strings 来节省空间并改善查询性能。

另请参见外国 key指数标准化询问参照完整性

ķ


  • KEY_BLOCK_SIZE


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

对于MyISAM 数据表,KEY_BLOCK_SIZE可选地指定用于索引 key 块的大小(以字节为单位)。 value 被视为提示;如有必要,可以使用不同的尺寸。为单个索引定义指定的KEY_BLOCK_SIZE value 会覆盖 table-level KEY_BLOCK_SIZE value。

另见压缩行格式

大号



    • InnoDB用于为其内部 memory 结构实现的轻量级结构,通常以毫秒或微秒为单位保持一段时间。一个通用术语,包括互斥锁(用于独占访问)和rw-locks(用于共享访问)。某些锁存器是InnoDB performance 调整的重点。有关锁存器使用和争用的统计信息可通过Performance Schema接口获得。

另请参见锁定mutexPerformance Schemarw-lock


  • 名单


    • InnoDB 缓冲池表示为 memory页面的列表。当访问新页面并进入缓冲池时,该列表被重新排序,因为缓冲池中的页面被再次访问并被认为是更新的,并且因为 long time 访问的页面被从缓冲池中逐出**.缓冲池分为子列表,替换 policy 是熟悉的LRU技术的变体。

另请参见缓冲池赶出LRU子表



    • 作为锁定策略的一部分,object 的 high-level 概念控制对资源的访问,例如 table,行或内部数据结构。对于密集的 performance 调优,您可能需要深入研究实现锁的实际结构,例如互斥锁锁存器

另请参见锁定模式锁定mutex


  • 锁定升级


    • 在某些数据库系统中使用的操作,它将许多行锁转换为单个表锁,从而节省了 memory 空间,但减少了对 table 的并发访问。 InnoDB对行锁使用 space-efficient 表示,因此不需要lock升级。

另见锁定行锁table 锁


  • 锁定模式

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

独占(X)锁允许 transaction 更新或删除行。没有其他 transaction 可以在同一个 time 上同一行获取任何类型的锁。

意图锁适用于 table,用于指示 transaction 要在 table 中的行上获取什么类型的锁。不同的 transactions 可以在同一个 table 上获取不同类型的意图锁,但第一个 transaction 获取意图在 table 上的独占(IX)锁定会阻止其他 transactions 获取 table 上的任何 S 或 X 锁。相反,在 table 上获取意图共享(IS)锁的第一个 transaction 会阻止其他 transactions 获取 table 上的任何 X 锁。 two-phase process 允许在 order 中解析锁定请求,而不会阻塞锁定和兼容的相应操作。

另请参见意图锁定锁定交易


  • 锁定


    • 保护事务免于查看或更改其他 transactions 正在查询或更改的数据的系统.锁定策略必须平衡数据库操作的可靠性和一致性(ACID哲学的原则)与良好的并发性所需的性能。 Fine-tuning 锁定策略通常涉及选择isolation level并确保所有数据库操作对于隔离 level 是安全可靠的。

另请参见并发隔离 level锁定交易


  • 锁定读取


    • 一个选择语句,它还对InnoDB table 执行锁定操作。 SELECT ... FOR UPDATESELECT ... LOCK IN SHARE MODE。它有可能产生死锁,具体取决于 transaction 的isolation levelnon-locking 读的反面.**read-only transaction **中的 global 表不允许。

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

第 14.7.2.4 节,“锁定读取”

另请参见僵局隔离 level锁定non-locking 读read-only transaction


  • log


    • InnoDB context 中,“ log”或“log files”通常是指iblogfileN files 表示的redo log。另一种类型的InnoDB log 是undo log,它是一个存储区域,用于保存 active transactions 修改的数据副本。

在 MySQL 中很重要的其他类型的日志是error log(用于诊断启动和运行时问题),binary log(用于复制和执行 point-in-time 恢复),通用查询 log * *(用于诊断 application 问题),以及慢查询 log**(用于诊断 performance 问题)。

另请参见二进制 log错误 log一般查询 logiblogfile重做 log慢查询 log撤消 log


  • log 缓冲区


    • memory 区域包含要写入log files的数据,组成redo log。它由innodblog_buffer_size configuration 选项控制。

另见log 文件重做 log


  • log 文件


    • 构成重做 logiblogfileN 文件之一。数据从log buffer memory 区域写入这些 files。

另见iblogfilelog 缓冲区重做 log


  • log group


    • 构成重做 log的 files 集合,通常命名为ib_logfile0ib_logfile1。 (因此,有时统称为iblogfile .)

另见iblogfile重做 log


  • 合乎逻辑


    • 一种涉及 high-level 的操作,包括表,查询,索引和其他 SQL 概念等抽象方面。通常,逻辑方面对于使数据库管理和应用程序开发方便和可用非常重要。与物理对比。

另见逻辑备份物理


  • 逻辑备份


    • 一个备份,它可以重现 table 结构和数据,而无需复制实际数据 files。例如,mysqldump命令产生一个逻辑备份,因为它的输出包含_st_,如创建 TABLE插入,可以 re-create 数据。与物理备份对比。逻辑备份提供了灵活性(例如,您可以在还原之前编辑 table 定义或 insert statements),但是比物理备份需要更长的时间来恢复**。

另请参见备用mysqldump物理备份恢复


  • 疏松_


    • 在服务器启动之后添加到InnoDB configuration 选项的前缀,因此 MySQL 的当前 level 无法识别的任何新的 configuration 选项不会导致启动失败。 MySQL 处理以此前缀开头的 configuration 选项,但如果前缀后面的部分不是可识别的选项,则会发出警告而不是失败。

另见启动


  • low-water 马克


    • 表示下限的值,通常是阈值值,某些纠正操作开始或变得更具侵略性。与high-water 标记对比

另见high-water 标记


  • LRU


    • “最近最少使用”的首字母缩写,一种用于管理存储区域的常用方法。当需要空间来缓存较新的项目时,最近未使用的项目将被驱逐**.InnoDB默认使用 LRU 机制来管理缓冲池中的页面,但是在页面可能只读取一个 time 的情况下进行 exceptions,例如在完整 table 扫描期间* *。 LRU 算法的这种变化称为中点插入策略**。有关更多信息,请参阅第 14.5.1 节,“缓冲池”

另请参见缓冲池赶出完整 table 扫描中点插入策略


  • LSN


    • “log 序列号”的缩写。这个任意的 ever-increasing value 代表 time 中与redo log中记录的操作相对应的一个点。 (time 中的这一点与transaction边界无关;它可以落在一个或多个 transactions.)的中间。它在崩溃恢复期间由InnoDB内部使用,并用于管理缓冲池

在 MySQL 5.6.3 之前,LSN 是一个 4-byte 无符号的 integer。当 redo log 文件大小限制从 4GB 增加到 512GB 时,LSN 成为 MySQL 5.6.3 中的 8-byte 无符号整数,因为需要额外的字节来存储额外的大小信息。 基于 MySQL 5.6.3 或更高版本构建的使用 LSN 值的应用程序应该使用 64-bit 而不是 32-bit 变量来存储和比较 LSN 值。

MySQL Enterprise Backup产品中,您可以指定一个 LSN 来表示 time 中从中进行增量备份的点。相关的 LSN 由mysqlbackup命令的输出显示。一旦您拥有与完整备份的 time 相对应的 LSN,您就可以指定 value 进行后续增量备份,其输出包含用于下一次增量备份的另一个 LSN。

另请参见缓冲池崩溃恢复增量备份MySQL 企业备份重做 log交易

中号


  • .MRG 文件


    • 包含_seference 到其他表的文件,由MERGE存储引擎使用。 具有此扩展名的文件始终包含在由MySQL Enterprise Backup产品的mysqlbackup命令生成的备份中。

另见MySQL 企业备份mysqlbackup 命令


  • .MYD 文件

另见.MYI 文件MySQL 企业备份mysqlbackup 命令


  • .MYI 文件

另见.MYD 文件MySQL 企业备份mysqlbackup 命令


  • master 服务器


    • 经常缩写为“master”。 复制方案中的数据库服务器计算机,用于处理数据的初始 insert,update 和 delete 请求。这些更改将传播到其他服务器(称为从属服务器)并在其上重复执行。

另见复制奴隶服务器


  • master 线程


    • 一个InnoDB 线程,它在后台执行各种任务。这些任务中的大多数都与 I/O 相关,例如将更改从更改缓冲区写入相应的二级索引。

为了提高并发性,有时操作会从 master 线程移动到单独的后台线程。例如,在 MySQL 5.6 和更高版本中,脏页****由页面清除程序线程而不是 master 线程从缓冲池中刷新

另请参见缓冲池改变缓冲区并发脏页红晕页面清洁线


  • MDL


    • “元数据锁定”的缩写。

另见元数据锁


  • memcached


    • 许多 MySQL 和NoSQL软件堆栈的流行组件,允许对单个值进行快速读写,并将结果完全缓存在 memory 中。传统上,applications 需要额外的逻辑来将相同的数据写入 MySQL 数据库以进行永久存储,或者在 MySQL 数据库尚未在 memory 中缓存时从 MySQL 数据库中读取数据。现在,applications 可以使用简单的memcached协议,client libraries 支持多种语言,使用InnoDBNDB表直接与 MySQL 服务器通信。这些与 MySQL 表的 NoSQL 接口允许 applications 实现比直接发出 SQL statements 更高的读写性能,并且可以简化已经包含memcached用于 in-memory 缓存的系统的 application 逻辑和部署配置。

InnoDB表的memcached接口在 MySQL 5.6 及更高版本中可用;有关详细信息,请参阅第 14.20 节,“InnoDB memcached 插件”NDB表的memcached接口在 NDB Cluster 7.2 及更高版本中可用;有关详细信息,请参阅http://dev.mysql.com/doc/ndbapi/en/ndbmemcache.html

另见InnoDBNoSQL


  • 合并

    • 将更改应用于 memory 中缓存的数据,例如当页面进入缓冲池时,更改缓冲区中记录的任何适用更改都将合并到缓冲池中的页面中。更新的数据最终由flush机制写入表空间

另请参见缓冲池改变缓冲区红晕表空间


  • 元数据锁

在线操作的增强功能,特别是在 MySQL 5.6 及更高版本中,专注于减少元数据锁定的数量。目标是 DDL 操作不会更改 table 结构(例如InnoDBDROP INDEX表的创建指数DROP INDEX),而其他 transactions 正在查询,更新等 table。

另请参见DDL线上交易


  • metrics counter


    • 一个 feature 由INFORMATIONSCHEMA中的INNODBMETRICS table 实现,在 MySQL 5.6 和更高版本中。您可以查询计数和 low-level InnoDB操作的总计,并将 performance tuning 的结果与Performance Schema中的数据结合使用。

另见计数器INFORMATIONSCHEMAPerformance Schema


  • 中点插入策略


    • 最初将页面带入InnoDB缓冲池的技术不是在列表的“最新”端,而是在中间的某个地方。根据innodb_old_blocks_pct选项的设置,此点的确切位置可能会有所不同。目的是只读取一次的页面,例如在完整 table 扫描期间,可以比使用严格的LRU算法更早地从缓冲池中老化。有关更多信息,请参阅第 14.5.1 节,“缓冲池”

另请参见缓冲池完整 table 扫描LRU


  • mini-transaction


    • DML操作期间,当物理level 对内部数据结构进行更改时,InnoDB处理的内部阶段。 mini-transaction(mtr)没有回滚的概念;多个 mini-transactions 可以在单个事务中发生。 Mini-transactions 将信息写入崩溃恢复期间使用的redo log。 mini-transaction 也可以发生在常规 transaction 的 context 之外,对于 example,由后台线程进行清除处理。

另请参见承诺崩溃恢复DML物理清除重做 log回滚交易


  • mixed-mode insert


    • 一个插入语句,其中为某些但不是所有新行指定了auto-increment值。对于 example,multi-value INSERT可以在某些情况下为 auto-increment 列指定 value,在其他情况下为NULL指定 value。 InnoDB为列 value 指定为NULL的行生成 auto-increment 值。另一个 example 是一个INSERT ... ON DUPLICATE KEY UPDATE语句,其中可能会生成 auto-increment 值,但不会使用,因为任何重复的行都被处理为UPDATE而不是INSERT statements。

复制configuration 中,可能导致** masterslave服务器之间出现一致性问题。可能需要调整innodb_autoinc_lock_mode** configuration 选项的 value。

另请参见auto-incrementinnodb_autoinc_lock_modemaster 服务器复制奴隶服务器


  • 地铁


  • multi-core


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

  • 多版本并发控制


  • mutex


    • “mutex 变量”的非正式缩写。 (Mutex 本身是“互斥”的缩写.) 用于表示和强制执行 exclusive-access 锁定到内部 in-memory 数据结构的对象。一旦获得锁定,就会阻止任何其他进程,线程等获取相同的锁。与rw-locks对比,InnoDB用来表示并强制执行 shared-access 锁定到内部 in-memory 数据结构。互斥锁和 rw-locks 统称为锁存器

另请参见Performance Schema并行线程rw-lock


  • MVCC


    • “multiversion 并发控制”的缩写。这种技术允许具有某些隔离级别的InnoDB事务执行一致的读取操作;也就是说,查询其他 transactions 正在更新的行,并查看这些更新发生之前的值.这是一种增强并发的强大技术,允许查询继续进行而无需等待由于其他 transactions 持有的锁**。

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

另请参见并发一致阅读隔离 level交易


  • my.cnf


    • 在 Unix 或 Linux 系统上的 name,MySQL 选项文件

另见my.ini选项文件


  • my.ini

    • MySQL 选项文件的 Windows 系统上的 name。

另见my.cnf选项文件


  • MySQL


    • MySQL程序是 MySQL 数据库的 command-line interpreter。它通过将请求传递给mysqld守护程序来处理SQL statements 以及 MySQL-specific 命令(如显示表格)。

另见mysqldSQL


  • MySQL 企业备份


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

另见热备份InnoDB

另见热备份MySQL 企业备份热备份


  • mysqld


    • mysqld程序是 MySQL 数据库的数据库引擎。它作为 Unix 守护程序或 Windows 服务运行,不断等待请求并在后台执行维护工作。

另见MySQL


  • mysqldump


    • 一个命令,用于执行某些数据库,表和 table 数据组合的逻辑备份。结果是 SQL statements,它们可以重现原始的 schema objects,data 或两者。对于大量数据,物理备份解决方案(如MySQL Enterprise Backup)更快,特别是对于restore操作。

另请参见逻辑备份MySQL 企业备份物理备份恢复

ñ


  • 自然 key


    • 索引列,通常是primary key,其中值具有一些 real-world 重要性。通常建议不要因为:
  • 如果 value 应该更改,则 re-sort 聚集索引可能会有很多索引维护,并更新在每个二级索引中重复的主 key value 的副本。

  • 即使看似稳定的值也会以不可预测的方式改变,这些方式难以在数据库中正确表示。例如,一个国家/地区可以更改为两个或几个国家/地区,使原始国家 code 过时。或者,有关唯一值的规则可能具有 exceptions。例如,即使纳税人 ID 对于单个人来说是唯一的,数据库也可能必须处理违反该规则的记录,例如在身份被盗的情况下。纳税人 ID 和其他敏感 ID numbers 也会使主要密钥变差,因为它们可能需要受到保护,加密和以其他方式与其他列不同的处理方式。

因此,对于使用auto-increment列的 example,通常最好使用任意数值来形成合成 key

另请参见auto-increment聚集索引首要的关键二级指数合成 key


  • 邻居页面


    • 任何页面与特定页面相同范围。当选择页面刷新时,任何的邻居页面通常也会被刷新,作为传统硬盘的 I/O 优化。在 MySQL 5.6 及更高版本中,此行为可由 configuration 变量innodb_flush_neighbors控制;您可能会为 SSD 驱动器关闭该设置,因为 SSD 驱动器在随机位置编写较小批量数据的开销不同。

另请参见脏页程度红晕


  • next-key 锁


    • 索引 record 上的记录锁和索引 record 之前的间隙上的差距锁定的组合。

另见差距锁定锁定record 锁


  • non-locking 阅读

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

另见锁定读取询问read-only transaction


  • non-repeatable 阅读


    • 查询检索数据时的情况,以及同一事务中的后续查询检索应该是相同数据的内容,但查询返回不同的结果(在此期间由另一个 transaction 提交更改)。

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

在不同的隔离级别中,non-repeatable 读取由可序列化读取可重复读取级别阻止,并且由一致读取读取未提交级别允许。

另请参见一致阅读隔离 level阅读不满意可重复阅读SERIALIZABLE交易


  • 无阻塞 I/O


    • 行业术语与异步 I/O相同。

另见异步 I/O


  • 标准化

    • 数据库设计策略,将数据拆分为多个表,并将重复值压缩为由 ID 表示的单个行,以避免存储,查询和更新冗余或冗长的值。它通常用于OLTP applications。

例如,一个地址可能被赋予一个唯一的 ID,因此人口普查数据库可以通过将该 ID 与一个系列的每个成员相关联来表示该地址的关系,而不是存储复杂 value 的多个副本。作为123 Main Street,Anytown,USA

另一个例子是,虽然一个简单的地址簿 application 可能会将每个电话号码存储在与人的 name 和地址相同的 table 中,但电话公司数据库可能会为每个电话号码分配一个特殊 ID,并将 numbers 和 ID 存储在单独的 table 中。当区域代码分开时,这种规范化表示可以简化 large-scale 更新。

并不总是建议进行标准化。主要查询并且仅通过完全删除和重新加载来更新的数据通常保存在具有重复值的冗余副本的更少,更大的表中。此数据表示称为非规范化,并且经常在数据仓库应用程序中找到。

另请参见非规范化外国 keyOLTP相关


  • NoSQL


    • 一组数据访问技术的广义术语,它们不使用SQL语言作为读取和写入数据的主要机制。一些 NoSQL 技术充当 key-value stores,只接受 single-value 读写;一些人放松了ACID方法的限制;还有一些人不需要 pre-planned 架构。 MySQL 用户可以通过使用memcached API 直接访问某些类型的 MySQL 表,将 NoSQL-style 处理速度和简单性与 SQL 操作结合起来,以实现灵活性和便利性。 InnoDB表的memcached接口在 MySQL 5.6 及更高版本中可用;有关详细信息,请参阅第 14.20 节,“InnoDB memcached 插件”NDB表的memcached接口在 NDB Cluster 7.2 及更高版本中可用;见用于 NDB Cluster 的 ndbmemcache-Memcache API

另请参见InnoDBmemcachedschemaSQL


  • NOT NULL 约束


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

另请参见约束空值首要的关键参照完整性


  • 空值


    • SQL中的特殊 value,表示缺少数据。任何涉及NULL value 的算术运算或相等测试都会产生NULL结果。 (因此它类似于 NaN 的 IEEE floating-point 概念,“不是数字”.)任何聚合计算,例如AVG()忽略具有NULL值的行,在确定要分割的行数时。唯一适用于NULL值的测试使用 SQL 成语IS NULLIS NOT NULL

    NULL值在index操作中起作用,因为对于 performance,数据库必须最小化跟踪丢失数据值的开销。通常,NULL值不存储在索引中,因为使用标准比较 operator 测试索引列的查询永远不能_匹配具有该列的NULL value 的行。出于同样的原因,唯一索引不会阻止NULL值;这些值根本没有在索引中表示。在列上声明NOT NULL约束可以确保索引中没有任何行,从而可以更好地进行查询优化(准确计算行数并估计是否使用索引)。

因为primary key必须能够唯一地标识 table 中的每一行,所以 single-column primary key 不能包含任何NULL值,并且 multi-column primary key 不能包含所有列中具有NULL值的任何行。

虽然 Oracle 数据库允许将NULL value 与 string 连接,但InnoDB会将此类操作的结果视为NULL

另见指数首要的关键SQL

Ø


  • .OPT 文件


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

另见MySQL 企业备份mysqlbackup 命令


  • off-page 专栏


    • 包含 variable-length 数据(例如BLOBVARCHAR)的列太长不适合B-tree页面。数据存储在溢出页面中.DYNAMIC 行格式比旧的COMPACT行格式更有效。

另请参见B-tree紧凑的行格式动态行格式溢出页面


  • OLTP

    • “Online Transaction Processing”的缩写。数据库系统或数据库应用程序,它运行具有许多事务的工作负载,具有频繁写入和读取,通常在 time 时影响少量数据。例如,航空公司预订系统或处理银行存款的应用程序。数据可以以标准化形式组织,以实现DML(insert/update/delete)效率和查询效率之间的平衡。与数据仓库对比

凭借row-level 锁定事务功能,InnoDB是 OLTP applications 中使用的 MySQL 表的理想存储引擎。

另请参见数据仓库DMLInnoDB询问行锁交易


  • 线上


    • 一种不涉及数据库停机,阻塞或受限操作的操作。通常适用于DDL。缩短限制操作周期的操作,例如快速索引创建,已经演变成 MySQL 5.6 中更广泛的在线 DDL操作。

在备份的 context 中,热备份是在线操作,热备份部分是在线操作。

另请参见DDL快速创建索引热备份在线 DDL热备份

细节因操作类型而异。在某些情况下,可以在ALTER TABLE正在进行时同时修改 table。可以在没有 table 副本或使用特殊优化类型的 table 副本的情况下执行该操作。 in-place 操作的 DML log 空间使用由innodb_online_alterlog_max_size configuration 选项控制。

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

另见DDL快速创建索引线上


  • 乐观


    • 一种为关系数据库系统指导 low-level implementation 决策的方法。关系数据库中 performance 和并发的要求意味着必须快速启动或分派操作。一致性和引用完整性的要求意味着任何操作都可能失败:transaction 可能会被回滚,DML操作可能违反约束,锁定请求可能导致死锁,网络错误可能导致超时。乐观策略是假设大多数请求或尝试都会成功的策略,因此为失败案例做准备的工作相对较少。当这个假设是 true 时,数据库几乎没有做不必要的工作;当请求失败时,必须进行额外的工作来清理和撤消更改。

    InnoDB使用乐观策略进行操作,例如锁定提交。例如,transaction 更改的数据可以在提交发生之前写入数据 files,这使得提交本身非常快,但如果回滚 transaction 则需要更多工作来撤消更改。

与乐观策略相反的是悲观的,其中系统被优化以处理不可靠且经常不成功的操作。这种方法在数据库系统中很少见,因为在选择可靠的硬件,网络和算法时要特别小心。

另请参见承诺并发DML锁定悲观参照完整性


  • 优化


    • MySQL component 根据相关的特征和数据分布确定最佳索引join order 用于查询

另请参见指数加入询问


  • 选项


    • MySQL 的 configuration 参数,存储在选项文件中或传递给命令 line。

对于适用于InnoDB表的选项,每个选项 name 都以前缀innodb_开头。

另见InnoDB选项选项文件


  • 选项文件


    • 保存 MySQL 实例的 configuration 选项的文件。传统上,在 Linux 和 Unix 上,此文件名为my.cnf,而在 Windows 上,它名为my.ini

另请参见configuration 文件my.cnfmy.ini选项


  • 溢出页面


    • 单独分配的磁盘页面包含 variable-length 列(例如BLOBVARCHAR),这些列太长不适合B-tree页面。关联的列称为off-page 列

另见B-treeoff-page 专栏

P


  • .par 文件


    • 包含分区定义的文件。 具有此扩展名的文件包含在由MySQL Enterprise Backup产品的mysqlbackup命令生成的备份中。

通过在 MySQL 5.7.6 中引入对InnoDB表的本机分区支持,不再为分区的InnoDB表创建.par files。分区MyISAM表继续在 MySQL 5.7 中使用.par files。在 MySQL 8.0 中,分区支持仅由InnoDB存储引擎提供。因此,从 MySQL 8.0 开始不再使用.par files。

另见MySQL 企业备份mysqlbackup 命令



    • 表示在磁盘(data files)和 memory(缓冲池)之间的任何一个 time 传输的数据量的单位。页面可以包含一个或多个,具体取决于每行中的数据量。如果某行不完全适合单个页面,则InnoDB _设置其他 pointer-style 数据结构,以便有关该行的信息可以存储在一个页面中。

在每个页面中放置更多数据的一种方法是使用压缩行格式。对于使用 BLOB 或大文本字段的表,紧凑行格式允许将那些大列与行的 rest 分开存储,从而减少_l开销和 memory 用于不引用这些列的查询。

InnoDB批量读取或写入_set 页面以增加 I/O 吞吐量时,它会在 time 读取或写入范围

MySQL 实例中的所有InnoDB磁盘数据结构共享相同的页面大小

另请参见缓冲池紧凑的行格式压缩行格式data files程度页面大小


  • 页面清洁


    • 一个InnoDB背景线程****从缓冲池中刷出****脏页。在 MySQL 5.6 之前,此活动由主线程执行。页面清除程序线程的数量由 MySQL 5.7.4 中引入的innodb_page_cleaners configuration 选项控制。

另请参见缓冲池脏页红晕master 线程线


  • 页面大小


    • 对于 MySQL 5.5 之前和之后的版本,每个InnoDB 页面的大小固定为 16 千字节。此 value 表示一个余额:大到足以容纳大多数行的数据,但又小到足以最小化将不需要的数据传输到 memory 的性能开销。未测试或支持其他值。

从 MySQL 5.6 开始,InnoDB 实例的页面大小可以是 4KB,8KB 或 16KB,由innodb_page_size configuration 选项控制。从 MySQL 5.7.6 开始,InnoDB还支持 32KB 和 64KB 的页面大小。对于 32KB 和 64KB 页面大小,不支持ROW_FORMAT=COMPRESSED,最大 record 大小为 16KB。

在创建 MySQL 实例时设置页面大小,之后它保持不变。相同的页面大小适用于所有InnoDB 表空间,包括系统表空间file-per-table表空间和通用表空间

较小的页面大小可以帮助使用小块大小的存储设备,特别是****_ 工作负载中的SSD设备,例如OLTP** applications。更新单个行时,将更少的数据复制到 memory,写入磁盘,重新组织,锁定等等。

另请参见disk-boundfile-per-table一般表空间OLTPSSD系统表空间表空间


  • parent table


    • 外部 key关系中的 table,用于保存从child table指向的初始列值。删除或更新 parent table 中的行的后果取决于外部 key 定义中的ON UPDATEON DELETE子句。可以依次自动删除或更新 child table 中具有相应值的行,或者可以将这些列设置为NULL,或者可以防止操作。

另见child table外国 key


  • 部分备份


    • 一个备份,包含 MySQL 数据库中的一些,或 MySQL 实例中的一些数据库。与完全备份对比。

另见备用完整备份


  • 部分指数


    • 索引仅表示列 value 的一部分,通常是 long VARCHAR value 的前 N 个字符(前缀)。

另见指数索引前缀


  • Performance Schema


    • MySQL 5.5 及更高版本中的performance_schema schema 提供了一组表,您可以查询这些表以获取有关 MySQL 服务器许多内部部件的 performance 特性的详细信息。见第 25 章,MySQL Performance Schema

另请参见INFORMATIONSCHEMAmutexrw-lock

另请参见指数优化计划稳定询问


  • 悲观

    • 一种牺牲 performance 或 concurrency 以支持安全的方法。如果大部分请求或尝试可能失败,或者请求失败的后果严重,则是适当的。 InnoDB使用所谓的悲观锁定策略,以尽量减少死锁的可能性。在 application level 中,您可以通过使用悲观策略来避免死锁,该策略一开始就获取 transaction 所需的所有锁。

许多 built-in 数据库机制使用相反的乐观方法。

另见僵局锁定乐观


  • 幻影


    • 显示在查询结果集中但不在先前查询的结果集中的行。例如,如果查询在事务中运行两次,并且在此期间,另一个 transaction 在插入新行或更新行后提交,以便它与查询的WHERE子句匹配。

这种情况称为幻像读取。防止比non-repeatable 读取更难,因为锁定第一个查询结果集中的所有行并不会阻止导致幻像出现的更改。

在不同的隔离级别中,幻象读取由可序列化读取level 阻止,并且由可重复读取一致读取读取未提交级别允许。

另请参见一致阅读隔离 levelnon-repeatable 读阅读不满意可重复阅读SERIALIZABLE交易


  • 物理


    • 一种涉及 hardware-related 方面的操作,例如磁盘块,存储页面,文件,位,磁盘读取等。通常,在 expert-level 性能调优和问题诊断期间,物理方面很重要。与逻辑对比。

另见合乎逻辑物理备份


  • 物理备份


    • 一个备份复制实际数据 files。例如,MySQL Enterprise Backup产品的mysqlbackup命令产生物理备份,因为它的输出包含可以由mysqld服务器直接使用的数据 files,从而实现更快的恢复操作。与逻辑备份对比。

另请参见备用逻辑备份MySQL 企业备份恢复


  • PITR


    • point-in-time recovery的缩写。

另见point-in-time 恢复


  • 计划稳定


    • 查询执行计划的 property,其中优化器为给定的查询每个 time 做出相同的选择,以便 performance 是一致且可预测的。

另见询问查询执行计划


  • point-in-time 恢复


    • 恢复备份的过程在特定的 date 和 time 重新创建数据库的 state。通常缩写为“PITR”。由于指定的 time 不太可能与备份的 time 完全对应,因此该技术通常需要物理备份逻辑备份的组合。例如,使用MySQL Enterprise Backup产品,您可以恢复在 time 中指定点之前所做的最后一次备份,然后从备份的 time 和 PITR time 之间重放二进制 log中的更改。

另请参见备用二进制 log逻辑备份MySQL 企业备份物理备份


  • 字首


  • 准备备份


    • 在完成应用二进制日志增量备份的所有阶段之后,由MySQL Enterprise Backup产品生成的一组备份 files。生成的 files 准备好恢复。在应用步骤之前,files 称为原始备份

另请参见二进制 log热备份增量备份MySQL 企业备份原始备份恢复


  • 首要的关键


    • 一组列 - 并且暗示,基于这组列的索引 - 可以唯一地标识 table 中的每一行。因此,它必须是不包含任何NULL值的唯一索引。

    InnoDB要求每个 table 都有这样的索引(也称为聚簇索引聚簇索引),并根据主 key 的列值组织 table 存储。

选择主 key 值时,请考虑使用任意值(****key ),而不是依赖于从其他源(anatural key **)派生的值。

另请参见聚集索引指数自然 key合成 key


  • 处理


    • 执行程序的实例。操作系统在多个 running 进程之间切换,允许一定程度的并发。在大多数操作系统上,进程可以包含共享资源的多个执行**线程。线程之间的 Context-switching 比进程之间的等效切换更快。

另见并发线


  • pseudo-record


    • 索引中的人工 record,用于锁定 key 值或当前不存在的范围。

另见infimum record锁定supremum record


  • 并行线程


    • POSIX 线程标准,它定义了用于在 Unix 和 Linux 系统上进行 threading 和锁定操作的 API。在 Unix 和 Linux 系统上,InnoDB将此 implementation 用于互斥体

另见mutex


  • 清除


    • 由一个或多个单独的后台线程(由innodb_purge_threads控制)执行的一种垃圾收集,它按周期性计划运行。清除分析和处理历史列表中撤消 log页面,目的是删除标记为删除的聚簇和二级索引记录(通过之前的删除 statements),并且不再需要MVCC * *或回滚**。清除后,清除会从历史列表中释放撤消 log 页面。

另请参见历史清单MVCC回滚撤消 log


  • 清除缓冲


    • 更改缓冲区中存储由DELETE操作产生的二级索引页面的更改而不是立即写入更改的技术,以便可以执行物理写入以最小化随机 I/O。 (因为删除操作是 two-step process,此操作会缓冲通常清除以前标记为 deletion.)的索引 record 的写入。它是更改缓冲的类型之一;其他是插入缓冲删除缓冲

另请参见改变缓冲区改变缓冲删除缓冲insert 缓冲区insert 缓冲


  • 清除滞后

另见历史清单清除


  • 清除线程


    • InnoDB process 中的线程专用于执行定期清除操作。在 MySQL 5.6 及更高版本中,innodb_purge_threads configuration 选项启用了多个清除线程。

另见清除线

Q


  • 询问


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

由于历史原因,有时对 statements 的内部处理的讨论在更广泛的意义上使用“查询”,包括其他类型的 MySQL statements,例如DDLDML statements。

另请参见DDLDML指数加入SQL


  • 查询执行计划


    • 优化器关于如何最有效地执行查询的决策集,包括索引或要使用的索引,以及加入表的 order.计划稳定性涉及针对给定查询一致地做出的相同选择。

另请参见指数加入计划稳定询问


  • 查询 log


  • 停顿


    • 为了减少数据库活动的数量,通常是为了准备诸如ALTER TABLE备份关闭之类的操作。可能会或可能不会涉及尽可能多的冲洗,所以InnoDB不会继续做背景 I/O。

在 MySQL 5.6 及更高版本中,语法FLUSH TABLES ... FOR EXPORT将一些数据写入磁盘以用于InnoDB表,这使得通过复制数据 files 更容易备份这些表。

另请参见备用红晕InnoDB关掉

[R


  • R-tree


    • 用于空间索引 multi-dimensional 数据的树数据结构,例如地理坐标,矩形或多边形。

另见B-tree


  • 袭击


    • “Redundant Array of Inexpensive Drives”的缩写。跨多个驱动器传播 I/O 操作可以在硬件 level 上实现更高的并发性,并提高 low-level 写操作的效率,否则将按顺序执行。

另见并发


  • 随机潜水


    • 一种快速估算列中不同值的数量的技术(列的基数**)。 InnoDB samples 页面随机索引并使用该数据估计不同值的数量。

另见基数


  • 原始备份


    • 在应用二进制 log和任何增量备份中反映的更改之前,由MySQL Enterprise Backup产品生成的初始备份 files 集。在这个阶段,files 还没有准备好恢复。应用这些更改后,files 称为准备备份

另请参见二进制 log热备份ibbackuplogfile增量备份MySQL 企业备份准备备份恢复


  • 阅读提交

    • 隔离 level使用锁定策略,为了_ performance 而放松交易之间的一些保护。 Transactions 无法查看来自其他 transactions 的未提交数据,但是在当前 transaction 启动后,它们可以看到另一个 transaction 提交的数据。因此,transaction 永远不会看到任何不良数据,但它确实看到的数据可能在某种程度上取决于其他 transactions 的时间。

当具有此隔离 level 的 transaction 执行UPDATE ... WHEREDELETE ... WHERE操作时,其他 transactions 可能必须等待。 transaction 可以执行SELECT ... FOR UPDATELOCK IN SHARE MODE操作,而无需等待其他 transactions。

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

另请参见隔离 level锁定可重复阅读SERIALIZABLE交易


  • 读现象


    • 现象如脏读non-repeatable 读幻像读取,当 transaction 读取另一个 transaction 已修改的数据时可能会发生这种情况。

另见脏读non-repeatable 读幻影


  • 阅读不满意


    • isolation level在 transactions 之间提供最少量的保护。查询采用锁定策略,允许它们在通常等待另一个 transaction 的情况下继续。但是,这种额外的性能是以不太可靠的结果为代价的,包括其他 transactions 已经更改但尚未提交的数据(称为脏读)。请谨慎使用此隔离 level,并注意结果可能不一致或可重现,具体取决于其他 transactions 在同一时间执行的操作。通常,具有此隔离 level 的 transactions 仅执行查询,而不执行 insert,update 或 delete 操作。

另请参见脏读隔离 level锁定交易


  • 阅读视图


    • MVCC机制InnoDB使用的内部快照。某些事务,取决于它们的隔离 level,查看 timens(或在某些情况下,语句)time 时的数据值。使用读取视图的隔离级别是REPEATABLE READREAD COMMITTEDREAD UNCOMMITTED

另请参见隔离 levelMVCC阅读提交阅读不满意可重复阅读交易


  • read-ahead


    • 一种 I/O 请求,它将页面的组**(整个范围)异步预取到缓冲池中,预计很快就会需要这些页面。线性 read-ahead 技术基于前一范围中的页面的访问模式预取一个范围的所有页面。一旦来自相同范围的特定数量的页面在缓冲池中,随机 read-ahead 技术就预取所有页面。随机 read-ahead 不是 MySQL 5.5 的一部分,但是在innodb_random_read_ahead configuration 选项的控制下,MySQL 5.6 中的 re-introduced。

另见缓冲池程度

另见non-locking 读阅读视图交易


  • record 锁


    • 索引 record 上的。对于 example,SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE;阻止任何其他 transaction 插入,更新或删除t.c1的 value 为 10 的行。与gap locknext-key lock对比。

另见差距锁定next-key 锁


  • 重做


    • DML statements 对InnoDB表进行更改时,以记录为单位的数据记录在redo log中。它在崩溃恢复期间用于纠正由不完整的交易写的数据。 ever-increasing**LSN ** value 表示通过重做 log 的重做数据的累积量。

另请参见崩溃恢复DMLLSN重做 log交易


  • 重做 log


    • 崩溃恢复期间使用的 disk-based 数据结构,用于纠正由不完整的事务写入的数据。在正常操作期间,它编码更改InnoDB table 数据的请求,这些数据来自 SQL statements 或 low-level API calls 通过 NoSQL 接口。在意外关闭之前未完成更新data files的修改会自动重播。

redo log 在物理上表示为一组 files,通常名为ib_logfile0ib_logfile1。 redo log 中的数据根据受影响的记录进行编码;这些数据统称为重做。数据通过重做日志的传递由 ever-increasing**LSN ** value 表示。在 MySQL 5.6.3 中,redo log 最大大小的原始 4GB 限制被提升到 512GB。

redo log 的磁盘布局受 configuration 选项innodblog_file_sizeinnodbloggroup_home_dir和(很少)innodblogfiles_ingroup的影响。重做 log 操作的 performance 也受log buffer的影响,该缓冲区由innodblog_buffer_size configuration 选项控制。

另请参见崩溃恢复data filesiblogfilelog 缓冲区LSN重做关掉交易


  • redo log 归档


    • InnoDB feature,在启用时,将 redo log 记录顺序写入归档文件,以避免在备份操作正在进行时备份实用程序无法跟上 redo log 生成的情况时可能发生的数据丢失。有关更多信息,请参阅重做 LogLog 归档

另见重做 log


  • 冗余行格式


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

有关更多信息,请参阅第 14.11 节,“InnoDB 行格式”

另见紧凑的行格式动态行格式行格式


  • 参照完整性


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

另请参见FOREIGN KEY 约束NOT NULL 约束独特的约束


  • 相关


    • 现代数据库系统的一个重要方面。数据库服务器编码并强制执行 one-to-one,one-to-many,many-to-one 和唯一性等关系。例如,一个人在地址数据库中可能有零个,一个或多个电话数字;一个电话号码可能与几个家庭成员相关联。在金融数据库中,可能要求一个人只有一个纳税人 ID,并且任何纳税人 ID 只能与一个人相关联。

数据库服务器可以使用这些关系来防止插入错误数据,并找到查找信息的有效方法。例如,如果声明 value 是唯一的,则服务器可以在找到第一个 match 后立即停止搜索,并且它可以拒绝尝试插入同一 value 的第二个副本。

在数据库 level 中,这些关系通过 SQL features 表示,例如 table 中的,唯一和NOT NULL约束外键和不同类型的连接操作。复杂关系通常涉及在多个 table 之间分割数据。通常,数据被标准化,因此 one-to-many 关系中的重复值仅存储一次。

在数学 context 中,数据库中的关系来自集合论。例如,WHERE子句的ORAND operators 表示 union 和 intersection 的概念。

另请参见约束外国 key标准化


  • 关联


    • full-text search feature 中,一个数字表示搜索 string 与FULLTEXT 索引中的数据之间的相似性。例如,当您搜索单个单词时,该单词通常与文本中出现多次的行相比,而不是仅出现一次的行。

另见full-text 搜索FULLTEXT 指数


  • 可重复阅读


    • InnoDB的默认隔离 level。它可以防止被查询的任何行被其他事务更改,从而阻止non-repeatable 读取而不是幻像读取。它使用适度严格的锁定策略,以便 transaction 中的所有查询都可以查看来自同一快照的数据,即 transaction time 时的数据。

当具有此隔离 level 的 transaction 执行UPDATE ... WHEREDELETE ... WHERESELECT ... FOR UPDATELOCK IN SHARE MODE操作时,其他 transactions 可能必须等待。

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

另请参见一致阅读隔离 level锁定幻影交易


  • 剧目


  • 复制


    • 将更改从master 数据库发送到一个或多个slave 数据库的做法,以便所有数据库都具有相同的数据。此技术具有广泛的用途,例如 load-balancing,可实现更好的可扩展性,灾难恢复以及测试软件升级和配置更改。可以通过名为row-based replicationstatement-based replication的方法在数据库之间发送更改。

另请参见master 服务器row-based 复制奴隶服务器statement-based 复制


  • 恢复


    • MySQL Enterprise Backup产品中的一组备份 files 放在适当位置以供 MySQL 使用的 process。可以执行此操作以修复损坏的数据库,_返回 time 中的某个早期点,或者(在replication context 中)设置新的slave 数据库。在MySQL Enterprise Backup产品中,此操作由mysqlbackup命令的copy-back选项执行。

另请参见热备份MySQL 企业备份mysqlbackup 命令准备备份复制奴隶服务器


  • 回滚


    • 一个SQL语句结束事务,撤消 transaction 所做的任何更改。它与commit相反,它使 transaction 中所做的任何更改成为永久性的。

默认情况下,MySQL 使用autocommit设置,该设置会在每个 SQL 语句后自动发出提交。您必须先更改此设置,然后才能使用回滚技术。

另请参见自动提交承诺SQL交易


  • 回滚段


    • 包含undo logs的存储区域。回滚段传统上驻留在系统表空间中。从 MySQL 5.6 开始,回滚段可以驻留在撤消表空间中。从 MySQL 5.7 开始,回滚段也分配给 global 临时表空间。

另见系统表空间撤消 log撤消表空间



    • 逻辑数据结构由一组定义。一组行组成。在InnoDBdata files 中,每个可以包含一行或多行。

虽然InnoDB使用术语行格式来与 MySQL 语法保持一致,但行格式是每个 table 的 property 并适用于该 table 中的所有行。

另请参见data files行格式


  • 行格式


    • InnoDB 的磁盘存储格式。随着InnoDB获得压缩等新功能,引入了新的行格式以支持最终提高存储效率和性能。

InnoDB table 的行格式由ROW_FORMAT选项或innodb_default_row_format configuration 选项(在 MySQL 5.7.9 中引入)指定。行格式包括REDUNDANTCOMPACTCOMPRESSEDDYNAMIC。要查看InnoDB table 的行格式,请在INFORMATIONSCHEMA中发出显示 TABLE 状态语句或查询InnoDB table 元数据。

另请参见紧凑的行格式压缩行格式压缩动态行格式冗余行格式


  • 行锁


    • 一个,防止另一个事务以不兼容的方式访问行。同一 table 中的其他行可以由其他 transactions 自由写入。这是由InnoDB表上的DML操作完成的锁定的类型。

MyISAM 数据使用的表锁对比,或InnoDB表上的DDL操作对****DDL **无法完成;这些锁阻止对 table 的并发访问。

另请参见DDLDMLInnoDB锁定在线 DDLtable 锁交易


  • row-based 复制


    • 复制的一种形式,其中 events 从主服务器传播,指定如何更改从属服务器上的各个行。可以安全地用于innodb_autoinc_lock_mode选项的所有设置。

另请参见auto-increment 锁定innodb_autoinc_lock_modemaster 服务器复制奴隶服务器statement-based 复制


  • row-level 锁定


    • 用于InnoDB表的锁定机制,依赖于行锁而不是表锁。多个事务可以同时修改相同的 table。只有当两个 transactions 尝试修改同一行时,其中一个 transactions 才会等待另一个完成(并释放其行锁)。

另请参见InnoDB锁定行锁table 锁交易


  • rw-lock


    • InnoDB object 用于表示并强制 shared-access 按照某些规则将锁定到内部 in-memory 数据结构。与互斥体对比,InnoDB用于表示和强制执行对内部 in-memory 数据结构的独占访问。互斥锁和 rw-locks 统称为锁存器

    rw-lock类型包括s-locks(共享锁),x-locks(独占锁)和sx-locks(shared-exclusive 锁)。

  • s-lock提供对 common 资源的读访问权。

  • x-lock提供对 common 资源的写访问权限,同时不允许其他线程进行不一致的读取。

  • sx-lock提供对 common 资源的写访问权限,同时允许其他线程进行不一致的读取。 sx-locks在 MySQL 5.7 中引入,以优化并发性并提高 read-write 工作负载的可伸缩性。

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

SSXX
S兼容兼容冲突
SX兼容冲突冲突
X冲突冲突冲突

另请参见mutexPerformance Schema

小号


  • 保存点


    • 保存点有助于实现嵌套的事务。它们可用于为作为较大 transaction 的一部分的表的操作提供范围。例如,在预订系统中安排旅行可能涉及预订几个不同的航班;如果没有所需的航班,您可以**回滚预订一条航线所涉及的更改,而不会回滚成功预订的早期航班。

另见回滚交易


  • 可扩展性


    • 能够添加更多工作并向系统发出更多同时请求,而不会因超出系统容量限制而导致性能突然下降。软件架构,硬件配置,应用程序编码和工作负载类型都在可伸缩性中起作用。当系统达到其最大容量时,用于提高可扩展性的流行技术是扩展(增加现有硬件或软件的容量)和扩展(添加新服务器和更多 MySQL 实例)。通常与可用性配对,作为 large-scale 部署的关键方面。

另见可用性向外扩展放大


  • 向外扩展


    • 通过添加新服务器和更多 MySQL 实例来增加可伸缩性的技术。例如,设置复制,NDB Cluster,连接池或在服务器组之间传播工作的其他 features。与放大对比

另见可扩展性放大

另见可扩展性向外扩展


  • schema


    • 从概念上讲,schema 是一组相互关联的数据库对象,例如表,table 列,列的数据类型,索引,外键等。这些 object 通过 SQL 语法连接,因为列构成表,外键引用表和列,依此类推。理想情况下,它们也是逻辑连接的,作为统一的应用程序或灵活的 framework 的一部分一起工作。例如,INFORMATIONSCHEMAperformanceschema数据库在其名称中使用“schema”来强调它们包含的表和列之间的紧密关系。

在 MySQL 中,物理上,schema数据库同义。您可以在 MySQL SQL 语法中使用关键字SCHEMA而不是DATABASE替换,例如使用CREATE SCHEMA而不是CREATE DATABASE替换 example。

其他一些数据库产品也有所区别。例如,在 Oracle 数据库产品中,schema仅表示数据库的一部分:表和其他 objects 由单个用户拥有。

另见数据库INFORMATIONSCHEMAPerformance Schema


  • 搜索索引


    • 在 MySQL 中,full-text search查询使用一种特殊的索引,即FULLTEXT 索引。在 MySQL 5.6.4 及以上,InnoDBMyISAM表都支持FULLTEXT索引;以前,这些索引仅适用于MyISAM表。

另见full-text 搜索FULLTEXT 指数


  • 二级指数


    • 一种InnoDB 索引,表示 table 列的子集。 InnoDB table 可以包含零个,一个或多个二级索引。 (与每个InnoDB table 所需的聚集索引对比,并且存储所有 table columns.)的数据

辅助索引可用于满足仅需要来自索引列的值的查询。对于更复杂的查询,它可用于标识 table 中的相关行,然后使用聚簇索引通过查找检索这些行。

复制和删除二级索引传统上涉及复制InnoDB table 中所有数据的大量开销。 快速索引创建 feature 使InnoDBDROP INDEX statements 对于InnoDB二级索引更快。

另见聚集索引快速创建索引指数


  • 分割

    • InnoDB 表空间内的一个分区。如果表空间类似于目录,则段类似于该目录中的 files。细分可以增长。可以创建新细分。

例如,在file-per-table表空间中,table 数据位于一个段中,每个关联的索引位于其自己的段中。 系统表空间包含许多不同的段,因为它可以容纳许多表及其相关索引。在 MySQL 8.0 之前,系统表空间还包括一个或多个用于撤消日志回滚段

插入和删除数据时,段会增长和缩小。当一个片段需要更多空间时,它会在 time 时延长一个范围(1 兆字节)。类似地,当不再需要该范围内的所有数据时,段释放一个范围的空间。

另请参见程度file-per-table回滚段系统表空间表空间撤消 log


  • 选择性


    • 数据分布的 property,列中不同值的数量(其基数)除以 table 中的记录数。高选择性意味着列值相对独特,并且可以通过索引有效地检索。如果您(或查询优化器)可以预测WHERE子句中的测试仅匹配 table 中的少量(或比例)行,则整体查询如果首先评估该测试,则往往是有效的,使用索引。

另见基数询问


  • semi-consistent 阅读


    • 一种用于UPDATE statements 的读操作,它是READ COMMITTED一致读的组合。当UPDATE语句检查已经锁定的行时,InnoDB将最新提交的 version 返回给 MySQL,以便 MySQL 可以确定该行是否与UPDATEWHERE条件匹配。如果行匹配(必须更新),MySQL 再次读取该行,并且此 time InnoDB要么锁定它,要么等待锁定它。这种类型的读操作只能在 transaction 具有 READ COMMITTED**isolation level **或启用innodb_locks_unsafe_for_binlog选项时发生。在 MySQL 8.0 中删除了innodb_locks_unsafe_for_binlog

另见一致阅读隔离 level阅读提交


  • SERIALIZABLE


    • isolation level使用最保守的锁定策略,以防止任何其他Transactions插入或更改此 transaction 读取的数据,直到完成为止。这样,同一个查询可以在 transaction 中反复运行,并确保每次 time 都检索相同的结果集。自当前 transaction 开始以来,任何尝试更改由另一个 transaction 提交的数据的尝试都会导致当前 transaction 等待。

这是 SQL 标准指定的默认隔离 level。在实践中,很少需要这种严格程度,因此InnoDB的默认隔离 level 是下一个最严格的,REPEATABLE READ

另请参见一致阅读隔离 level锁定可重复阅读交易


  • 服务器


    • 一种程序,它持续运行,等待接收来自另一个程序(客户端)的请求并采取行动。因为通常整个计算机专用于运行一个或多个服务器程序(例如数据库服务器,web 服务器,应用程序服务器或这些服务器的某些组合),所以术语服务器也可以指代计算机运行服务器软件。

另见客户mysqld


  • 共享锁


    • 一种,允许其他事务读取锁定的 object,并获取其上的其他共享锁,但不写入它。与独家锁相反。

另见独家锁交易


  • 共享表空间


    • 另一种引用系统表空间通用表空间的方法。 MySQL 5.7 中引入了一般表空间。多个 table 可以驻留在共享表空间中。只有一个 table 可以驻留在 file-per-table 表空间中。

另见一般表空间系统表空间


  • 尖锐的检查站


    • 刷新的所有缓冲池页面的 process,其重做条目包含在redo log的某些部分中。在InnoDB重新使用 log 文件的一部分之前发生; log files 以循环方式使用。通常发生 write-intensive 工作负载

另请参见脏页红晕重做 log工作量


  • 关掉


    • 停止 MySQL 服务器的 process。默认情况下,此 process 清除InnoDB表的操作,因此InnoDB可以关闭,但可以快速启动。如果跳过清理操作,则关闭快速**,但必须在下次重新启动时执行清理。

InnoDB的关闭模式由innodb_fast_shutdown选项控制。

另请参见快速关机InnoDB慢关机启动


  • 奴隶服务器


    • 经常缩短为“奴隶”。 复制方案中的数据库服务器机器,它接收来自另一个服务器(master)的更改并应用这些相同的更改。因此它保持与 master 相同的内容,尽管它可能会落后一些。

在 MySQL 中,从属服务器通常用于灾难恢复,以取代失败的 master 服务器。它们还常用于测试软件升级和新设置,以确保数据库配置更改不会导致 performance 或 Reliability 的问题。

从属服务器通常具有高工作负载,因为它们处理从 master 中继的所有DML(写入)操作以及用户查询。为确保从服务器能够足够快地从 master 应用更改,它们通常具有快速的 I/O 设备和足够的 CPU 和 memory 来运行同一从属服务器上的多个数据库实例。例如,master 服务器可能使用硬盘存储,而从服务器使用SSD

另请参见DMLmaster 服务器复制服务器SSD


  • 慢查询 log


    • 一种log,用于 MySQL 服务器处理的 SQL statements 的 performance 调优。 log 信息存储在文件中。您必须启用此 feature 才能使用它。您可以控制记录哪些类别的“慢”SQL 语句。有关更多信息,请参阅第 5.4.5 节,“慢查询 Log”

另见一般查询 loglog


  • 慢关机


    • 一种关闭,在完成之前执行额外的InnoDB刷新操作。又称干净关机。由 configuration 参数innodb_fast_shutdown=0或命令SET GLOBAL innodb_fast_shutdown=0;指定。虽然关闭本身可能需要更长时间,但 time 将在后续启动时保存。

另见干净关机快速关机关掉


  • 快照


    • 特定 time 时的数据表示,即使其他事务****的更改也保持不变。由某些隔离级别使用以允许一致读取

另请参见承诺一致阅读隔离 level交易


  • 排序缓冲区


    • 用于在创建InnoDB索引期间对数据进行排序的缓冲区。使用innodb_sort_buffer_size configuration 选项配置排序缓冲区大小。

  • 空间 ID


    • 用于唯一标识 MySQL 实例中的InnoDB 表空间的标识符.系统表空间的空间 ID 始终为零;这个相同的 ID 适用于系统表空间内或一般表空间内的所有表。每个file-per-table表空间和通用表空间都有自己的空间 ID。

在 MySQL 5.6 之前,这个硬编码的 value 在 MySQL 实例之间移动InnoDB tablespace files 时遇到了困难。从 MySQL 5.6 开始,您可以使用涉及 statements FLUSH TABLES ... FOR EXPORTALTER TABLE ... DISCARD TABLESPACEALTER TABLE ... IMPORT TABLESPACEtransportable tablespace feature 在实例之间复制表空间 files。调整空间 ID 所需的信息将在**.cfg 文件**中传送,您将其与表空间一起复制。有关详细信息,请参阅部分 14.6.3.7,“将表空间复制到另一个实例”

另请参见.cfg 文件file-per-table一般表空间.ibd 文件系统表空间表空间可移动的表空间


  • 稀疏文件


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

另见打孔透明页面压缩



    • 一种等待操作,持续测试资源是否可用。此技术用于通常仅在短时间内保持的资源,其中在“忙循环”中等待使线程进入休眠状态并执行 context 切换更有效。如果资源在短时间内不可用,则自旋循环停止并使用另一种等待技术。

另请参见mutex等待

另请参见DDLDML询问复制


  • SSD

    • “solid-state drive”的缩写。一种具有与传统硬盘驱动器不同的 performance 特性的存储设备(HDD):存储容量更小,随机读取速度更快,没有移动部件,并且有许多考虑因素会影响 writeperformance。其性能特征可以影响disk-bound工作负载的吞吐量。

另见disk-bound硬盘

另见关掉


  • statement-based 复制


    • 复制的一种形式,其中 SQL statements 从主服务器发送并在从服务器上重放。它需要注意innodb_autoinc_lock_mode选项的设置,以避免auto-increment 锁定的潜在时序问题。

另请参见auto-increment 锁定innodb_autoinc_lock_modemaster 服务器复制row-based 复制奴隶服务器


  • 统计


    • 与每个InnoDB 索引相关的估计值,用于构建有效的查询执行计划。主要值是基数(不同值的数量)和 table 行或索引条目的总数。 table 的统计信息表示其primary key索引中的数据。 二级索引的统计信息表示该索引所涵盖的行。

估计值而不是精确计算,因为在任何 moment 中,不同的transactions可以插入和删除同一 table 中的行。为了防止频繁重新计算值,可以启用持久统计,其中值存储在InnoDB系统表中,并且仅在发出分析 TABLE语句时刷新。

通过innodb_stats_method configuration 选项计算统计信息时,可以控制NULL值的处理方式。

其他类型的统计信息可通过INFORMATIONSCHEMAPERFORMANCESCHEMA表用于数据库对象和数据库活动。

另请参见基数指数INFORMATIONSCHEMA空值Performance Schema持久统计首要的关键查询执行计划二级指数交易


  • 词干


    • 能够根据 common 根词搜索单词的不同变体,例如单数和复数,或过去,现在和将来的动词时态。此 feature 目前在MyISAM full-text search feature 中受支持,但在InnoDB表的FULLTEXT 索引中不受支持。

另见full-text 搜索FULLTEXT 指数


  • 停用词


    • FULLTEXT 索引中,一个被认为是 common 或者足够简单的单词,它从搜索索引中被省略并在搜索查询中被忽略。不同的 configuration 设置控制InnoDBMyISAM表的停用词处理。有关详细信息,请参阅第 12.9.4 节,“Full-Text 停用词”

另见FULLTEXT 指数搜索索引


  • 存储引擎


    • MySQL 数据库的一个组件,用于执行存储,更新和查询数据的 low-level 工作。在 MySQL 5.5 及更高版本中,InnoDB是新表的默认存储引擎,取代了MyISAM。设计不同的存储引擎时,在诸如存储器使用率与磁盘使用率,读取速度与写入速度以及速度与鲁棒性之间的因素之间存在不同的权衡。每个存储引擎都管理特定的表,因此我们引用InnoDB表,MyISAM 数据表等。

MySQL Enterprise Backup产品针对备份InnoDB表进行了优化。它还可以备份MyISAM和其他存储引擎处理的表。

另见InnoDBMySQL 企业备份table 类型


  • 存储生成的列


    • 一列,其值是根据列定义中包含的表达式计算的。插入或更新行时,将评估和存储列值。存储的生成列需要存储空间并且可以编制索引。

虚拟生成列对比。

另见基本栏目生成列虚拟生成列


  • 存储 object


    • 存储的程序或视图。

  • 存储程序


    • 存储的例程(过程或 function),触发器或 Event Scheduler event。

  • 存储例程


    • 存储过程或 function。

  • 严格模式


    • innodb_strict_mode选项控制的设置的常规 name。启用此设置会导致某些通常被视为警告的情况被视为错误。例如,与文件格式行格式相关的某些选项的无效组合(通常会产生警告并且_ =使用默认值)现在会导致CREATE TABLE操作失败。 MySQL 5.7 默认启用innodb_strict_mode

MySQL 也有一种称为严格模式的东西。见第 5.1.10 节,“服务器 SQL 模式”

另见文件格式innodb_strict_mode行格式


  • 子表

    • 在表示缓冲池的列表结构中,相对较旧且相对较新的页面由列表的不同部分表示。一组参数控制这些部分的大小以及新旧页面之间的分界点。

另请参见缓冲池赶出名单LRU


  • supremum record


    • 索引中的pseudo-record,表示该索引中最大值之上的间隙。如果 transaction 具有SELECT ... FROM ... WHERE col > 10 FOR UPDATE;之类的语句,并且列中最大的 value 为 20,则它是对 supremum record 的锁定,阻止其他 transactions 插入更大的值,如 50,100 等。

另见间隙infimum recordpseudo-record


  • 代理 key


    • synthetic key的同义词 name。

另见合成 key


  • 合成 key


    • 索引列,通常是primary key,其中值是任意分配的。通常使用auto-increment列完成。通过将 value 视为完全任意的,您可以避免过度限制的规则和错误的 application 假设。例如,如果员工被批准招聘但从未实际加入,则表示员工数字的数字序列可能会有间隙。或者员工编号 100 可能会比雇员编号 500 更晚雇用 date,如果他们离开公司然后重新加入。数值也会产生较短的可预测长度值。例如,存储数字代码意味着“道路”,“大道”,“高速公路”等等比重复那些 strings 更多 space-efficient。

又称代理 key。与自然 key对比。

另请参见auto-increment自然 key首要的关键代理 key


  • 系统表空间


    • 包含InnoDB -related objects(InnoDB 数据字典)元数据的一个或多个数据 files(ibdata files),以及更改缓冲区的存储区域,doublewrite buffer ,可能撤消日志。如果在系统表空间中创建表而不是file-per-table通用表空间,它还可能包含InnoDB表的 table 和索引数据。系统表空间中的数据和元数据适用于 MySQL实例中的所有数据库

在 MySQL 5.6.7 之前,默认是将所有InnoDB表和索引保留在系统表空间内,这通常会导致此文件变得非常大。由于系统表空间永远不会缩小,因此如果加载并删除大量临时数据,则可能会出现存储问题。在 MySQL 5.7 中,默认为file-per-table模式,其中每个 table 及其相关索引都存储在单独的**.ibd 文件中**。此默认设置使得更容易使用依赖于Barracuda文件格式的InnoDB features,例如 table compressionoff-page columns的高效存储和大型索引 key 前缀(innodb_large_prefix)。

innodb_undotablespaces选项定义撤消日志的撤消表空间数。

将所有 table 数据保存在系统表空间或单独的.ibd files 中通常会影响存储管理。 MySQL Enterprise Backup产品可能会备份一小组大 files 或许多较小的 files。在具有数千个表的系统上,处理数千个.ibd files 的文件系统操作可能会导致瓶颈。

InnoDB在 MySQL 5.7.6 中引入了一般表空间,它们也由.ibd files 表示。常规表空间是使用创建 TABLESPACE语法创建的共享表空间。它们可以在 MySQL 数据目录之外创建,能够保存多个表,并支持所有行格式的表。

另请参见梭子鱼改变缓冲区压缩数据字典数据库双写缓冲区动态行格式file-per-table一般表空间.ibd 文件ibdata 文件innodb_file_pertableMySQL 企业备份off-page 专栏表空间撤消 log

Ť


  • .TRG 文件


    • 包含触发器参数的文件。 具有此扩展名的文件始终包含在由MySQL Enterprise Backup产品的mysqlbackup命令生成的备份中。

另见MySQL 企业备份mysqlbackup 命令.TRN 文件


  • .TRN 文件


    • 包含触发命名空间信息的文件。 具有此扩展名的文件始终包含在由MySQL Enterprise Backup产品的mysqlbackup命令生成的备份中。

另见MySQL 企业备份mysqlbackup 命令.TRG 文件



    • 每个 MySQL table 都与特定的存储引擎相关联.InnoDB 表具有特定的物理逻辑特性,这些特性会影响性能,可扩展性备份,管理和 application 开发。

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

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

  • 一个file-per-table表空间,由一个**.ibd 文件**组成。

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

    .ibd data files 包含 table 和index数据。

    在 file-per-table 表空间中创建的InnoDB表可以使用Barracuda文件格式,而 Barracuda 表可以使用DYNAMICCOMPRESSED行格式。这些行格式启用InnoDB features,例如compressionoff-page 列的高效存储,以及大索引 key 前缀(请参阅innodb_large_prefix)。无论innodb_file_format设置如何,常规表空间都支持所有行格式。

至于 MySQL 5.7.5,系统表空间内的InnoDB表必须使用Antelope文件格式,以便与 MySQL 5.1 及更早版本向后兼容。 Antelope文件格式支持COMPACTREDUNDANT行格式。系统表空间支持从 MySQL 5.7.6 开始使用DYNAMIC行格式的表。

InnoDB table 的被组织成一个称为聚集索引的索引结构,条目根据 table 的primary key列排序。数据访问针对对主 key 列进行筛选和排序的查询进行了优化,每个索引都包含每个条目的关联主 key 列的副本。修改任何主 key 列的值是一项昂贵的操作。因此,InnoDB table 设计的一个重要方面是选择一个主 key,其中包含在最重要的查询中使用的列,并保持主 key 简短,很少更改值。

另请参见羚羊备用梭子鱼聚集索引紧凑的行格式压缩行格式压缩动态行格式快速创建索引file-per-table.ibd 文件指数off-page 专栏首要的关键冗余行格式系统表空间表空间


  • table 锁


    • 一个阻止任何其他事务访问 table 的锁。 InnoDB通过使用诸如在线 DDL行锁一致读取等技术来处理DML statements 和查询,努力使这种锁不必要。您可以使用LOCK TABLE语句通过 SQL 创建这样的锁;从其他数据库系统或 MySQL 存储引擎迁移的其中一个步骤是在可行的情况下删除此类语句。

另请参见一致阅读DML锁定在线 DDL询问行锁交易

另见InnoDB存储引擎


  • 表空间


    • 一个数据文件,可以保存一个或多个InnoDB 和相关索引的数据。

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

MySQL 5.6 及更高版本中默认启用的innodb_file_pertable选项允许在自己的表空间中创建表。 File-per-table 表空间支持 features,例如off-page 列,table 压缩和可传输表空间的高效存储。有关详细信息,请参阅第 14.6.3.2 节,“File-Per-Table 表空间”

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

MySQL NDB Cluster 还将其表分组到表空间中。有关详细信息,请参阅Section 21.5.13.1,“NDB Cluster Disk Data Objects”

另请参见压缩行格式数据字典data filesfile-per-table一般表空间指数innodb_file_pertable系统表空间


  • 临时表


    • A table,其数据不需要是真正永久的。例如,临时表可以用作复杂计算或转换中的中间结果的存储区域;崩溃后不需要恢复这些中间数据。数据库产品可以采用各种快捷方式来改善临时表上操作的性能,通过不太谨慎地将数据写入磁盘以及其他措施来保护重启后的数据。

有时,数据本身会在 set time 时自动删除,例如 transaction ends 或 session ends 时。对于某些数据库产品,table 本身也会自动删除。

另见


  • 临时表空间

    • MySQL 5.7 中引入了 non-compressed InnoDB 临时表和相关 objects 的表空间。 innodb_temp_data_file_path configuration 文件选项定义临时表空间数据 files 的相对路径,name,大小和属性。如果未指定innodb_temp_data_file_path,则默认行为是在数据目录中创建名为ibtmp1的单个 auto-extending 12MB 数据文件。在每个服务器启动时重新创建临时表空间,并接收动态生成的空间 ID。临时表空间不能驻留在原始设备上。如果无法创建临时表空间,则拒绝启动。

临时表空间在正常关闭或中止初始化时被删除。发生崩溃时,不会删除临时表空间。在这种情况下,数据库管理员可以手动删除临时表空间,也可以使用相同的 configuration 重新启动服务器,从而删除并重新创建临时表空间。

另见临时表


  • 文字集


    • FULLTEXT 索引中包含的列集。

另见FULLTEXT 指数


  • 线


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

另请参见并发master 线程处理并行线程


  • 撕裂的页面


    • 由于 I/O 设备配置和硬件故障的组合可能发生的错误情况。如果数据以小于InnoDB 页面大小(默认情况下为 16KB)的块写出,则写入时硬件故障可能导致只有部分页面存储到磁盘。 InnoDBdoublewrite 缓冲区防止这种可能性。

另见双写缓冲区


  • TPS


    • transactions per second”的缩写,是有时在基准测试中使用的度量单位。它的 value 取决于特定基准测试所代表的工作负载,以及您控制的因素,例如硬件容量和数据库配置。

另见交易工作量


  • 交易


    • Transactions 是原子工作单位,可以承诺回滚。当 transaction 对数据库进行多次更改时,要么在提交 transaction 时所有更改都成功,要么在回滚 transaction 时撤消所有更改。

InnoDB实现的数据库 transactions 具有 properties,它们由首字母缩写词ACID统称为原子性,一致性,隔离性和持久性。

另请参见承诺隔离 level回滚


  • transaction ID


    • 与每个相关联的内部字段。该字段由插入UPDATE删除操作物理地更改为 record**_ transaction **已锁定该行。

另见隐式行锁交易

另见file-per-table打孔稀疏文件

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

如果被截断的 table 包含引用另一个 table 的外键,则截断操作使用较慢的操作方法,在 time 删除一行,以便可以根据需要删除引用的 table 中的相应行,任何ON DELETE CASCADE子句。 (MySQL 5.5 及更高版本不允许这种较慢形式的 truncate,而_如果涉及外键则返回错误。在这种情况下,请改用DELETE语句。

另请参见DDL下降外国 key回滚


  • 元组


    • 指定有序元素集的技术术语。这是一个抽象的概念,用于数据库理论的正式讨论。在数据库字段中,tuples 通常由 table 行的列表示。它们也可以由查询的结果 sets 表示,例如,仅检索 table 的某些列的查询或连接表中的列。

另见光标


  • two-phase 提交


    • 作为分布式事务的一部分的操作,在XA规范下。 (有时缩写为 2PC.)当多个数据库参与 transaction 时,要么所有数据库都提交更改,要么所有数据库都回滚**更改。

另请参见承诺回滚交易XA

ü


  • 解开


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

另请参见回滚回滚段系统表空间交易撤消 log撤消表空间


  • 撤消缓冲区


  • 撤消 log


    • 保存由 active transactions修改的数据副本的存储区域。如果另一个 transaction 需要查看原始数据(作为一致读取操作的一部分),则从该存储区域检索未修改的数据。

在 MySQL 5.6 和 MySQL 5.7 中,您可以使用innodb_undotablespaces变量将 undo logs 驻留在undo tablespaces中,这可以放在另一个存储设备上,例如SSD。在 MySQL 8.0 中,undo logs 驻留在 MySQL 初始化时创建的两个默认撤销表空间中,并且可以使用创建 UNDO TABLESPACE语法创建其他撤消表空间。

undo log 被拆分为单独的部分,insert undo bufferupdate undo buffer

另请参见一致阅读回滚段SSD系统表空间交易撤消表空间


  • 撤消 log 段


    • 撤消日志的集合。撤消 log 段存在于回滚段中。 undo log 段可能包含多个 transactions 的 undo 日志。 undo log 段只能在 time 使用一个 transaction,但在 transactioncommit rollback释放后可以重用。也可以称为“撤消段”。

另请参见承诺回滚回滚段撤消 log


  • 撤消表空间


    • undo 表空间包含undo logs。撤消日志存在于undo log segments中,它们包含在回滚段中。回滚段传统上驻留在系统表空间中。从 MySQL 5.6 开始,回滚段可以驻留在撤消表空间中。在 MySQL 5.6 和 MySQL 5.7 中,撤消表空间的数量由innodb_undotablespaces configuration 选项控制。在 MySQL 8.0 中,初始化 MySQL 实例时会创建两个默认的撤消表空间,并且可以使用创建 UNDO TABLESPACE语法创建其他撤消表空间。

有关更多信息,请参阅第 14.6.3.4 节,“撤消表空间”

另请参见回滚段系统表空间撤消 log撤消 log 段


  • 独特的约束


    • 一种约束,断言列不能包含任何重复值。就关系代数而言,它用于指定 1-to-1 关系。为了有效地检查是否可以插入 value(即,列中尚未存在 value),底层唯一索引支持唯一约束。

另见约束相关独特的指数


  • 独特的指数


    • 具有唯一约束的列或列集的索引。因为已知索引不包含任何重复值,所以某些类型的查找和计数操作比正常类型的索引更有效。针对此类索引的大多数查找只是确定某个 value 是否存在。索引中的值数与 table 中的行数相同,或者至少是关联列的 non-null 值的行数。

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

另请参见基数改变缓冲独特的约束独特 key


  • 独特 key


    • 包含唯一索引的列集(一个或多个)。如果可以定义恰好与一行匹配的WHERE条件,并且查询可以使用关联的唯一索引,则可以非常有效地执行查找和错误处理。

另见基数独特的约束独特的指数

V


  • variable-length 类型

    InnoDB将大于或等于 768 字节的 fixed-length 字段视为 variable-length 字段,可以存储off-page。对于 example,如果字符集的最大字节长度大于 3,则CHAR(255)列可以超过 768 字节,与utf8mb4一样。

另见off-page 专栏溢出页面


  • 受害者


    • 当检测到死锁时,事务被自动选择回滚InnoDB回滚已更新最少行的 transaction。

    可以使用innodb_deadlock_detect configuration 选项禁用死锁检测

另请参见僵局死锁检测innodb_lock_waittimeout交易


  • 视图


    • 存储的查询在调用时会生成结果集。视图充当虚拟 table。

  • 虚拟列


  • 虚拟生成列


    • 一列,其值是根据列定义中包含的表达式计算的。不存储列值,但在读取任何BEFORE触发器之后立即计算列值。虚拟生成列不占用存储空间。 InnoDB支持虚拟生成列上的二级索引。

存储生成的列对比。

另见基本栏目生成列存储生成的列

另见二级指数存储生成的列虚拟生成列

w ^


  • 等待


    • 当某个操作(例如获取互斥锁锁定)无法立即完成时,InnoDB暂停并再次尝试。暂停的机制很精细,这个操作有自己的 name,wait。使用内部InnoDB调度,操作系统wait() calls 和 short-duration spin循环的组合暂停各个线程。

在负载较重且 transactions 很多的系统上,您可以使用SHOW INNODB STATUS命令或Performance Schema的输出来确定线程是否花费太多 time 等待,如果是,那么如何提高并发性

另请参见并发mutexPerformance Schema


  • 热备份


    • 在数据库运行时采用备份,但在备份 process 期间限制了某些数据库操作。对于 example,表可能变为 read-only。对于繁忙的应用程序和网站,您可能更喜欢热备份

另见备用冷备份热备份


  • 暖身


    • 要在启动后的某个 time 时间内运行典型工作负载下的系统,以便缓冲池和其他 memory 区域在正常条件下填充。当 MySQL 服务器重新启动或受到新工作负载时,此 process 自然发生在 time。

通常,您在 running performance 测试之前运行一些 time 的工作负载来预热缓冲池,以确保跨多个运行的结果一致;否则,performance 可能在第一次 run 期间人为地低。

在 MySQL 5.6 中,您可以通过启用innodb_buffer_pool_dump_at_shutdowninnodb_buffer_pool_load_at_startup configuration 选项来加速 warmup process,以便在重新启动后将缓冲池的内容恢复到 memory。 MySQL 5.7 中默认启用这些选项。见第 14.8.3.6 节,“保存和恢复缓冲池 State”

另见缓冲池工作量


  • 工作量


    • SQL和其他数据库操作的组合和数量,由典型或高峰使用期间的数据库应用程序执行。您可以在 performance 测试期间将数据库置于特定工作负载中以识别瓶颈,或在容量规划期间。

另请参见瓶颈CPU-bounddisk-boundSQL


  • 写合并


    • 一种优化技术,当从InnoDB 缓冲池****刷新脏页**时,减少写操作。如果页面中的行多次更新,或者同一页面上的多行更新,则所有这些更改将在单个写入操作中存储到 data files,而不是每次更改都写入一次。

另见缓冲池脏页红晕

X


  • XA


    • 用于协调分布式事务的标准接口,允许多个数据库参与 transaction,同时保持ACID合规性。有关完整详细信息,请参阅第 13.3.7 节,“XA Transactions”

默认情况下启用 XA Distributed Transaction 支持。如果您不使用此 feature,则可以禁用innodb_support_xa configuration 选项,从而避免每个 transaction 的额外 fsync 的 performance 开销。

从 MySQL 5.7.10 开始,不允许禁用innodb_support_xa,因为它会使复制不安全并阻止与binary log group commit 相关的 performance 增益。 MySQL 8.0 中删除了innodb_support_xa configuration 选项。

另请参见二进制 log承诺交易two-phase 提交

ÿ


  • 年轻


    • InnoDB 缓冲池中的页面的特征意味着它最近被访问过,因此在缓冲池数据结构中被移动,因此它不会被快速刷新****LRU 算法。此术语用于与缓冲池相关的表的某些INFORMATIONSCHEMA列名称。

另请参见缓冲池红晕INFORMATIONSCHEMALRU

Updated at: 7 months ago
Transaction Isolation Level IndexTable of content