您当前的位置:首页 > 电脑百科 > 数据库 > MYSQL

MySQL 8.0 数据字典表

时间:2023-02-04 14:27:47  来源:今日头条  作者:一树一溪

MySQL 8.0 对数据字典进行了重构,用户表、数据字典表、MySQL 其它系统表的元数据都统一保存到 mysql 库的数据字典表中了。

mysql 库中,除了 general_log、slow_log 2 个日志表,其它所有表的存储引擎都是 InnoDB,伴随而来的是 ddl 终于能够支持原子操作了。

以 DROP TABLE t1, t2 为例,不会出现 t1 表删除成功,t2 表删除失败的情况,而是要么都删除成功,要么都删除失败。

本文我们就来聊聊 MySQL 8.0 中的数据字典表。

 

本文内容基于 MySQL 8.0.29 源码。

 

目录

 

  • 1. 概述
  • 2. 数据字典表有哪些?
  • 3. 数据字典表元数据在哪里?
  • 4. 创建数据字典表
  • 5. 打开数据字典表
  • 6. 总结

 

正文

1. 概述

MySQL 8.0 重构数据字典之后,废除了 MySQL 5.7 中用于保存元数据的磁盘文件:.frm、.par、.TRN、.TRG、.isl、db.opt、ddl_log.log。

 

如果想要了解上面这些磁盘文件都保存了什么元数据,可以参照 MySQL 官方文档:https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html

 

这些文件被废除之后,原本保存到这些文件中的元数据,都保存到数据字典表中了。

数据字典表本身也大变样了:

 

  • 数据字典表不再位于 innodb 系统表空间,而是迁移到 mySQL 库中,mysql 库位于 mysql 表空间,磁盘文件为 mysql.ibd。
  • SYS_TABLES、SYS_COLUMNS、SYS_INDEXES、SYS_FIELDS 这 4 个数据字典表也不再完全依赖硬编码在源码中的元数据了,而是和其它表一样,使用保存在 mysql 库的数据字典表中的元数据。
上面 4 个数据字典表的名字也发生了变化,后面会介绍。
2. 数据字典表有哪些?

 

按照官方文档的定义,MySQL 8.0 一共有 31 张数据字典表:


dd_properties innodb_ddl_log catalogs character_sets check_constrAInts collations column_statistics column_type_elements columns events foreign_key_column_usage foreign_keys index_column_usage index_partitions index_stats indexes parameter_type_elements parameters resource_groups routines schemata st_spatial_reference_systems table_partition_values table_partitions table_stats tables tablespace_files tablespaces triggers view_routine_usage view_table_usage

上面只是简单列出了数据字典表的表名,如果想了解每个表存放了什么内容,可以参照官方文档:https://dev.mysql.com/doc/refman/8.0/en/system-schema.html

默认情况下,我们是看不到数据字典表的,需要满足以下条件才能看到:

 

  • 源码编译 Debug 版本 MySQL,以使用 cmake 编译为例,需要带上 -DCMAKE_BUILD_TYPE=Debug 编译选项。
  • 连接 MySQL 之后,先执行下面的 SQL 告诉 MySQL 跳过数据字典表的权限检查:
SET SESSION debug = '+d,skip_dd_table_access_check'

 

满足以上 2 个条件之后,执行下面这条 SQL 就可以看到所有数据字典表了:

SELECT a.name AS db_name, b.* FROM mysql.schemata AS a INNER JOIN mysql.tables AS b ON a.id = b.schema_id WHERE b.schema_id = 1 AND b.hidden = 'System' ORDER BY b.id

执行上面的 SQL 列出来的表有 32 个,其中 INNODB_dynamic_metadata 表不属于数据字典表。

 

上面列出的数据字典表中,有 4 个需要重点介绍,因为不管是数据字典表本身,还是用户表,都离不开这 4 个表:

 

  • tables:存储表的元数据,包括表空间 ID、数据库 ID、表 ID、表名、表注释、行格式等信息,对应 MySQL 5.7 中的数据字典表 SYS_TABLES。
  • columns:存储表中字段的元数据,包括表 ID、字段 ID、字段名、字段注释、字段类型、是否自增等信息,对应 MySQL 5.7 中的数据字典表 SYS_COLUMNS。
  • indexes:存储表的索引元数据,包括表空间 ID、表 ID、索引 ID、索引名、索引注释、是否是隐藏索引等信息,对应 MySQL 5.7 中的数据字典表 SYS_INDEXES。
  • index_column_usage:存储索引中字段的元数据,包括索引 ID、字段 ID、字段在索引中的编号(从 1 开始)、索引字段长度(如果是前缀索引字段,则是前缀的长度)、索引字段排序、是否隐藏,共 6 个字段,对应 MySQL 5.7 中的数据字典表 SYS_FIELDS。
    这个表中没有包含更详细的字段信息,如果需要,可以通过字段 ID 到 columns 表获取。

 

index_column_usage 和 SYS_FIELDS 表不完全一样,有 2 点需要说明:

 

  • index_column_usage 包含 6 个字段,比 SYS_FIELDS 多 3 个字段:
    order:表示索引字段的排序。
    length:hidden = 0 时,表示索引字段长度,或前缀索引字段的前缀长度;hidden = 1 时,字段值为 NULL。
    hidden:0 表示索引中该字段由用户定义;1 表示索引中该字段是 MySQL 给加上的。以下是一个测试表,图中 name 是从 columns 表中连表查询得到的,其它都是 index_column_usage 表的字段。
CREATE TABLE `t5` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `str1` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8_general_ci NOT NULL DEFAULT '', `i1` int NOT NULL DEFAULT '0', `str2` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8_general_ci NOT NULL DEFAULT '', `i2` int NOT NULL DEFAULT '0', PRIMARY KEY (`id`) USING BTREE, UNIQUE KEY `idx_i1` (`i1`) USING BTREE, KEY `idx_str1` (`str1`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;

 


 

index_id = 310 是主键索引,hidden = 0 的记录是主键字段;hidden = 1 的记录是主键索引中的其它字段,也就是表中的字段。

index_id = 312 是二级索引,其中 str1 是前缀索引字段,前缀长度为 255 * 3(utf8 一个字符最多占用的字节数) = 765,hidden = 0 表示 str1 是用户定义的二级索引字段;hidden = 1 的记录是 MySQL 自己增加到二级索引中的主键字段。

 

  • index_column_usage 表中的 ordinal_position 表示编号,从 1 开始;SYS_FIELDS 中的 POS 表示序号,从 0 开始。

 

除了在 Debug 版本的 MySQL 中设置跳过数据字典表的权限检查之外,还可以通过 information_schema 数据库中的表或视图查看其对应的数据字典表:

数据字典表information_schema 表或视图tablesINNODB_TABLEScolumnsINNODB_COLUMNSindexesINNODB_INDEXESindex_column_usage
INNODB_FIELDS…………

3. 数据字典表元数据在哪里?

数据字典表用于存储用户表的元数据,这个比较好理解,因为创建用户表的时候,所有数据字典表都已经存在了,把用户表的各种元数据插入到相应的数据字典表就可以了。

数据字典表本身的元数据也会保存到数据字典表里,但是某个数据字典表创建的时候,有一些数据字典表还没有创建,这就有问题了。

我们以 columns、indexes 这 2 个数据字典表为例来说明:columns 表先于 indexes 表创建,columns 表创建成功之后,需要把索引元数据保存到 indexes 表中,而此时 indexes 表还没有创建,columns 表的索引元数据自然也就没办法保存到 indexes 表中了。

MySQL 解决这个问题的方案是引入一个中间层,用于临时存放所有数据字典表的各种元数据,等到所有数据字典表都创建完成之后,再把临时存放在中间层的所有数据字典表的元数据保存到相应的数据字典表中。

这里所谓的中间层实际上是一个存储适配器,源码中对应的类名为 Storage_adapter,这是一个实现了单例模式的类。

MySQL 在初始化数据目录的过程中,Storage_adapter 类的实例属性 m_core_registry 就是所有数据字典表元数据的临时存放场所。

4. 创建数据字典表

我们安装 MySQL 完成之后,想让 MySQL 运行起来,要做的第一件事就是初始化 MySQL,实际上就是初始化 MySQL 数据目录。

初始化过程会创建 MySQL 运行时需要的各种表空间、数据库、表,其中就包含数据字典表。

创建数据字典表的过程分为 3 个步骤进行:

第 1 步,把代表每个数据字典表的 Object_table 对象注册到 System_tables 类的实例属性 m_registry 中。

 

除了数据字典表,m_registry 中还包含了 mysql 库中的其它 MySQL 系统表。

 

第 2 步,循环 m_registry 中的所有表,通过 Object_table 得到数据字典表的 DDL,然后调用 dd::execute_query() 执行 DDL 语句创建数据字典表。

dd::execute_query() 创建数据字典表的过程中,会把表的元数据临时存放到 Storage_adapter 类的实例属性 m_core_registry 中,而不会保存到各种元数据对应的数据字典表中,这么做的原因在上一小节中介绍数据字典表的元数据在哪里时,已经介绍过了,这里不再赘述。

dd::execute_query() 执行完一个数据字典表的 DDL 语句之后,这个数据字典表在表空间中就已经存在了,m_registry 中的所有表都处理完成之后,所有数据字典表就都存在了。


 

第 3 步,循环 m_registry 中的所有表,把每个表本身的元数据(数据库 ID、表 ID、表名、注释、字段数量等)保存到 mysql.tables 数据字典表中,然后把表的字段、索引等元数据保存到对应的数据字典表中。

 

所有数据字典表的元数据都从 Storage_adapter 类的实例属性 m_core_registry 中读取。

 


 

经过 3 个步骤的通力协作,所有数据字典表的元数据就都保存到数据字典表中了,这个鸡生蛋、蛋生鸡的问题,就这样通过引入外力(m_core_registry)解决了。

5. 打开数据字典表

数据字典表保存着 MySQL 运行过程中需要的一系列关键数据,使用频次很高,MySQL 启动过程中就会把数据字典表的元数据都加载到内存中,这就是打开表的过程。

也就是说,打开数据字典表是在 MySQL 启动过程中完成的。

前面我们介绍过,数据字典表的元数据也是保存在数据字典表中的。

MySQL 启动过程中,要先打开数据字典表才能拿到数据字典表的元数据,而要拿到数据字典表的元数据,又必须先打开数据字典表。

这个过程很绕,不是很好理解,我们来打个比方:数据字典表是一个房间,数据字典表的元数据是打开房间门的钥匙。

现在问题来了,因为 MySQL 把数据字典表的元数据保存在数据字典表中,这就相当于把打开房间门的钥匙落在房间里了。

要想打开房间,必须先拿到钥匙,而要想拿到钥匙又必须先打开房间,这样一转换,问题是不是更好理解点了?

我们先来想想怎么解决房间和钥匙问题,如果把打开房间的钥匙落在房间里了,有哪些办法可以解决?

我能想到的有以下 3 种解决方案:

 

  • 暴力破解,把锁撬开。
  • 找专业的开锁师傅把锁打开。
  • 用备用钥匙开门。这个方法最好,但是有个前提条件:已经提前准备好了备用钥匙。

 

MySQL 里没有前 2 种方案,而是留了一把备用钥匙,也就是第 3 种方案,接下来我们看看 MySQL 打开数据字典表的过程:

第 1 步,和创建数据字典表一样,把代表每个数据字典表的 Object_table 对象注册到 System_tables 类的实例属性 m_registry 中。

每个数据字典表的 Object_table 对象中,都定义了这个表的表名、字段、索引、外键等信息。

Object_table 对象中保存的并不是 DDL 语句,却类似于我们建表时的 DDL 语句。

下面这个例子是源码中表空间数据字典表 mysql.tablespaces Object_table 对象中定义的该表的信息:

Tablespaces::Tablespaces() { // 表名 m_target_def.set_table_name("tablespaces"); // 字段 m_target_def.add_field(FIELD_ID, "FIELD_ID", "id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT"); m_target_def.add_field(FIELD_NAME, "FIELD_NAME", "name VARCHAR(268) NOT NULL COLLATE " + String_type(Object_table_definition_impl::name_collation()->m_coll_name)); m_target_def.add_field(FIELD_OPTIONS, "FIELD_OPTIONS", "options MEDIUMTEXT"); m_target_def.add_field(FIELD_SE_private_DATA, "FIELD_SE_PRIVATE_DATA", "se_private_data MEDIUMTEXT"); m_target_def.add_field(FIELD_COMMENT, "FIELD_COMMENT", "comment VARCHAR(2048) NOT NULL"); m_target_def.add_field(FIELD_ENGINE, "FIELD_ENGINE", "engine VARCHAR(64) NOT NULL COLLATE utf8_general_ci"); m_target_def.add_field(FIELD_ENGINE_ATTRIBUTE, "FIELD_ENGINE_ATTRIBUTE", "engine_attribute JSON"); // 索引 m_target_def.add_index(INDEX_PK_ID, "INDEX_PK_ID", "PRIMARY KEY(id)"); m_target_def.add_index(INDEX_UK_NAME, "INDEX_UK_NAME", "UNIQUE KEY(name)"); // 如果有外键等其它信息,也会加在这里 }

第 2 步,循环 m_registry 中的所有表,通过 Object_table 得到数据字典表的 DDL,然后调用 dd::execute_query() 执行 DDL 语句创建数据字典表。

和创建数据字典表中的第 2 步不一样,dd::execute_query() 执行 DDL,并不会真正的创建表,只是为了生成数据字典表元数据,并把元数据保存到 Storage_adapter 类的实例属性 m_core_registry 中。

保存到 m_core_registry 中的数据字典表元数据,就是我们前面说的备用钥匙,有了这把备用钥匙,就能打开数据字典表了。


 

第 3 步,循环 m_registry 中的所有表,通过第 2 步生成的数据字典表元数据,去 mysql 表空间中(表空间文件:mysql.ibd)读取各个数据字典表的元数据。

这一步执行完成之后,所有数据字典表的元数据都被加载到内存中了,数据字典表都被打开了。

第 4 步,循环 m_registry 中的所有表,把数据字典表的元数据从 m_core_registry 删除。

第 5 步,循环 m_registry 中所有的表,把从表空间中读取出来的数据字典表的元数据存入 m_core_registry 中。

不过,这一步存入 m_core_registry 的并不是所有数据字典表的元数据,而是 22 个核心(CORE)数据字典表的元数据:

catalogs character_sets check_constraints collations column_statistics column_type_elements columns foreign_key_column_usage foreign_keys index_column_usage index_partitions indexes resource_groups schemata table_partition_values table_partitions tables tablespace_files tablespaces triggers view_routine_usage view_table_usage

1 ~ 5 步执行完成之后,m_core_registry 中就只包含上面 22 个核心数据字典表的元数据了,有了这些表的元数据,就可以打开其它所有表了。

第 6 步,调用 dd::execute_query() 执行 FLUSH TABLES 关闭已经打开的所有数据字典表、非数据字典表,后续就可以用从数据字典表中读取出来的元数据来打开数据字典表和其它所有需要的表了。

到这里,打开数据字典表的大体流程就已经介绍完了,也许大家会有疑问

第 2 步调用 dd::execute_query() 执行 DDL,已经拿到了数据字典表的元数据。

 

为了区分,把这里拿到的元数据叫作备用元数据。

 

第 3 步根据备用元数据打开数据字典表,从表空间中读取到数据字典表的元数据。

 

同样为了区分,把这里拿到的元数据叫作原配元数据。

 

第 4 步从 m_core_registry 中删除备用元数据。第 5 步把原配元数据存入 m_core_registry。

数据字典表的备用元数据和原配元数据不是一样的吗?为什么还要用原配元数据替换备用元数据,这是不是多此一举?

我没有逐个对比备用元数据和原配元数据是否完全一样,这是个不小的工程。不过,既然源码中这么实现,那应该是有它的原因,只是我还没有发现。如果后面发现其中的原因,我会再补充到我的博客中。

6. 总结

要理解 MySQL 8.0 中的数据字典表,核心是理解以下 2 点:

 

  • 初始化数据目录时,数据字典表的元数据是怎么存放到数据字典表中的?

     

    这主要是借助了 Storage_adapter 类实例的 m_core_registry 属性。

    在创建数据字典表的过程中,先创建每个数据字典表,并把元数据临时存放到 m_core_registry 中,所有数据字典表都创建成功之后,最后再一次性把所有数据字典表的元数据保存到对应的数据字典表中。

     

  • MySQL 启动时,怎么用数据字典表的元数据打开数据字典表?

     

    这同时借助了硬编码在源码中的数据字典表定义,以及 Storage_adapter 类实例的 m_core_registry 属性。

    MySQL 启动过程中,先通过 Object_table 得到创建数据字典表的 DDL,调用 dd::execute_query() 执行 DDL,拿到元数据(备用原数据),把备用元数据临时存放到 m_core_registry 属性中,再通过备用元数据打开数据字典表。



Tags:MySQL   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,不构成投资建议。投资者据此操作,风险自担。如有任何标注错误或版权侵犯请与我们联系,我们将及时更正、删除。
▌相关推荐
MySQL 核心模块揭秘
server 层会创建一个 SAVEPOINT 对象,用于存放 savepoint 信息。binlog 会把 binlog offset 写入 server 层为它分配的一块 8 字节的内存里。 InnoDB 会维护自己的 savepoint...【详细内容】
2024-04-03  Search: MySQL  点击:(7)  评论:(0)  加入收藏
MySQL 核心模块揭秘,你看明白了吗?
为了提升分配 undo 段的效率,事务提交过程中,InnoDB 会缓存一些 undo 段。只要同时满足两个条件,insert undo 段或 update undo 段就能被缓存。1. 关于缓存 undo 段为了提升分...【详细内容】
2024-03-27  Search: MySQL  点击:(14)  评论:(0)  加入收藏
MySQL:BUG导致DDL语句无谓的索引重建
对于5.7.23之前的版本在评估类似DDL操作的时候需要谨慎,可能评估为瞬间操作,但是实际上线的时候跑了很久,这个就容易导致超过维护窗口,甚至更大的故障。一、问题模拟使用5.7.22...【详细内容】
2024-03-26  Search: MySQL  点击:(13)  评论:(0)  加入收藏
从 MySQL 到 ByteHouse,抖音精准推荐存储架构重构解读
ByteHouse是一款OLAP引擎,具备查询效率高的特点,在硬件需求上相对较低,且具有良好的水平扩展性,如果数据量进一步增长,可以通过增加服务器数量来提升处理能力。本文将从兴趣圈层...【详细内容】
2024-03-22  Search: MySQL  点击:(28)  评论:(0)  加入收藏
MySQL自增主键一定是连续的吗?
测试环境:MySQL版本:8.0数据库表:T (主键id,唯一索引c,普通字段d)如果你的业务设计依赖于自增主键的连续性,这个设计假设自增主键是连续的。但实际上,这样的假设是错的,因为自增主键不...【详细内容】
2024-03-10  Search: MySQL  点击:(12)  评论:(0)  加入收藏
准线上事故之MySQL优化器索引选错
1 背景最近组里来了许多新的小伙伴,大家在一起聊聊技术,有小兄弟提到了MySQL的优化器的内部策略,想起了之前在公司出现的一个线上问题,今天借着这个机会,在这里分享下过程和结论...【详细内容】
2024-03-07  Search: MySQL  点击:(31)  评论:(0)  加入收藏
MySQL数据恢复,你会吗?
今天分享一下binlog2sql,它是一款比较常用的数据恢复工具,可以通过它从MySQL binlog解析出你要的SQL,并根据不同选项,可以得到原始SQL、回滚SQL、去除主键的INSERT SQL等。主要...【详细内容】
2024-02-22  Search: MySQL  点击:(53)  评论:(0)  加入收藏
如何在MySQL中实现数据的版本管理和回滚操作?
实现数据的版本管理和回滚操作在MySQL中可以通过以下几种方式实现,包括使用事务、备份恢复、日志和版本控制工具等。下面将详细介绍这些方法。1.使用事务:MySQL支持事务操作,可...【详细内容】
2024-02-20  Search: MySQL  点击:(54)  评论:(0)  加入收藏
为什么高性能场景选用Postgres SQL 而不是 MySQL
一、 数据库简介 TLDR;1.1 MySQL MySQL声称自己是最流行的开源数据库,它属于最流行的RDBMS (Relational Database Management System,关系数据库管理系统)应用软件之一。LAMP...【详细内容】
2024-02-19  Search: MySQL  点击:(39)  评论:(0)  加入收藏
MySQL数据库如何生成分组排序的序号
经常进行数据分析的小伙伴经常会需要生成序号或进行数据分组排序并生成序号。在MySQL8.0中可以使用窗口函数来实现,可以参考历史文章有了这些函数,统计分析事半功倍进行了解。...【详细内容】
2024-01-30  Search: MySQL  点击:(55)  评论:(0)  加入收藏
▌简易百科推荐
MySQL 核心模块揭秘
server 层会创建一个 SAVEPOINT 对象,用于存放 savepoint 信息。binlog 会把 binlog offset 写入 server 层为它分配的一块 8 字节的内存里。 InnoDB 会维护自己的 savepoint...【详细内容】
2024-04-03  爱可生开源社区    Tags:MySQL   点击:(7)  评论:(0)  加入收藏
MySQL 核心模块揭秘,你看明白了吗?
为了提升分配 undo 段的效率,事务提交过程中,InnoDB 会缓存一些 undo 段。只要同时满足两个条件,insert undo 段或 update undo 段就能被缓存。1. 关于缓存 undo 段为了提升分...【详细内容】
2024-03-27  爱可生开源社区  微信公众号  Tags:MySQL   点击:(14)  评论:(0)  加入收藏
MySQL:BUG导致DDL语句无谓的索引重建
对于5.7.23之前的版本在评估类似DDL操作的时候需要谨慎,可能评估为瞬间操作,但是实际上线的时候跑了很久,这个就容易导致超过维护窗口,甚至更大的故障。一、问题模拟使用5.7.22...【详细内容】
2024-03-26  MySQL学习  微信公众号  Tags:MySQL   点击:(13)  评论:(0)  加入收藏
从 MySQL 到 ByteHouse,抖音精准推荐存储架构重构解读
ByteHouse是一款OLAP引擎,具备查询效率高的特点,在硬件需求上相对较低,且具有良好的水平扩展性,如果数据量进一步增长,可以通过增加服务器数量来提升处理能力。本文将从兴趣圈层...【详细内容】
2024-03-22  字节跳动技术团队    Tags:ByteHouse   点击:(28)  评论:(0)  加入收藏
MySQL自增主键一定是连续的吗?
测试环境:MySQL版本:8.0数据库表:T (主键id,唯一索引c,普通字段d)如果你的业务设计依赖于自增主键的连续性,这个设计假设自增主键是连续的。但实际上,这样的假设是错的,因为自增主键不...【详细内容】
2024-03-10    dbaplus社群  Tags:MySQL   点击:(12)  评论:(0)  加入收藏
准线上事故之MySQL优化器索引选错
1 背景最近组里来了许多新的小伙伴,大家在一起聊聊技术,有小兄弟提到了MySQL的优化器的内部策略,想起了之前在公司出现的一个线上问题,今天借着这个机会,在这里分享下过程和结论...【详细内容】
2024-03-07  转转技术  微信公众号  Tags:MySQL   点击:(31)  评论:(0)  加入收藏
MySQL数据恢复,你会吗?
今天分享一下binlog2sql,它是一款比较常用的数据恢复工具,可以通过它从MySQL binlog解析出你要的SQL,并根据不同选项,可以得到原始SQL、回滚SQL、去除主键的INSERT SQL等。主要...【详细内容】
2024-02-22  数据库干货铺  微信公众号  Tags:MySQL   点击:(53)  评论:(0)  加入收藏
如何在MySQL中实现数据的版本管理和回滚操作?
实现数据的版本管理和回滚操作在MySQL中可以通过以下几种方式实现,包括使用事务、备份恢复、日志和版本控制工具等。下面将详细介绍这些方法。1.使用事务:MySQL支持事务操作,可...【详细内容】
2024-02-20  编程技术汇    Tags:MySQL   点击:(54)  评论:(0)  加入收藏
MySQL数据库如何生成分组排序的序号
经常进行数据分析的小伙伴经常会需要生成序号或进行数据分组排序并生成序号。在MySQL8.0中可以使用窗口函数来实现,可以参考历史文章有了这些函数,统计分析事半功倍进行了解。...【详细内容】
2024-01-30  数据库干货铺  微信公众号  Tags:MySQL   点击:(55)  评论:(0)  加入收藏
mysql索引失效的场景
MySQL中索引失效是指数据库查询时无法有效利用索引,这可能导致查询性能显著下降。以下是一些常见的MySQL索引失效的场景:1.使用非前导列进行查询: 假设有一个复合索引 (A, B)。...【详细内容】
2024-01-15  小王爱编程  今日头条  Tags:mysql索引   点击:(87)  评论:(0)  加入收藏
站内最新
站内热门
站内头条