MySQL中的存储引擎及InnoDB简单介绍

 更新时间:2026年05月07日 08:52:02   作者:huangSir-devops  
存储引擎就是数据库服务中的文件系统,用户可以根据应用的需要选择存储和索引数据,本文给大家介绍MySQL中的存储引擎及InnoDB简单介绍,感兴趣的朋友跟随小编一起看看吧

概述

存储引擎是MySQL数据库底层软件组件,负责执行数据的存储和检索操作,是MySQL区别于其他数据库的核心特性之一。MySQL采用插件式存储引擎架构,不同存储引擎提供不同的存储机制、索引技术、锁定水平等功能,用户可以根据业务需求灵活选择。

通俗点讲:存储引擎决定了数据在磁盘上的存储方式和访问方式,不同的存储引擎实现了不同的存储和检索算法
存储引擎就是数据库服务中的文件系统,用户可以根据应用的需要选择存储和索引数据。

存储引擎的架构:

+-------------------------+
|    连接/会话层          |
+-------------------------+
|    SQL解析/优化层       |
+-------------------------+
|    存储引擎接口层       |
+-------------------------+
| InnoDB | MyISAM | Memory | ... |
+-------------------------+
  • 上层SQL层与存储引擎层通过标准接口交互,上层不需要关心存储引擎的具体实现
  • 不同存储引擎之间相互独立,各自实现自己的特性
  • 支持同一数据库中不同表使用不同存储引擎

存储引擎的简单运维操作

查看数据库中所有引擎种类:

mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)

查看数据库默认引擎

mysql> select @@default_storage_engine;
+--------------------------+
| @@default_storage_engine |
+--------------------------+
| InnoDB                   |
+--------------------------+
1 row in set (0.00 sec)

查看某张表的存储引擎

show create table 表名;

如果你想修改存储引擎

  • 全局修改
# 修改配置文件,然后重启mysql即可
vim /etc/my.cnf
# 修改下面的配置 
[mysqld]
default_storage_engine=InnoDB
  • 针对某一张表修改
#创建表时设置
create table xxx (id int) engine=innodb charset=utf8mb4;
#创建表之后设置
alter table xxx engine=myisam;
alter table world.xxx engine=innodb;

存储引擎分类

目前mysql有很多种存储引擎,但是99%的场景直接选择InnoDB:现在InnoDB已经非常成熟,性能比MyISAM更高,功能更全,除非有非常明确的理由,否则都用InnoDB。
但是为了学习,我们在这里还是简单说一下所有的存储引擎:

InnoDB

这是mysql5.5+版本中默认的存储引擎,其核心特性如下:

  • 事务支持:完全支持ACID特性,支持4种事务隔离级别,是需要事务支持的业务首选
  • 行级锁定:粒度更小的行锁,并发性能远高于表锁,适合高并发读写场景
  • MVCC多版本并发控制:读写不阻塞,大幅提升高并发场景下的性能
  • 外键约束:唯一支持外键的存储引擎,保证数据的一致性和完整性
  • 崩溃恢复:通过redo log和undo log实现 crash-safe,异常重启后数据不会丢失
  • 聚簇索引:数据和主键索引存储在一起,主键查询性能极高
  • 支持热备份:可以在服务运行时进行备份,不影响业务

其优缺点:

优点缺点
事务支持,数据安全性高空间占用较高,存储成本略高
行级锁,并发性能好不支持全文索引(MySQL 5.6+开始支持,但功能较弱)
崩溃恢复能力强批量插入性能略低于MyISAM
支持外键、MVCC维护成本略高

其适用场景

  • 绝大多数OLTP(在线事务处理)场景
  • 需要事务支持、数据一致性要求高的业务
  • 高并发读写的场景(电商、金融、社交等)
  • 对数据可靠性要求高的核心业务

MyISAM

这是MySQL 5.5之前默认引擎,现在版本已经很新了,使用这个存储引擎的公司应该已经很少了。核心特性如下:

  • 表级锁定:读共享、写独占,写操作会锁全表,并发写入性能差
  • 全文索引:原生支持全文索引,适合全文搜索场景
  • 压缩存储:支持压缩表,占用空间小,适合只读数据
  • 查询性能高:在数据量不大、读写比很高的场景下,查询性能优于InnoDB
  • 不支持事务、不支持行锁和外键、崩溃后无法安全恢复,可能丢失数据

优缺点如下:

优点缺点
占用空间小,存储成本低不支持事务,数据安全性差
只读场景下性能极高表级锁,并发写入性能差
全文索引支持崩溃后数据易丢失
维护简单,资源消耗低不支持外键、行锁

其适用场景

  • 非核心的只读或者读多写极少的场景
  • 数据可以通过其他方式恢复的业务(比如统计报表、日志归档)
  • 需要全文搜索的场景(现在更推荐用Elasticsearch替代)
  • 对性能要求极高、数据可靠性要求低的非核心场景

Memory(HEAP)

这是一个将数据存储在内存中的引擎,现在基本都是使用redis做缓存,所以这个存储引擎使用极低,了解即可,其核心特性:

  • 数据存储在内存中:访问速度极快,响应时间微秒级
  • 默认哈希索引:等值查询性能极高
  • 表级锁定:并发写入性能差
  • 服务重启后数据全部丢失
  • 不支持TEXT、BLOB等大字段,varchar最大长度65535
  • 内存资源有限,不适合存储大量数据

适用场景

  • 临时数据存储(比如 session 数据、一次性统计数据)
  • 缓存场景(热点数据缓存,替代Redis的轻量级方案)
  • 高频读、低频写的小数据量场景

Archive

这款引擎适合存储海量的归档数据,例如日志数据等,但是这种类型的数据基本都是用elasticsearch存储,所以实际工作中,这款引擎使用率也极低,了解即可。
核心特性:

  • 高压缩比存储:采用zlib压缩,空间占用仅为InnoDB的1/5~1/10
  • 高写入性能:支持批量插入,写入性能极高
  • 仅支持INSERT和SELECT操作,不支持UPDATE、DELETE
  • 不支持索引(除了自增ID索引)
  • 不支持事务

适用场景

  • 日志数据归档、历史数据冷存储
  • 不需要修改的海量数据存储场景
  • 写入后只做批量查询的场景

CSV

这款存储引擎适合小数据量,适合将外部CSV格式数据到MySQL,现在一般不使用这款引擎,了解即可。
核心特性如下:

  • 数据以CSV文本格式存储,可以直接用Excel等工具打开编辑
  • 支持导入导出CSV格式数据
  • 不支持索引
  • 不支持NULL值
  • 不支持事务

适用场景

  • 数据交换、导入导出中间格式
  • 快速导入外部CSV格式数据到MySQL
  • 简单的小数据量存储场景

Blackhole

这款引擎简称黑洞引擎,正如名字一样,写入的数据会被吞掉(丢弃),不实际存储,读取数据永远返回空值,但是binlog日志会正常记录写入的SQL,一般作为主从复制的中继节点,很少使用,了解即可。

适用场景

  • 作为主从复制的中继节点,过滤不需要同步的数据
  • 性能测试时的压测目标,验证写入性能
  • 测试二进制日志功能

Merge(MRG_MyISAM)

这款引擎会把多个结构相同的MyISAM表合并成一个逻辑表,透明查询和写入,不需要关心底层分表,仅支持MyISAM表,功能十分有限,不支持事务

适用场景

  • 简单的分表场景,合并多个历史数据表
  • 日志分表后的统一查询场景

Federated

这款引擎可以访问远程MySQL数据库中的表,本地不存储数据,所有操作转发到远程节点,因为网络开销较大,所以性能较低,稳定性一般,很多特性不支持

适用场景

  • 跨库访问、数据联邦查询场景
  • 临时的跨实例数据访问需求

NDB Cluster

这款引擎主要用于电信、金融等需要极高可用性的核心场景,但是在此类场景下一般不使用mysql,所以这个引擎使用极低,知道即可。

核心存储引擎对比(InnoDB vs MyISAM)

此问题一般都是面试的时候会问,在实际工作中一般都是无脑选择InnoDB,当然一些极特殊情况例外。

对比维度InnoDBMyISAM
事务支持✅ 支持ACID❌ 不支持
锁机制✅ 行级锁、gap锁、next-key lock❌ 仅表级锁
MVCC✅ 支持❌ 不支持
外键✅ 支持❌ 不支持
索引结构✅ 聚簇索引❌ 非聚簇索引
崩溃恢复✅ 支持crash-safe❌ 易丢失数据
全文索引⚠️ 5.6+支持,功能弱✅ 原生支持,功能强
存储空间较高,支持压缩较低,压缩比更高
内存占用较高较低
批量写入性能一般更高
并发性能极高(支持高并发读写)低(写操作阻塞所有操作)
适用场景绝大多数OLTP核心场景只读、非核心场景

InnoDB详解

磁盘结构组成

在磁盘存储结构中,会使用表空间模式进行数据信息的管理,经常提到的段,区,页概念也是属于表空间的逻辑结构。
表空间的概念源于Oracle数据库,最初的目的是为了能够更好的做存储的扩容,因此数据库的表空间技术类似磁盘管理的lvm技术

共享表空间

共享表空间是ibdata1这个文件

作用:

  • MySQL8.0.20之前存储Double write buffer信息、changer buffer信息
  • MySQL8.0.20之后只存储changer buffer信息,Double write buffer信息被独立出来了
  • MySQL5.7版本存储全局数据字典信息、undo回滚日志、Double write buffer信息、changer buffer以及系统数据

共享表空间的运维操作命令:

  • 查看共享表空间
#查看共享表空间
mysql> select @@innodb_data_file_path;
+-------------------------+
| @@innodb_data_file_path |
+-------------------------+
| ibdata1:12M:autoextend  |
+-------------------------+
1 row in set (0.00 sec)

#查看共享表空间默认扩展大小,默认每次扩展64M
mysql> select @@innodb_autoextend_increment;
+-------------------------------+
| @@innodb_autoextend_increment |
+-------------------------------+
|                            64 |
+-------------------------------+
1 row in set (0.00 sec)
  • 共享表空间的扩容操作
# 编写数据库配置文件信息
vim /etc/my.cnf
[mysqld]
innodb_data_file_path=ibdata1:12M;ibdata2:100M;ibdata3:100M:autoextend
-- 需要注意的是ibdata1文件大小必须和实际数据库要存储的数据相匹配,否则会出现如下报错信息
 [ERROR] [MY-012264] [InnoDB] The innodb_system data file './ibdata1' is of a different size 768 pages (rounded down to MB) than the 4864 pages specified in the .cnf file!
-- 表示ibdate1指定大小超过了原有ibdata1实际的大小尺寸
  • 共享表空间的初始设置方式
# 初始化配置文件
root@master:~# vim /etc/my.cnf
[mysqld]
innodb_data_file_path=ibdata1:100M;ibdata2:100M;ibdata3:100M:autoextend
# 模拟初始化操作命令
root@master:~# mysqld --initialize-insecure --user=mysql --basedir=/usr/local/mysql --datadir=/data/3306/data
# 模拟初始化重启服务
root@master:~# /etc/init.d/mysqld start

生产环境下,共享表空间容量推荐:

MySQL版本共享表空间数量初始推荐大小额外配置
5.72~3 个512M / 1G最后一个开启自动扩展
8.01 个512M / 1G无需多文件,默认管理

独立表空间

独立表空间是以ibd结尾的文件,例如:

其作用主要是存储表中的数据信息(索引信息 表结构 表中行数据)。

独立表空间操作

#表示每个表就是一个独立文件,进行数据信息的独立存储,不建议进行修改,如果改为0就是所有数据统一存储在共享表空间
select @@innodb_file_per_table;
+---------------------------------+
| @@innodb_file_per_table |
+---------------------------------+
|                                 1 |
+---------------------------------+
#设置为0表示利用共享表空间存储用户数据 1表示利用独立表空间存储用户数据
set global innodb_file_per_table=0

利用独立表空间进行数据快速迁移

源端 3306/test/t100w --> 目标端 3307/test/t100w

# 步骤一:锁定源端t100w表
# 给t100w表加写数据锁
mysql > lock tables test.t100w write;
# 获取创建表结构数据信息
mysql > show create table test.t100w;
CREATE TABLE `t100w` (
  `id` int DEFAULT NULL,
  `num` int DEFAULT NULL,
  `k1` char(2) DEFAULT NULL,
  `k2` char(4) DEFAULT NULL,
  `dt` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  KEY `idx` (`k1`,`k2`,`num`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci |
#步骤二:目标端创建oldboy库和t100w空表
# 创建新的数据库
mysql> create database test;
# 创建新的数据表
mysql > CREATE TABLE `t100w` (
  `id` int DEFAULT NULL,
  `num` int DEFAULT NULL,
  `k1` char(2) DEFAULT NULL,
  `k2` char(4) DEFAULT NULL,
  `dt` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  KEY `idx` (`k1`,`k2`,`num`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
#步骤三:删除目标端空的表空间文件
# 删除t100w表的ibd数据文件信息,但是保留t100w的frm,ibdata1中关于t100w的系统数据
mysql> alter table test.t100w discard tablespace;
#操作步骤四:拷贝源端ibd文件到目标端目录,并设置权限
root@master: ~# cp /data/3306/data/test/t100w.ibd /data/3307/data/test/
root@master: ~# chown -R mysql.mysql /data/*
#操作步骤五:导入表空间
# 在目标端加载识别迁移过来的数据文件信息
mysql> alter table test.t100w import tablespace;
# 查看数据表中是否有迁移过来的数据信息
mysql> select count(*) from t100w;
+----------+
| count(*) |
+----------+
|  1000000 |
+----------+
1 row in set (0.04 sec)
#步骤六:解锁源端数据库
mysql> unlock tables;

undo表空间

在数据库5.7版本中,默认存储在共享表空间中(ibdata);在数据库8.0版本后,默认就是独立存储了(undo_001-undo_002)

undo表空间的作用:
在数据库5.7版本中,默认存储在共享表空间中(ibdata);在数据库8.0版本后,默认就是独立存储了(undo_001-undo_002),在实际生产环境中,建议在5.7版本之后,都将undo表空间进行独立文件存储。

查看临时表空间相关命令

# 设置undo表空间文件数量(默认2个文件)
mysql> select @@innodb_undo_tablespaces;
+---------------------------+
| @@innodb_undo_tablespaces |
+---------------------------+
|                         2 |
+---------------------------+
1 row in set (0.00 sec)
# 设置undo表空间文件大小(字节)
mysql> select @@innodb_max_undo_log_size;
+----------------------------+
| @@innodb_max_undo_log_size |
+----------------------------+
|                 1073741824 |
+----------------------------+
1 row in set (0.00 sec)
# 设置undo表空间回收机制(默认开启)
mysql> select @@innodb_undo_log_truncate;
+----------------------------+
| @@innodb_undo_log_truncate |
+----------------------------+
|                          1 |
+----------------------------+
1 row in set (0.00 sec)
# 设置undo表空间信息检测次数 (128次)
mysql> select @@innodb_purge_rseg_truncate_frequency; 
+----------------------------------------+
| @@innodb_purge_rseg_truncate_frequency |
+----------------------------------------+
|                                    128 |
+----------------------------------------+
1 row in set (0.00 sec)

修改undo表空间配置

# 关闭数据库服务程序,清理数据库服务数据目录
root@master:~# vim /etc/my.cnf
[mysqld]
innodb_undo_tablespaces=3
innodb_max_undo_log_size=128M
innodb_undo_log_truncate=ON
innodb_purge_rseg_truncate_frequency=32

临时表空间

临时表空间可以存储在内存和磁盘上,主要用于存储临时的表信息,主要是在使用group by,order by,having,union all,子查询等情况都会使用临时表;
重新加载临时数据时,可以从临时表空间文件中直接读取(顺序IO读取数据)

临时表空间查看操作命令

临时表空间默认初始化大小12M,不够用会自动扩容,每次扩容64M

mysql> select @@innodb_temp_data_file_path;
+------------------------------+
| @@innodb_temp_data_file_path |
+------------------------------+
| ibtmp1:12M:autoextend        |
+------------------------------+
1 row in set (0.00 sec)
mysql> select @@innodb_autoextend_increment;
+-------------------------------+
| @@innodb_autoextend_increment |
+-------------------------------+
|                            64 |
+-------------------------------+
1 row in set (0.00 sec)

建议初始化时,设定好临时表空间,mysql5.7版本建议设置2~3个临时表空间,大小建议512M或1G,最后一个定制为自动扩展,mysql8.0版本建议设置1个即可,大小建议512M或者1G。

vim /etc/my.cnf
[mysqld]
innodb_temp_data_file_path=ibtmp1:12M;ibtmp2:120M:autoextend:max:500M

redo事物日志

redo log属于事务重做日志文件,主要用于记录内存数据页的变化(记录在内存中对数据页的操作信息),都会以日志文件方式记录;

查看redo事物日志

mysql> show variables like '%innodb_log_file%';
+---------------------------+----------+
| Variable_name             | Value    |
+---------------------------+----------+
| innodb_log_file_size      | 50331648 |
| innodb_log_files_in_group | 2        |
+---------------------------+----------+
2 rows in set (0.01 sec)

在实际生产中,文件大小建议512M-1G,应用组数设置2-4

# 编写数据库配置文件信息
vim /etc/my.cnf
[mysqld]
innodb_log_file_size=100M
innodb_log_files_in_group=3

ib_buffer_pool预热文件

ib_buffer_pool预热文件可用于缓冲和缓存,可以存储‘热’数据页,减少物理IO性能损耗。

内存结构组成

其内存架构主要由缓冲池和日志缓冲组成,其结构如下:

+-------------------------+
| Buffer Pool(缓冲池)   |
|  - 数据页缓存           |
|  - 索引页缓存           |
|  - 自适应哈希索引       |
|  - 插入缓冲             |
|  - 锁信息、数据字典等   |
+-------------------------+
| Log Buffer(日志缓冲)  |
+-------------------------+

Buffer Pool

Buffer Pool是InnoDB最重要的内存组件,默认占用物理内存的50%~70%,缓存热点数据和索引,减少磁盘IO。采用LRU算法管理缓存页。是MySQL中最大的、最重要的内存区域。

查看buffer pool

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                1073741824 |
+---------------------------+
1 row in set (0.00 sec)

设置buffer pool

# buffer pool默认内存空间大小为128M,生产建议大小可以设置为物理内存总量的50%~80%
方式一:
set global innodb_buffer_pool_size=268435456;
方式二:
vim /etc/my.cnf
[mysqld]
innodb_buffer_pool_size=256M

Log Buffer

缓存redo log日志,定期刷入磁盘,减少日志写入IO。Log Buffer建议设置64M

查看log buffer

mysql> select @@innodb_log_buffer_size;
+--------------------------+
| @@innodb_log_buffer_size |
+--------------------------+
|                 16777216 |
+--------------------------+
1 row in set (0.00 sec)

修改log buffer

方式一:
set global innodb_log_buffer_size=33554432;
方式二:
vim /etc/my.cnf
[mysqld]
innodb_log_buffer_size=32M

InnoDB性能优化

  • 缓冲池配置:innodb_buffer_pool_size设置为物理内存的50%~70%,越大越好
  • 日志配置:innodb_log_file_size设置为1GB~4GB,innodb_log_buffer_size设置为64MB
  • 刷新策略:innodb_flush_log_at_trx_commit=1(最高安全性),或2(最高性能,最多丢失1秒数据)
  • IO优化:使用SSD存储,innodb_io_capacity设置为磁盘的IOPS能力
  • 索引优化:合理设计索引,避免回表,使用覆盖索引

到此这篇关于MySQL中的存储引擎及InnoDB简单介绍的文章就介绍到这了,更多相关MySQL中的存储引擎及InnoDB简单介绍内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • MySQL组合索引与最左匹配原则详解

    MySQL组合索引与最左匹配原则详解

    这篇文章主要给大家介绍了关于MySQL组合索引与最左匹配原则的相关资料,文中通过示例代码介绍的非常详细,对大家学习或者使用Mysql具有一定的参考学习价值,需要的朋友们下面来一起学习学习吧
    2019-03-03
  • Mysql常见bug及解决方案超详细讲解

    Mysql常见bug及解决方案超详细讲解

    在使用MySQL的过程中,相比大家都踩过不少坑,下面这篇文章主要给大家介绍了关于Mysql常见bug及解决方案超详细讲解的相关资料,文中介绍的非常详细,需要的朋友可以参考下
    2023-06-06
  • Navicat连接虚拟机mysql常见错误问题及解决方法

    Navicat连接虚拟机mysql常见错误问题及解决方法

    这篇文章主要介绍了Navicat连接虚拟机mysql常见错误问题及解决方法,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
    2020-11-11
  • 使用Shell脚本进行MySql权限修改的实现教程

    使用Shell脚本进行MySql权限修改的实现教程

    原先数据配置文件中有bind-address=127.0.0.1,注释掉此配置后,原数据库中默认带%root的权限,现在需要通过脚本实现白名单列表中的ip添加权限允许访问数据库,本文给大家介绍了使用Shell脚本进行MySql权限修改的实现教程,需要的朋友可以参考下
    2024-03-03
  • mysql重复索引与冗余索引实例分析

    mysql重复索引与冗余索引实例分析

    这篇文章主要介绍了mysql重复索引与冗余索引,简单说明了重复索引与冗余索引的概念、应用场景并结合实例形式分析了mysql重复索引与冗余索引相关操作技巧,需要的朋友可以参考下
    2019-07-07
  • MySQL安装第四步报错(initializing database报错)的图文解决方法

    MySQL安装第四步报错(initializing database报错)的图文解决方法

    这篇文章主要给大家介绍了关于MySQL安装第四步报错(initializing database报错)的解决方法,"initializing database" 通常出现在安装MySQL的过程中,表示MySQL数据库初始化过程中遇到了问题,需要的朋友可以参考下
    2024-06-06
  • 哪些情况会导致 MySQL 索引失效

    哪些情况会导致 MySQL 索引失效

    这篇文章主要介绍了哪些情况会导致MySQL索引失效,文章围绕主题展开详细的内容介绍,具有一定的参考价值,需要的朋友可以参考一下
    2022-07-07
  • Mysql获取指定时间范围数据的各种实例

    Mysql获取指定时间范围数据的各种实例

    最近在做管理后台报表时,给定一个日期范围,查出库中这个日期范围内的每一天数据,下面这篇文章主要给大家介绍了关于Mysql获取指定时间范围数据的相关资料,需要的朋友可以参考下
    2023-05-05
  • MySql获取当前时间并转换成字符串的实现

    MySql获取当前时间并转换成字符串的实现

    本文主要介绍了MySql获取当前时间并转换成字符串的实现,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2022-07-07
  • MySQL 8.0找不到 my.ini 配置文件(并开启 Binlog 监听)

    MySQL 8.0找不到 my.ini 配置文件(并开启 Binlog 

    本文主要介绍了MySQL 8.0找不到 my.ini 配置文件(并开启 Binlog 监听),文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2025-06-06

最新评论