MySQL 生僻概念汇总

键缓冲区和键映射

这句话描述了从索引中读取记录的过程，涉及到两个关键概念：键缓冲区（Key Buffer）和键映射（Key Mapping）。

• 键缓冲区（Key Buffer）：键缓冲区是指在内存中的一个缓冲区，用于存储索引的关键字（键）。当查询需要通过索引进行数据检索时，MySQL会首先检查键缓冲区是否已经缓存了相应的索引键。如果键缓冲区中已经存在该键，那么数据库可以直接从缓冲区中读取索引数据，而无需进行磁盘I/O操作，从而提高查询性能。
• 键映射（Key Mapping）：键映射是指将索引键映射到实际数据文件中的位置。当数据库需要读取索引对应的数据记录时，它会使用键映射来确定数据在磁盘上的位置，并读取相应的数据块。键映射可以帮助数据库快速定位到索引对应的数据位置，从而加快数据检索的速度。

举个例子来说明这个过程：

假设有一个名为"users"的表，其中有一个列名为"username"的索引。现在执行一个查询语句：

SELECT * FROM users WHERE username = 'john'。

1）首先，数据库会检查键缓冲区，看是否已经缓存了索引键"john"。如果键缓冲区中存在该键，则可以直接从缓冲区中读取索引数据，跳过磁盘I/O操作，提高查询速度。

2）如果键缓冲区中不存在该键，数据库将使用键映射来确定索引键"john"在实际数据文件中的位置。它会根据索引结构（如B+树）进行相应的搜索和定位操作，找到包含键"john"的数据块。

3）一旦找到包含键"john"的数据块，数据库就可以读取该数据块中的记录，并返回满足查询条件的数据行。

通过使用键缓冲区和键映射，数据库可以快速定位和读取索引中的记录，提高查询性能并减少磁盘I/O的开销。

记录缓冲区和预取缓存

在MySQL中，记录缓冲区（record buffer）和预取缓存（prefetch cache）是用于优化数据库查询性能的机制。

• 记录缓冲区是一个内存区域，用于存储从磁盘读取的数据记录。当查询需要读取数据时，MySQL会首先尝试从记录缓冲区中获取数据，而不是每次都从磁盘读取。这样可以减少磁盘I/O操作，提高查询性能。如果记录缓冲区中没有所需的数据记录，MySQL将从磁盘读取相应的数据并将其存储在记录缓冲区中，以便后续查询可以更快地访问。
• 预取缓存是记录缓冲区的一种扩展，它用于预取（prefetch）更多的数据记录到缓存中。当MySQL检测到查询可能需要连续访问多个数据记录时，它会预先从磁盘读取一批数据记录，并将它们存储在预取缓存中。这样，当查询需要下一个数据记录时，它可以直接从预取缓存中获取，而不需要等待磁盘I/O操作。预取缓存可以显著减少查询的等待时间，提高整体查询性能。

通过使用记录缓冲区和预取缓存，MySQL可以减少磁盘I/O操作，提高数据访问速度，从而改善查询性能。这些缓存机制是由MySQL内部进行管理和优化的，通常不需要用户干预。

快速自适应散列索引搜索

"快速自适应散列索引搜索"（Fast Adaptive Hash Index Search）是MySQL中一种用于高效查询的索引搜索策略。它是针对自适应散列索引（Adaptive Hash Index）而设计的。

自适应散列索引是MySQL中的一种索引类型，它使用散列（hash）算法将索引键映射到索引桶（index bucket）。每个索引桶都包含了一组索引键值对。自适应散列索引的特点是在运行时动态地调整索引结构，以适应数据访问模式的变化。

在快速自适应散列索引搜索中，MySQL会尽可能地利用自适应散列索引来执行查询操作。它会根据查询的条件和数据访问模式，选择合适的索引桶进行搜索，以最大程度地减少磁盘I/O操作和索引搜索的时间。这种搜索策略可以显著提高查询性能，特别是对于频繁查询的场景。

需要注意的是，快速自适应散列索引搜索是MySQL内部的优化策略，通常由MySQL自动选择和执行。对于用户而言，重点是设计和创建适合的索引，以便MySQL可以充分利用自适应散列索引和其他索引类型来提高查询性能。

索引游标

什么是索引游标？

在数据库中，索引是一种用于提高查询效率的数据结构。当执行查询操作时，数据库可以使用索引来快速定位和访问所需的数据。

"将索引游标定位到句柄中指定的索引"这句话的意思是，数据库会使用一个称为游标的指针或标记，将其定位到指定的索引位置。这个过程通常发生在执行索引读取操作时，即根据索引的值来检索数据。

语句中的"游标定位"指的是将游标移动到指定位置的操作。在数据库中，游标可以被视为一个指向查询结果集中的当前行的指针。通过移动游标，您可以在结果集中定位到不同的行，并执行相应的操作，比如读取行的数据。

索引游标是如何定位的？

在MySQL中，当需要读取数据时，MySQL会使用索引游标来定位到指定的索引。索引游标是一个内部数据结构，用于跟踪和定位索引中的记录。

当执行查询语句时，MySQL的查询执行引擎会按照查询条件中指定的索引来选择合适的索引。然后，MySQL会使用索引游标来定位到句柄（又称为文件句柄或页句柄）中指定的索引。

下面是大致的过程：

1）MySQL首先通过索引的B+树结构或其他索引结构来确定索引的层级关系（根节点、叶子节点等）。

2）MySQL根据查询条件中指定的索引键值，通过索引结构进行搜索和定位。它会从根节点开始，根据索引键值逐层向下搜索，直到找到匹配的叶子节点。

3）一旦找到匹配的叶子节点，MySQL会获取该叶子节点中存储的记录指针（也称为记录句柄），这个记录指针包含了数据记录的位置信息。

4）MySQL根据记录指针获取数据记录，并返回给查询操作。

需要注意的是，索引游标的定位过程是在内存中进行的，它并不涉及磁盘I/O操作。因为索引通常会被缓存在内存中，所以MySQL可以快速定位到索引的位置，并读取相应的数据记录。

通过使用索引游标，MySQL能够高效地定位和读取索引中的数据，从而提高查询性能和响应速度。

表句柄实例与m_prebuilt

在MySQL中，表句柄实例（Table Handler Instance）是指与每个表相关联的数据结构，用于管理和操作表中的数据。每个表句柄实例都包含一个与之关联的InnoDB数据结构体，称为'm_prebuilt'结构体。

'm_prebuilt'结构体是InnoDB存储引擎中的一个数据结构，它包含了与表句柄实例相关的大部分InnoDB数据。该数据结构保存了表的元数据信息、索引信息、行数据等。它在查询执行过程中被使用，用于存储和管理表的相关数据。

举个例子来说明：

假设有一个名为employees的表，包含员工的信息，如员工ID、姓名、部门等。当执行查询语句时，MySQL会创建一个表句柄实例来处理该表。

对于这个employees表的表句柄实例，会有一个与之关联的'm_prebuilt'结构体。该结构体存储了employees表的元数据信息（如表结构、列类型等）、索引信息（如主键索引、辅助索引等）以及行数据等。

在查询执行过程中，MySQL的查询执行引擎会使用表句柄实例和'm_prebuilt'结构体来定位和读取表中的数据。例如，当执行SELECT语句时，MySQL会使用表句柄实例和'm_prebuilt'结构体来确定需要读取的数据行、应用查询条件、处理索引等操作。

这种设计可以提高查询性能，因为'm_prebuilt'结构体保存了与表相关的重要数据，避免了重复的数据访问和解析操作。

总之，表句柄实例是MySQL中用于管理和操作表数据的数据结构，而'm_prebuilt'结构体是InnoDB存储引擎中与表句柄实例相关的数据结构，它包含了表的元数据、索引信息和行数据等。这些结构体的使用可以提高查询性能和数据访问效率。

内建表

内建表（Built-in Table）：内建表是指MySQL中的系统表或元数据表，用于存储数据库服务器的配置信息、权限信息、表结构信息等。这些表是MySQL自身所使用的，用于管理和维护数据库服务器的正常运行。

常见的内建表包括mysql.user（存储用户账号和权限信息）、mysql.db（存储数据库权限信息）、mysql.tables_priv（存储表级权限信息）等。这些表通常由MySQL自动创建和维护，用户一般无需直接操作这些表。

InnoDB并发控制

InnoDB并发控制（InnoDB Concurrency Control）：InnoDB是MySQL中一种常用的存储引擎，提供了高度的并发性能和事务支持。并发控制是指在多个并发事务同时访问数据库时，保证数据的一致性和隔离性的机制。

InnoDB使用多版本并发控制（MVCC）来实现并发控制。MVCC通过在每个数据行上保存多个版本的数据，使得每个事务在读取数据时能够看到一致的快照，而不会被其他事务的修改所干扰。当有多个事务同时修改同一数据行时，InnoDB使用锁和锁冲突检测来协调并发访问，确保数据的一致性和隔离性。

具体来说，InnoDB使用以下机制来实现并发控制：

• 读写锁（Locks）：InnoDB使用共享锁（读锁）和排他锁（写锁）来控制对数据行的并发访问。读锁之间可以共享，写锁之间是互斥的。这样可以确保读操作之间的并发性，同时保证写操作的原子性和隔离性。
• 事务隔离级别（Transaction Isolation Level）：InnoDB支持多个事务隔离级别，如读未提交（Read Uncommitted）、读已提交（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable）。不同的隔离级别提供了不同的并发控制机制，用于平衡并发性能和数据一致性之间的关系。
• 快照读（Snapshot Read）：InnoDB允许事务在读取数据时，使用一致的快照来获取数据。这样可以避免读取到其他事务正在修改的数据，提高了并发性能和数据的隔离性。

通过上述并发控制机制，InnoDB能够提供高度的并发性能和事务支持，保证多个事务之间的数据一致性和隔离性。这使得InnoDB成为了MySQL中常用的存储引擎之一。

间隙锁

间隙锁（Gap Locks）是InnoDB存储引擎中的一种锁机制，用于在多个事务之间保持一定的间隔，防止出现幻读（Phantom Read）的情况。

具体来说，间隙锁是用于锁定索引范围而不是实际存在的记录。它会在索引上的间隙（两个索引值之间的区域）上设置锁，阻止其他事务在该间隙内插入新记录，从而保证了查询的一致性。

举个例子来说明：

假设有一个名为orders的表，其中包含订单信息，包括订单号（order_id）和订单金额（amount）等字段。我们希望查询订单金额大于100的订单数量。

首先，我们执行以下查询语句：

SELECT COUNT(*) FROM orders WHERE amount > 100;

在执行这个查询时，InnoDB存储引擎会使用间隙锁来保护查询范围。它会在满足条件的订单金额大于100的记录上设置行锁，并在金额为100的记录之前和之后的索引间隙上设置间隙锁。

这样，如果另一个事务尝试在这个查询的范围内插入一个新的订单记录（比如金额为110的订单），间隙锁会阻止该插入操作（只要是金额大于100的订单都会被阻止），从而避免了幻读的问题。只有当查询事务释放了间隙锁后，其他事务才能在该间隙内插入新记录。

需要注意的是，间隙锁只会在事务使用范围查询或使用范围条件的语句时才会被使用。对于使用相等条件的查询（如WHERE amount = 100），InnoDB会使用行锁而不是间隙锁。

总之，间隙锁是InnoDB存储引擎中用于保护索引范围的一种锁机制。它可以防止幻读问题的发生，保证了查询的一致性和隔离性。

幻读

幻读（Phantom Read）是数据库中并发事务执行时的一种现象，它指的是在同一个事务中，由于其他并发事务的插入或删除操作，导致前后两次相同的查询返回不同的结果。

幻读通常发生在使用范围条件的查询中，例如使用SELECT语句查询某个范围内的记录。当一个事务在查询期间，另一个事务插入了符合查询条件的新记录，那么在同一个事务中再次执行相同的查询时，就会发现多了一些之前不存在的记录，就好像出现了幻觉一样，这就是幻读。

举个例子来说明：

假设有一个名为products的表，其中包含产品信息，包括产品ID（product_id）和产品价格（price）等字段。我们希望查询价格低于10的产品数量。

首先，我们执行以下查询语句：

SELECT COUNT(*) FROM products WHERE price < 10;

在执行这个查询时，如果另一个事务插入了一个价格低于10的新产品，那么在同一个事务中再次执行相同的查询时，就会发现记录数量增加了，出现了幻读。

假设在第一次查询后，另一个事务插入了一个价格为5的新产品。然后，在同一个事务中再次执行相同的查询，结果可能会返回更多的记录，包括之前不存在的价格为5的产品。

这就是幻读的典型例子，事务在查询期间，其他事务的插入操作导致了查询结果的不一致。

为了解决幻读问题，数据库系统提供了不同的隔离级别（如读未提交、读提交、可重复读和串行化），并使用锁机制（如间隙锁）来保证事务的隔离性和一致性。通过选择适当的隔离级别和使用合适的锁机制，可以避免或减少幻读的发生。

意向锁

意向锁（Intention Lock）是数据库中的一种锁机制，用于在并发事务环境下管理和控制对数据对象（如表、页、行）的访问。它是一种粒度较粗的锁，用于指示事务对某个数据对象的意图，以协调多个事务之间的并发操作。

意向锁分为两种类型：

1）意向共享锁（Intention Shared Lock，IS锁）：表示事务打算对数据对象进行读取操作，但不排斥其他事务也对该数据对象进行读取操作。多个事务可以同时持有意向共享锁，但不能与排他锁（X锁）共存。

2）意向排他锁（Intention Exclusive Lock，IX锁）：表示事务打算对数据对象进行写入操作，但不排斥其他事务对该数据对象进行读取操作。多个事务可以同时持有意向排他锁，但不能与共享锁（S锁）或其他排他锁（X锁）共存。

意向锁的作用是提供了一种层次结构的锁管理机制，可以帮助数据库管理系统判断是否需要等待或释放锁资源。通过意向锁，可以减少锁冲突，提高并发性能。

下面是一个示例说明意向锁的使用场景：

假设有一个数据库表 "orders"，多个事务同时进行操作。其中，事务A打算对表进行写入操作（如插入新的订单记录），事务B打算对表进行读取操作（如查询订单信息）。

• 事务A在开始写入之前，会请求意向排他锁（IX锁）来表明其对表的写入意图。
• 事务B在开始读取之前，会请求意向共享锁（IS锁）来表明其对表的读取意图。

这样，在事务A持有意向排他锁（IX锁）的同时，事务B可以持有意向共享锁（IS锁），它们之间不会发生冲突。如果有其他事务C也打算进行写入操作，则事务C会请求排他锁（X锁），此时会与事务A的意向排他锁（IX锁）发生冲突，需要等待事务A释放锁资源。

通过使用意向锁，数据库管理系统可以更好地控制并发事务对数据对象的访问，提高并发性能和数据一致性。

需要注意的是，意向锁是数据库内部使用的一种机制，并不需要用户手动创建或管理。它在数据库引擎中实现，用于支持并发事务的正确执行。

一致性读取

一致性读取（Consistent Read）是数据库中的一种读取操作方式，它确保在事务执行期间读取的数据是一致的，即读取的数据反映了一个一致的数据库状态。一致性读取通常应用于具有事务性需求的场景，确保事务在读取数据时能够看到一个一致的数据快照，而不会受到其他并发事务的影响。

一致性读取的特点如下：

1）读取的数据反映了一个一致的数据库状态：在一致性读取中，数据库引擎会根据事务开始时的时间点来获取数据，保证读取的数据反映了该时间点之前的一致数据库状态。

2）读取的数据不受并发事务的修改影响：一致性读取会忽略其他并发事务对数据的修改，确保读取操作不会受到未提交事务的影响，保证了读取的数据的一致性。

下面是一个示例说明一致性读取的使用场景：

假设有一个数据库表 "products"，其中包含产品的库存数量。现在有两个并发事务，事务A负责查询产品的库存数量，事务B负责修改产品的库存数量。

• 事务A开始执行一致性读取操作，查询产品的库存数量为100。
• 事务B在事务A执行一致性读取之后，将产品的库存数量减少为80。
• 事务A继续执行其他操作，不受事务B的修改影响。

在这个例子中，一致性读取确保事务A在读取产品库存数量时，看到的是一个一致的数据快照，即100。即使在事务A执行期间，事务B对库存数量进行了修改，事务A仍然读取到了之前的一致状态，不受事务B的修改影响。

通过使用一致性读取，事务可以在读取数据时获取一个一致的数据快照，保证数据的一致性和事务的隔离性。这对于需要进行读取操作的事务非常重要，因为它们需要基于一致的数据状态进行后续的业务处理，而不受其他并发事务的干扰。

需要注意的是，一致性读取通常与数据库的隔离级别相关。在不同的隔离级别下，数据库引擎对一致性读取的处理方式可能会有所不同。因此，在使用一致性读取时，需要了解数据库的隔离级别以及相应的行为规则。

空间索引

空间索引（Spatial Index）是在地理空间数据中使用的一种索引结构，用于加速地理空间数据的查询和分析操作。它是一种特殊的索引，能够有效地组织和管理具有地理位置信息的数据，提供高效的空间查询能力。

空间索引的主要目的是解决地理空间数据的高维性和复杂性带来的查询效率问题。地理空间数据通常包含了地理坐标（如经度和纬度）或几何形状（如点、线、面），传统的索引结构难以直接应用于这种类型的数据。空间索引通过将地理空间数据映射到一种适合进行快速查询的数据结构中，提供了高效的空间查询功能。

常见的空间索引结构包括：

1）R树（R-tree）：R树是一种多叉树结构，用于组织和管理地理空间数据。它通过将地理对象逐层划分为矩形区域，构建一棵树形结构来表示地理空间数据。R树可以快速定位和检索与查询范围相交的地理对象，适用于范围查询和最近邻查询等操作。

2）四叉树（Quadtree）：四叉树是一种二叉树的变种，用于组织和管理地理空间数据。它将地理空间划分为四个象限，并将地理对象逐层存储在相应的象限中。四叉树适用于点数据和二维几何对象的查询，可以快速定位和检索与查询范围相交的地理对象。

3）网格索引（Grid Index）：网格索引将地理空间划分为规则的网格单元，并将地理对象按照其所属的网格单元进行索引。网格索引适用于均匀分布的地理空间数据，可以快速定位和检索与查询网格单元相交的地理对象。

空间索引的使用场景非常广泛，例如：

1）地图应用：在地图应用中，需要根据用户的位置信息查询附近的商店、餐馆等地点。通过使用空间索引，可以快速定位和检索与用户位置相交的地理对象，提供准确的查询结果。

2）地理信息系统（GIS）：GIS系统用于管理和分析地理空间数据，例如土地利用、环境监测、城市规划等。空间索引可以加速对地理空间数据的查询和分析操作，提高GIS系统的性能和响应速度。

3）位置服务：位置服务应用如出租车叫车、路径规划等，需要根据用户的位置信息进行查询和计算。通过使用空间索引，可以快速定位和检索与用户位置相关的地理对象，提供准确的位置服务。

通过使用空间索引，可以大大提高地理空间数据的查询效率和分析能力，使得对地理空间数据的操作更加高效和精确。不同的空间索引结构适用于不同类型的地理空间数据和查询需求，选择合适的空间索引结构可以根据具体应用场景来优化查询性能。

预测锁

预测锁（Predictive Locking）是一种并发控制机制，用于在多用户并发访问数据库时管理事务之间的锁定和冲突。它通过预测事务可能需要的锁定资源，并在事务执行之前提前获取这些锁定资源，从而减少锁定冲突的发生，提高并发性能。

预测锁的工作原理如下：

1）事务开始前的锁定预测：在事务开始执行之前，预测锁会分析事务的查询操作和访问模式，并预测可能需要的锁定资源。这些锁定资源可以是数据行、表、页或其他数据库对象。

2）提前获取锁定资源：根据预测结果，预测锁会提前获取事务可能需要的锁定资源。这样，在事务执行期间，其他并发事务就无法获取到这些锁定资源，避免了锁定冲突的发生。

3）锁定资源的释放：事务在完成操作后会释放已经获取的锁定资源，使其他事务能够继续访问这些资源。

通过使用预测锁，可以减少锁定冲突的概率，提高数据库的并发性能和吞吐量。然而，预测锁也存在一些潜在的问题，例如预测错误可能导致不必要的锁定和资源浪费，或者无法准确预测事务的行为而导致锁定冲突的发生。

MySQL常用搜索模式

除了"GE"（大于等于）和"G"（大于）之外，MySQL还提供了其他比较运算符和搜索模式。以下是一些常用的搜索模式及其详细介绍和示例：

1）大于等于（GE）和大于（G）：匹配大于等于或大于给定值的记录。

示例：

SELECT * FROM products WHERE price >= 100;

2）小于等于（LE）和小于（L）：匹配小于等于或小于给定值的记录。

示例：

SELECT * FROM products WHERE price <= 100;

3）不等于（<>）：匹配不等于给定值的记录。

示例：

SELECT * FROM users WHERE role <> 'admin';

4）IS NULL：匹配字段值为空（NULL）的记录。

示例：

SELECT * FROM users WHERE email IS NULL;

5）IS NOT NULL：匹配字段值不为空（NOT NULL）的记录。

示例：

SELECT * FROM users WHERE email IS NOT NULL;

6）LIKE运算符与通配符的组合：结合通配符进行更灵活的模糊匹配。

示例：

SELECT * FROM products WHERE name LIKE '%apple%';

7）BETWEEN运算符：匹配位于给定范围内的记录。

示例：

SELECT * FROM sales WHERE date BETWEEN '2022-01-01' AND '2022-12-31';

8）NOT BETWEEN运算符：匹配不在给定范围内的记录。

示例：

SELECT * FROM sales WHERE date NOT BETWEEN '2022-01-01' AND '2022-12-31';

9）EXISTS子查询：检查是否存在满足特定条件的记录。

示例：

SELECT * FROM orders WHERE EXISTS (SELECT * FROM products WHERE orders.product_id = products.id);

这些搜索模式可以根据具体的查询需求选择和组合使用，以实现灵活的数据检索和匹配。请注意，在使用搜索模式时，要考虑性能和索引的使用，以避免不必要的查询开销。

页与Infimum、Supremum的关系

以下是对infimum、supremum、页、结果集和锁定的介绍以及它们之间的关系：

定义：

1）页（Page）：页是数据库中存储数据的基本单位。它是磁盘上的一块连续空间，用于存储多条记录。数据库将数据组织成页的形式，以便进行高效的读取和写入操作。每个页都有一个固定的大小，通常是几KB或几MB。

2）Infimum（下限）和Supremum（上限）：Infimum和Supremum是B+树索引结构中每个页的特殊记录。它们位于索引页的最底部和最顶部，不包含实际的数据。Infimum记录是所有数据记录的最小值，用于维护B+树索引的结构。Supremum记录是所有数据记录的最大值，也用于维护B+树索引的结构。

关系：

• 一个页可以包含多个数据记录，这些记录按照特定的排序方式（通常是根据索引键值）组织在页中。
• 在一个页中，Infimum记录位于最底部，Supremum记录位于最顶部，它们分别标志着该页中记录的最小值和最大值的边界。
• Infimum和Supremum记录不包含实际的数据，它们只是用于维护B+树索引的结构和一致性。
• 在B+树索引中，通过Infimum和Supremum记录，可以保证索引的完整性和一致性，同时提供高效的索引遍历和查询操作。

总结来说，页是数据库中存储数据的基本单位，而Infimum和Supremum是B+树索引结构中每个页的特殊记录，用于维护索引的结构和边界。它们共同组成了数据库中的数据存储和索引机制的基础。

热加载

热加载是指在运行时动态加载或替换数据库中的某些组件或配置，而无需停止或重新启动数据库实例。这样可以实现系统的无缝升级、插件的动态加载或配置的实时更新。热加载可以提高数据库的可用性和灵活性，因为它允许在不中断服务的情况下进行系统的修改和更新。

例如，假设你正在运行一个数据库系统，并且想要添加一个新的存储引擎或更改数据库的配置参数。通过热加载，你可以在不停止数据库服务的情况下，动态地加载新的存储引擎或更新配置参数，使其立即生效。

探活

探活是指对数据库系统或其组件进行健康检查，以确保其正常运行和可用性。探活通常涉及监测数据库的各个方面，如连接状态、资源利用率、性能指标等。通过定期或实时地进行探活，可以及早发现数据库系统的故障、性能问题或其他异常情况，并采取相应的措施进行修复或优化。

探活可以通过各种手段实现，包括监控工具、自动化脚本或专门的探活服务。这些工具和方法可以定期向数据库发送查询或命令，获取系统状态和性能指标，并根据预定义的规则或阈值来判断数据库的健康状态。

RBO

基于规则优化，传统查询优化方法

CBO

基于代价优化，传统查询优化方法

常量表

常量表（Constant Table）是指在查询过程中不会发生变化的表。它通常包含一些固定的、静态的数据，这些数据在查询过程中保持不变。

常量表的特点是数据不会被修改、插入或删除，因此它可以在查询中作为一个静态的参考表使用。常量表通常用于存储一些固定的参考数据，例如国家代码、性别列表、状态码等。

常量表的优势包括：

1）提高查询性能：由于常量表的数据是固定的，不需要在查询过程中进行实时的数据读取和计算，因此查询速度更快。

2）简化查询逻辑：通过将常量数据存储在表中，可以将复杂的数据转换或计算操作提前完成，简化查询语句的编写和理解。

3）减少数据库负载：常量表的数据不会频繁变动，不会引起额外的数据库更新操作，从而减少了数据库的负载。

需要注意的是，常量表适用于数据不经常变动的情况。如果常量表中的数据需要频繁更新或者包含大量的数据，可能会导致额外的存储和维护成本，此时需要综合考虑是否使用常量表。

以下是一个示例，展示了一个常量表的结构和用法：

假设我们有一个名为 "gender" 的常量表，用于存储性别的数据。表结构如下：

CREATE TABLE gender ( id INT, name VARCHAR(50) ); INSERT INTO gender (id, name) VALUES (1, 'Male'), (2, 'Female');

在上述示例中，我们创建了一个名为 "gender" 的常量表，包含了 id 和 name 两列，分别表示性别的标识和名称。这些数据是固定的，不会发生变化。

在查询过程中，我们可以使用该常量表作为参考表，例如：

SELECT users.name, gender.name AS gender FROM users JOIN gender ON users.gender_id = gender.id;

通过将常量表 "gender" 与用户表 "users" 进行连接，我们可以将性别的标识转换为对应的名称，从而简化查询结果的理解。常量表的使用可以提高查询的可读性和性能。

系统表

系统表是数据库内部用于存储关于数据库结构和元数据的特殊表格。它们提供了对数据库中对象（如表、列、索引等）的信息查询。

在 MySQL 数据库中，一个常见的系统表是 information_schema.tables，它包含了数据库中所有表的元数据信息。

以下是一个简单的例子，展示了如何使用 information_schema.tables 查询数据库中所有表的名称：

SELECT table_name FROM information_schema.tables WHERE table_schema = 'your_database_name';

这将返回指定数据库（your_database_name）中所有表的名称。

另一个例子是 information_schema.columns，它包含了所有表的列的元数据信息：

SELECT table_name, column_name, data_type FROM information_schema.columns WHERE table_schema = 'your_database_name';

这将返回指定数据库中所有表的列名和数据类型。

请注意，这些例子适用于 MySQL 数据库，其他数据库系统（如 PostgreSQL、SQLite 等）可能会有自己的系统表结构和查询方式。

持续更新中！！！

 PDF有划重点，阅读起来更舒适！

如果需要本文 WORD、PDF 相关文档请在评论区留言！！！ 

如果需要本文 WORD、PDF 相关文档请在评论区留言！！！ 

如果需要本文 WORD、PDF 相关文档请在评论区留言！！！