MySQL性能调优：Mysql8高频面试题汇总
1，主键和唯一键有什么区别？
主键不能重复，不能为空，唯一键不能重复，可以为空。
建立主键的目的是让外键来引用。
一个表最多只有一个主键，但可以有很多唯一键
2，MySQL常用的存储引擎有哪些，他们的区别是什么？
Mysql的存储引擎有：InnoDB、MyISAM、Memory、CSV、ARCHIVE等。
最常用的 InnoDB 和 MyISAM 的区别：
1）事务支持：InnoDB支持ACID事务，提供提交、回滚和崩溃恢复能力，适用于需保证数据一致性的场景；MyISAM不支持事务，无法回滚操作。
2）锁机制方面：
InnoDB支持行级锁，仅锁定操作涉及的数据行，适合高并发写操作。
MyISAM使用表级锁，写操作会锁定整个表，导致并发性能下降。
3）索引类型：
InnoDB采用聚簇索引，索引与数据共同存储于.ibd文件，主键索引叶子节点直接存数据行。
MyISAM采用非聚簇索引，索引与数据分离存储于.MYI和.MYD文件，索引叶子节点存储数据地址。
4）外键支持：InnoDB支持外键约束，MyISAM不支持
总结：InnoDB支持事务处理、行级锁定和外键，适用于需要高并发和事务处理的场景。MyISAM不支持事务和行级锁定，但读取速度快，适用于查询密集型的场景
3，说说对SQL语句优化有哪些方法？（选择几条）
1）Where子句中：where表之间的连接必须写在其他Where条件之前，那些可以过滤掉最大数量记录的条件必须写在Where子句的末尾.HAVING最后。
2）用EXISTS替代IN、用NOT EXISTS替代NOT IN。
3） 避免在索引列上使用计算。
4）避免在索引列上使用IS NULL和IS NOT NULL。
5）对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
6）尽量避免在 where 子句中，对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描。
7）应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。
4，如何提高insert的性能？
答：有如下方法：
1）合并多条 insert 为一条，即： insert into t values(a,b,c), (d,e,f) ,
原因分析：主要原因是多条insert合并后日志量（MySQL的binlog和innodb的事务日志） 减少了，降低日志刷盘的数据量和频率，从而提高效率。通过合并SQL语句，同时也能减少SQL语句解析的次数，减少网络传输的IO。
2）修改参数bulk_insert_buffer_size， 调大批量插入的缓存；
3）设置 innodb_flush_log_at_trx_commit = 0 ，相对于 innodb_flush_log_at_trx_commit = 1 可以十分明显的提升导入速度。
备注：innodb_flush_log_at_trx_commit，参数对 InnoDB Log 的写入性能有非常关键的影响。该参数可以设置为a，b，c，解释如下：
0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步操作，但是每个事务的commit并不会触发任何log buffer 到log file 的刷新或者文件系统到磁盘的刷新操作;
在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步;
事务提交会触发log buffer 到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操作。
4）手动使用事务
因为mysql默认是autocommit的，这样每插入一条数据，都会进行一次commit；所以，为了减少创建事务的消耗，我们可用手工使用事务，即START TRANSACTION;insert 。。,insert。。 commit；即执行多个insert后再一起提交；一般1000条insert 提交一次。
5，什么是覆盖索引？什么是回表查询？
InnoDb存储引擎有两大类索引聚集索引和普通（辅助/二级）索引，聚簇索引的叶子节点存储行记录，因此InnoDb必须要有聚簇索引且仅有一个聚簇索引，而普通索引的叶子节点只存储索引值和主键值，所以，通过聚簇索引一次性能获取所有列的数据，普通索引一般不行。
当我们SQL语句的中列无法在普通索引中获得时，就需要主键值到聚簇索引中获取相关的数据，这个过程就被称为回表。
而如果我们使用联合索引，使得SQL所需的所有列数据在这个索引上就能获得时，我们称为发生了索引覆盖或者覆盖索引。
6，什么是三星索引？
对于一个查询而言，一个三星索引，可能是其最好的索引。
如果查询使用三星索引，一次查询通常只需要进行一次磁盘随机读以及一次窄索引片的扫描，因此其相应时间通常比使用一个普通索引的响应时间少几个数量级。
一个查询相关的索引行是相邻的或者至少相距足够靠近的则获得一星；
如果索引中的数据顺序和查找中的排列顺序一致则获得二星；
如果索引中的列包含了查询中需要的全部列则获得三星。
三星索引在实际的业务中如果无法同时达到，一般我们认为第三颗星最重要，第一和第二颗星重要性差不多，根据业务情况调整这两颗星的优先度。
7，大表关联查询优化
一个6亿的表a，一个3亿的表b，通过tid关联，你如何最快的查询出满足条件的第50000到第50200中的这200条数据记录。
1、如果A表TID是自增长,并且是连续的,B表的ID为索引
select * from a,b where a.tid = b.id and a.tid>500000 limit 200;
2、如果A表的TID不是连续的,那么就需要使用覆盖索引.TID要么是主键,要么是辅助索引,B表ID也需要有索引。
select * from b, (select tid from a limit 50000,200) a
where b.id = a .tid;
8，[SELECT *] 和[SELECT 全部字段]有何优缺点？
1> 前者要解析数据字典，后者不需要
2> 结果输出顺序，前者与建表列顺序相同，后者按指定字段顺序。
3> 表字段改名，前者不需要修改，后者需要改
4> 后者可以建立索引进行优化，前者无法优化
5> 后者的可读性比前者要高
9，请概述下什么是MySQL的分区表
表分区，是指根据一定规则，将数据库中的一张表分解成多个更小的，容易管理的部分。从逻辑上看，只有一张表，但是底层却是由多个物理分区组成。
1）表分区与分表的区别
分表：指的是通过一定规则，将一张表分解成多张不同的表。比如将用户订单记录根据时间成多个表。
分表与分区的区别在于：分区从逻辑上来讲只有一张表，而分表则是将一张表分解成多张表。
2）表分区的好处？
a，存储更多数据。分区表的数据可以分布在不同的物理设备上，从而高效地利用多个硬件设备。和单个磁盘或者文件系统相比，可以存储更多数据
b，优化查询。在where语句中包含分区条件时，可以只扫描一个或多个分区表来提高查询效率；涉及sum和count语句时，也可以在多个分区上并行处理，最后汇总结果。
c，分区表更容易维护。例如：想批量删除大量数据可以清除整个分区。
3）分区表的限制因素
一个表最多只能有1024个分区
如果分区字段中有主键或者唯一索引的列，那么多有主键列和唯一索引列都必须包含进来。即：分区字段要么不包含主键或者索引列，要么包含全部主键和索引列。
分区表中无法使用外键约束
MySQL的分区适用于一个表的所有数据和索引，不能只对表数据分区而不对索引分区，也不能只对索引分区而不对表分区，也不能只对表的一部分数据分区。
4）分区表的类型
RANGE分区： 这种模式允许将数据划分不同范围。例如可以将一个表通过年份划分成若干个分区
LIST分区： 这种模式允许系统通过预定义的列表的值来对数据进行分割。按照List中的值分区，与RANGE的区别是，range分区的区间范围值是连续的。
HASH分区 ：这中模式允许通过对表的一个或多个列的Hash
Key进行计算，最后通过这个Hash码不同数值对应的数据区域进行分区。例如可以建立一个对表主键进行分区的表。
KEY分区 ：上面Hash模式的一种延伸，这里的Hash
Key是MySQL系统产生的。
Column分区：需要和RANGE和List结合，支持字符串和日期的分区，也支持多列分区。
复合分区/子分区：分区之下还可以再分区。
5）在实际工作中用分区表比较少
分区表，分区键设计不太灵活，如果不走分区键，很容易出现全表锁。
自己分库分表，自己掌控业务场景与访问模式，可控。分区表，研发写了一个sql，都不确定mysql是怎么操作的，不太可控。
分区表无论怎么分，都是在一台机器上，天然就有性能的上限。
10，说几条MySQL对SQL的执行做的优化手段
1）对SQL语句的优化，避免低效查询；
减少 SELECT *：仅查询必需字段，降低I/O与网络开销。用 JOIN 替代子查询：将 IN/EXISTS 子查询改写为 JOIN（如 SELECT ... FROM t1 JOIN t2 ON t1.id=t2.id）。对IN子查询会进行物化、物化表转连接查询、转换为半连接等方式进行。
2）合理使用索引。
在表字段上合理使用索引，如主键索引、唯一索引、联合索引等。及索引的使用规则。最左前缀匹配：联合索引需从最左列连续使用（如索引 (a,b,c)，WHERE a=1 AND b=2 有效，WHERE b=2 无效。覆盖索引：查询字段全部在索引中时，避免回表（如 SELECT a,b FROM tb WHERE a=1，索引 (a,b)）。前缀索引：对长字符串列使用 INDEX(col_name(N)) 减少存储。使用索引需要避免避免隐式类型转换，范围查询后索引失效等。
3）配置优化
如合理设置nnodb_buffer_pool_size 缓冲池，一般为物理内存的 70%~80%，减少磁盘I/O。事务及锁方面，拆分大事务，减少锁竞争，高并发场景下，读操作分流到从库。
4）架构方面
对业务体量大，数据量大的场景，考虑使用主从架构设计，最常见的为一主多从架构，实现主写从读，读写分离，并且从库使用负载均衡。针对热点数据，最冷热处理，热点数据引入Redis缓存，降低数据库查询频次。针对单表数据量大，做分表分库，可 水平分库分表（如按ID哈希、时间分段分表等）。
11，说说InnoDB引擎的四大特性？
InnoDB的四大特性是：插入缓冲(Insert Buffer)、二次写(Double Write)、自适应哈希索引(Adaptive Hash Index)和预读(Read Ahead)，这些特性共同优化了数据库的写入性能、可靠性及查询效率。
插入缓冲（Insert Buffer / Change Buffer），它的作用是优化非唯一二级索引的写入性能。原理：
将非聚集索引的插入/更新操作暂存于内存缓冲池（而非直接写磁盘）
定期合并多个操作到索引页，减少随机I/O。生效条件：非唯一索引、索引页不在缓冲池中。
二次写（Double Write），作用是为防止数据页写入不完整（Partial Page Write）。原理：
数据页刷盘前，先顺序写入共享表空间的连续区域（固定2MB）。
再将数据写入实际表空间文件。价值：崩溃恢复时可从二次写区还原损坏页。
自适应哈希索引（Adaptive Hash Index），可自动提升高频查询效率，实现原理：
监控索引查询模式，对频繁访问的索引键建立内存哈希索引
哈希查找时间复杂度降至O(1)（原B+树为O(log n)）。限制：仅适用于等值查询（如WHERE id=123）。
预读（Read Ahead），可以减少磁盘I/O次数，提升顺序扫描性能。原理：
线性预读：按页顺序提前加载后续数据（innodb_read_ahead_threshold控制）
随机预读：预测热点数据页提前加载（默认关闭，易影响性能）
12，redolog和binlog的区别？
维度 | redo log | binlog |
生成层级 | InnoDB 引擎层实现（引擎特有） | MySQL Server 层实现（所有引擎通用） |
日志类型 | 物理日志：记录数据页的修改（如“在XX页修改YY字段”） | 逻辑日志：记录原始的 SQL 语句（如 |
写入方式 | 循环写：固定大小文件（如 | 追加写：文件达到阈值后创建新文件，旧日志保留 |
核心功能 | 实现 crash-safe：确保事务持久性，崩溃后恢复未刷盘数据 | 数据归档与复制：主从同步、数据恢复（如 |
事务一致性 | 与事务绑定，支持崩溃恢复原子性 | 依赖 |
应用场景
redo log：
InnoDB 崩溃恢复（如断电后重启自动修复）。
缓冲池（Buffer Pool）与磁盘间的数据一致性保障。
binlog：
主从复制（Slave 重放 binlog 同步数据）。
数据恢复（按时间点恢复误删数据）
总结
redo log：引擎层物理日志，核心解决数据持久化与崩溃恢复。
binlog：服务层逻辑日志，核心服务于数据归档与系统扩展（如主从复制）。
13，MySQL崩溃后恢复为什么不用binlog？
MySQL崩溃后恢复主要依赖redo log而非binlog，核心原因在于两者在日志性质、恢复机制和事务保障上的本质差异，根本原因：binlog不具备crash-safe能力。
大致概括：binlog 是用作人工恢复数据，redo log 是 MySQL 自己使用，用于保证在数据库崩溃时的事务持久性。
binlog记录的是逻辑操作，但无法感知数据页的物理状态。即使binlog已记录某事务的SQL，也无法确认该事务对应的数据是否已写入磁盘。若仅用binlog恢复，可能导致：
> 数据丢失：已提交事务的修改未刷盘（仅存在于内存）；
> 数据错乱：未提交事务的修改被错误恢复
redo log是引擎层为crash-safe设计的物理日志，而binlog是服务层为数据复制设计的逻辑日志。两者分工明确，binlog在崩溃恢复中仅作为XA事务一致性的辅助验证，核心恢复工作必须由redo log完成。
14，MySQL如何实现事务的ACID？
MySQL 通过 InnoDB 存储引擎的核心机制实现事务的 ACID 特性，具体实现原理如下：
原子性（Atomicity），事务的处理要么全部生效，要么全部回滚。实现机制：
1）Undo Log（回滚日志）：
事务修改数据前，先将原始数据拷贝到 Undo Log。
若事务失败或主动回滚，反向应用 Undo Log 恢复原始数据。
2）事务状态管理：
每个事务绑定唯一 transaction_id，崩溃恢复时通过 Redo/Undo Log 回滚未提交的事务。
隔离性（Isolation），多个并发事务同时执行时互不干扰。实现机制：
1）锁机制：
行级锁（Record Lock）：锁定单行记录。
间隙锁（Gap Lock）：锁定索引范围，防止幻读（RR 隔离级别）。
Next-Key Lock：行锁 + 间隙锁组合。
2）MVCC（多版本并发控制）：
每条记录隐藏 DB_TRX_ID（事务ID）和 DB_ROLL_PTR（回滚指针）。
读操作基于 Read View 判断数据可见性（仅读取已提交的事务修改）。
持久性（Durability），通过事务修改完成的数据永久保存。实现机制：
1）Redo Log（重做日志）：
事务提交前，先将修改按页写入 Redo Log（顺序 I/O 高效刷盘）。
崩溃恢复时重放 Redo Log 恢复未落盘数据。
2）Force-Log-at-Commit 策略：
事务提交时 Redo Log 必须刷盘（innodb_flush_log_at_trx_commit=1确保）。
一致性（Consistency），数据满足完整性约束（外键、唯一索引等）。
实现机制：原子性+隔离性+持久性的综合结果：前三者保障数据的逻辑一致。
辅助机制：
双写缓冲区（Double Write）：防止页断裂导致数据损坏。
InnoDB 约束检查：事务中实时验证外键、唯一键等约束。
15，什么是当前读和快照读？
当前读
就像select lock in share mode（共享锁）, select for update; update, insert ,delete（排他锁）等这样的操作都属于当前读，它读取的是库中记录最新的版本，在读取时，还要保证其他的并发事务不能修改当前的记录，这样会对读取记录进行加锁的。属于悲观锁的实现。
快照读
我们使用不加锁的select操作，就属于快照读，即不加锁实现的非阻塞读；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，即MVCC。
16，什么是MVCC？
MVCC (Multi-Version Concurrency Control) ，叫做基于多版本的并发控制协议。他是和LBCC（Lock-Based Concurrency Control）基于锁的并发控制概念是相对的。MVCC是乐观锁的一种实现方式，它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。
MVCC最大的好处：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大地增加了系统的并发性能，现阶段几乎所有的RDBMS包括MySQL，都支持了MVCC。
17，MVCC的底层实现原理是什么？
MVCC实现原理主要是依赖记录中的隐式字段，undo日志，Read View 来实现的。
MySQL中每行记录除了我们自定义的字段外，还有数据库隐式定义的DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID等字段。DB_TRX_ID是最近修改(修改/插入)事务ID，记录创建这条记录/最后一次修改该记录的事务ID。DB_ROLL_PTR，回滚指针，用于配合undo日志，指向这条记录的上一个版本。
不同事务或者相同事务的对同一记录的修改，会导致该记录的undo log成为一条记录版本线性表，也就是版本链。
事务进行快照读操作的时候产生一个Read View，记录并维护系统当前活跃事务的ID，因为当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以最新的事务，ID值越大。
Read View主要是将要被修改的数据的最新记录中的DB_TRX_ID（即当前事务ID）取出来，与系统当前其他活跃事务的ID去对比（由Read View维护），如果DB_TRX_ID跟Read View的属性做了某些比较，不符合可见性，那就就通过DB_ROLL_PTR回滚指针去取出Undo Log中的DB_TRX_ID再比较，即遍历链表的DB_TRX_ID（从链首到链尾，即从最近的一次修改查起），直到找到满足特定条件的DB_TRX_ID, 那么这个DB_TRX_ID所在的旧记录就是当前事务能看见的最新老版本。
RC,RR级别下Read View生成时机的不同，造成RC,RR级别下快照读的结果的不同。RC隔离级别下，是每个快照读都会生成并获取最新的Read View，也就是说事务中，每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因；而在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见。
18，什么是锁？MySQL 中提供了几类锁？
锁是实现数据库并发控制的重要手段，可以保证数据库在多人同时操作时能够正常运行。MySQL 提供了全局锁、行级锁、表级锁。其中 InnoDB 支持表级锁和行级锁，MyISAM 只支持表级锁。
19，什么是全局锁、共享锁、排它锁？
全局锁就是对整个数据库实例加锁，它的典型使用场景就是做全库逻辑备份。 这个命令可以使整个库处于只读状态。使用该命令之后，数据更新语句、数据定义语句、更新类事务的提交语句等操作都会被阻塞。
共享锁又称读锁 (read lock)，是读取操作创建的锁。其他用户可以并发读取数据，但任何事务都不能对数据进行修改（获取数据上的排他锁），直到已释放所有共享锁。当如果事务对读锁进行修改操作，很可能会造成死锁。
排他锁 exclusive lock（也叫 writer lock）又称写锁。
若某个事物对某一行加上了排他锁，只能这个事务对其进行读写，在此事务结束之前，其他事务不能对其进行加任何锁，其他进程可以读取,不能进行写操作，需等待其释放。排它锁是悲观锁的一种实现。
若事务 1 对数据对象 A 加上 X 锁，事务 1 可以读 A 也可以修改 A，其他事务不能再对 A 加任何锁，直到事物 1 释放 A 上的锁。这保证了其他事务在事物 1 释放 A 上的锁之前不能再读取和修改 A。排它锁会阻塞所有的排它锁和共享锁。
20，MySQL中的表锁有哪些？
MySQL 里表级锁有两种：普通表级锁、元数据锁（meta data lock）简称 MDL和AUTO-INC锁。表锁的语法是 lock tables t read/write。
可以用 unlock tables 主动释放锁，也可以在客户端断开的时候自动释放。lock tables 语法除了会限制别的线程的读写外，也限定了本线程接下来的操作对象。
对于 InnoDB 这种支持行锁的引擎，一般不使用 lock tables 命令来控制并发，毕竟锁住整个表的影响面还是太大。
MDL：不需要显式使用，在访问一个表的时候会被自动加上。
MDL 的作用：保证读写的正确性。
在对一个表做增删改查操作的时候，加 MDL读锁；当要对表做结构变更操作的时候，加 MDL 写锁。
读锁之间不互斥，读写锁之间，写锁之间是互斥的，用来保证变更表结构操作的安全性。
AUTO-INC锁，也就是在执行插入语句时就在表级别加一个AUTO-INC锁，然后为每条待插入记录的AUTO_INCREMENT修饰的列分配递增的值。
21，InnoDB引擎的行锁是怎么实现的？
InnoDB是基于索引来完成行锁，在锁的算法实现上有三种：
· Record lock：单个行记录上的锁
· Gap lock：间隙锁，锁定一个范围，不包括记录本身
· Next-key lock：record+gap 锁定一个范围，包含记录本身
Gap锁设计的目的是为了阻止多个事务将记录插入到同一范围内，而这会导致幻读问题的产生，innodb对于行的查询使用next-key lock，Next-locking keying是Record lock和Gap lock的组合。当查询的索引含有唯一属性时，将next-key lock降级为record key。
有两种方式显式关闭gap锁 ，第一种. 将事务隔离级别设置为RC ；第二种. 将参数innodb_locks_unsafe_for_binlog设置为1。
22，谈一下MySQL中的死锁
死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁。
如何查看死锁？
1）使用命令：show engine innodb status 查看。
在返回的结果中，查找 LATEST DETECTED DEADLOCK 部分，这里会列出最近发生的死锁信息，包括涉及的事务、它们持有的锁以及等待的锁等。
2）查询 INFORMATION_SCHEMA 数据库
查询涉及的锁信息：SELECT*FROM INFORMATION_SCHEMA.INNODB_LOCKS;
查询等待信息： SELECT*FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
3）开启死锁日志（可选）
如果你希望MySQL自动记录死锁信息到日志文件中，你可以在MySQL的配置文件（通常是my.cnf或my.ini）中设置以下参数：
[mysqld]
innodb_print_all_deadlocks = 1
这样，每次发生死锁时，详细的死锁信息会被记录到MySQL的错误日志中。可以查看错误日志文件（通常是hostname.err）来找到死锁信息。
对待死锁常见的两种策略：
1）死锁发生前的预防与避免
通过破坏死锁产生的必要条件（互斥、不可剥夺、请求与保持、循环等待），彻底防止死锁发生。动态分配资源时通过算法（如银行家算法）确保系统始终处于安全状态，避免进入死锁状态。
2）死锁发生后的检测与解除
允许系统运行过程中出现死锁，通过定期检测机制（如资源分配图）识别死锁。检测到死锁后，通过终止进程、资源剥夺或回滚操作恢复系统。
23，简述下MySQL8中的新增特性有哪些
MySQL 8 引入了许多新特性和改进，这些改进旨在提高性能、安全性和易用性。以下是一些MySQL 8中的新增特性：
1）数据字典与元数据改进
重构元数据存储为原子数据字典，使用 InnoDB 引擎替代传统的 .frm 等文件，确保 DDL 操作的原子性和崩溃安全性。
系统表（如 mysql.user）全部迁移至 InnoDB，提升统一性和性能
2）SQL 功能增强
支持通用表表达式（CTE）和递归查询，简化复杂查询与层次数据处理。
新增窗口函数，优化分析型查询。
增强 JSON 功能，包括 JSON_ARRAYAGG()、JSON_OBJECTAGG() 聚合函数和行内操作符 ->>
引入降序索引和隐藏索引，提升查询性能与索引管理灵活性。
3）InnoDB 存储引擎优化
改进自增计数器管理，支持持久化初始值，避免回滚或重启后值重用。
支持原子 DDL 操作（如 CREATE/ALTER TABLE），确保操作要么成功要么完全回滚。
新增 SELECT ... FOR SHARE/UPDATE 的 NOWAIT 和 SKIP LOCKED 选项，减少锁等待问题。
动态配置死锁检测（innodb_deadlock_detect），优化高并发场景。
4）安全与账户管理
支持角色（Role）机制，允许权限批量分配给用户，简化权限管理。
引入 caching_sha2_password 插件、密码历史记录和 FIPS 模式，增强安全性。
5）其他关键特性
持久化系统变量（SET PERSIST），无需手动编辑配置文件即可保存参数。
支持资源组管理，允许分配 CPU 资源给线程组，优化资源利用率。
默认表加密功能，通过参数 default_table_encryption 或 DDL 语句实现。
简化升级过程，自动处理系统表升级任务。
往期文章：
MySQL性能调优：Mysql8新特性
Java Stream实现List排序的核心技巧
MySQL性能调优：库设计优化、查询优化、配置及硬件优化等
