[2024最新] java八股文实用版（附带原理）---Mysql篇

mysql事务的四大特性？

MySQL事务主要有4大特性，分别是原子性、一致性、隔离性、持久性。其中原子性确保事务中的所有操作要么全部完成，要么全部不完成；一致性是指数据库从一个一致性的状态转换到另外一个一致性的状态；隔离性确保并发执行的事务彼此隔离开来，避免相互干扰；持久性确保事务一旦提交，其结果是永久性的。

Mysql的事务隔离级别?

MySQL 主要支持四种事务隔离级别，分别是读未提交、读已提交、可重复读和串行化。
读未提交的意思是一个事务可以读取另一个未提交事务的数据，可能导致脏读，即一个事务读取了另一个事务未提交的数据。如果该事务回滚，那么读到的数据将是无效的。
读已提交是说一个事务只能读取已经提交的事务的数据。这样可以避免脏读，但可能会出现不可重复读，即A事务读取完数据后B事务提交数据，A事务再次读取的数据和上次不相同。
可重复读是说一个事务在整个过程中多次读取同一行数据时，结果是相同的。可以避免脏读和不可重复读，但可能会出现幻读。
串行化，这种级别下，事务完全串行化执行，避免了脏读、不可重复读和幻读。代价是并发性大大降低，事务可能会因为锁等待而阻塞。

Mysql脏读、幻读、不可重复读如何解释？

脏读
脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。
例如：张三的工资为5000,事务A中把他的工资改为8000,但事务A尚未提交。与此同时，事务B正在读取张三的工资，读取到张三的工资为8000。随后，事务A发生异常，而回滚了事务。张三的工资又回滚为5000。最后，事务B读取到的张三工资为8000的数据即为脏数据，事务B做了一次脏读。
​
不可重复读
是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。
例如：在事务A中，读取到张三的工资为5000，操作没有完成，事务还没提交。与此同时，事务B把张三的工资改为8000，并提交了事务。随后，在事务A中，再次读取张三的工资，此时工资变为8000。在一个事务中前后两次读取的结果并不致，导致了不可重复读。
​
幻读
是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。
例如：目前工资为5000的员工有10人，事务A读取所有工资为5000的人数为10人。此时，事务B插入一条工资也为5000的记录。这是，事务A再次读取工资为5000的员工，记录为11人。此时产生了幻读。
​
不可重复读和幻读有什么区别
不可重复读的重点是修改：同样的条件，你读取过的数据，再次读取出来发现值不一样了。
幻读的重点在于新增或者删除：同样的条件，第 1 次和第 2 次读出来的记录数不一样。

Mysql存储引擎MyISAM与InnoDB区别

MyISAM和InnoDB都是mysql的存储引擎。mysql5.5之前，默认的存储引擎是MyISAM，从5.5之后，默认的是InnoDB。MyISAM 适用于读多写少的场景，如数据仓库、日志分析等；InnoDB 适用于事务密集型和高并发场景，如在线交易系统、社交网络等。

存储引擎应该如何选择

1、 需要事务支持必选InnoDB，不需要事务选择MyISAM
2、如果表的大部分操作都是查询，数据不大，并发不大，可以考虑选择MyISAM，但是一般还是选择 innodb，有写又有读则选择InnoDB
3、如果系统奔溃导致数据难以恢复，且成本高，选择 innodb

什么是自适应hash索引？

自适应哈希索引是InnoDB存储引擎的一项独特性能优化特性，旨在针对高频访问的热点数据提升查询效率。与传统的静态哈希索引不同，自适应哈希索引采纳了一种自动化、动态调整的机制：InnoDB自主监控查询模式及数据访问频次，据此智能决策哈希索引的创建与否，并能依据数据集变动及查询模式的演进灵活地调整索引结构，无需人工介入。
其运作机理如下：当InnoDB检测到特定索引键值频繁遭受等值查询操作，系统便会在内存中自发为这些热点键值生成哈希索引，以此来加速后续的等值查询响应时间。这一系列优化行为均在后台自动执行，无需用户的直接参与或配置。

mysql使用规范你觉得都有什么?

1.数据库设计规范
    范式化设计：根据业务需求，合理选择符合一定范式（如1NF、2NF、3NF或BCNF）进行表结构设计，减少数据冗余，保证数据的一致性。
    表命名规范：采用有意义的、区分大小写的表名，通常使用小写字母，并用下划线_分隔单词，如user_info。
    字段命名规范：同样遵循有意义的命名原则，使用小写字母加下划线，避免使用数据库保留字。
2.索引设计规范
    适度索引：为频繁查询和参与JOIN操作的字段创建索引，但需注意过多的索引会影响插入、删除和更新操作的性能。
    索引类型选择：根据数据特性和查询需求选择合适的索引类型，如BTREE索引适用于范围查询，哈希索引适合等值查询。
    复合索引：合理安排复合索引中字段的顺序，一般将区分度高的字段放在前面以提高索引利用率。
3.SQL编写规范
    避免SELECT *：明确指定需要查询的字段，减少不必要的数据传输量。
    使用参数化查询：防止SQL注入攻击，提高代码安全性和可读性。
    事务处理：对相关操作使用事务管理，确保数据一致性，尤其是在涉及多表操作时。    
4.数据类型选择
    根据实际存储需求选择最合适的的数据类型，避免过度使用大容量类型，比如合理使用INT而非BIGINT，使用VARCHAR并限制长度而非无限制的TEXT。    
5.性能优化
    定期分析和优化表：使用ANALYZE TABLE和OPTIMIZE TABLE命令来分析表的状态并进行必要的优化。
    查询优化：利用EXPLAIN分析查询计划，优化复杂的查询语句，减少子查询的使用，适当情况下使用连接（JOIN）代替。
    定期进行数据库备份，包括全备和增量备份，确保在数据丢失或损坏时能够快速恢复。    
6.安全管理
    最小权限原则：为不同用户或应用分配仅满足其功能所需的最小权限。
    加密敏感数据：对敏感信息如密码进行加密存储，不直接保存明文。   
7.监控与日志
    启用并监控MySQL的日志系统（如错误日志、慢查询日志），及时发现并解决问题。
    遵循这些规范，可以帮助开发团队构建更加健壮、高效、易于维护的MySQL数据库应用系统。    

在建立索引的时，需要考虑哪些因素?

1.选择合适的列
    并非所有列都适合创建索引。通常，那些频繁用于查询条件（如WHERE子句）、JOIN操作或者ORDER BY、GROUP BY语句中的列是建立索引的首选。同时，考虑到索引维护的成本，应避免在具有高更新频率或大量重复值的列上建立索引。
2.索引覆盖
    如果一个查询的所有需要的数据都能从索引中直接获取而无需回表查询（即索引覆盖查询），那么这样的查询将更加高效。因此，在设计索引时，考虑是否能通过包含额外的列来实现索引覆盖。
3.索引类型
    根据数据特性和查询需求选择合适的索引类型。   
4.复合索引
    当查询涉及多个列时，可以考虑创建复合索引（即包含多个列的索引）。
5.索引的稀疏性
    索引应该尽可能地“瘦”，即只包含对查询有帮助的列，避免不必要的数据冗余，减少索引的大小和维护成本。   

数据库的三范式是什么

第一范式 (1NF):第一范式要求每个表中的字段值都是原子的，即每个字段只能包含一个值，不能包含重复的组或数组。
第二范式 (2NF):第二范式在满足第一范式的基础上，要求表中的每个非主键字段必须完全依赖于主键，消除部分依赖。
第三范式 (3NF):第三范式在满足第二范式的基础上，要求表中的非主键字段之间不能有传递依赖。

mysql的explain有哪些列？

EXPLAIN命令用于分析 SQL 查询的执行计划，帮助优化查询性能。通过 explain 命令获取 select 语句的执行计划，通过 explain 我们可以知道以下信息：表的读取顺序，数据读取操作的类型，哪些索引可以使用，哪些索引实际使用了，表之间的引用，每张表有多少行被优化器查询等信息。

Mysql语句都有哪些种类？

数据定义语言 (DDL):DDL 语句用于定义和管理数据库结构，例如创建、修改和删除数据库和表。
数据操作语言 (DML):DML 语句用于操作数据库中的数据，例如插入、更新、删除和查询数据。
数据控制语言 (DCL):DCL 语句用于控制数据库的访问权限。
事务控制语言 (TCL):TCL 语句用于管理事务，确保数据的一致性和完整性。
数据查询语言 (DQL):DQL 主要包括SELECT语句，用于查询数据库中的数据。

Mysql查询优化建议？

1.避免全表扫描
    优化查询时，应避免全表扫描，优先在 WHERE 和 ORDER BY 涉及的列上建立索引。
2.避免 NULL 值判断
    避免在 WHERE 子句中对字段进行 NULL 值判断。创建表时，尽量使用 NOT NULL 或使用特殊值（如 0 或 -1）作为默认值。
3.避免 != 或 <> 操作符
    避免在 WHERE 子句中使用 != 或 <> 操作符。MySQL 仅对 <，<=，=，>，>=，BETWEEN，IN 以及某些情况下的 LIKE 使用索引。
4.避免 OR 条件
    避免在 WHERE 子句中使用 OR 连接条件，因这会导致全表扫描。可以使用 UNION 合并查询
5.谨慎使用 IN 和 NOT IN
    谨慎使用 IN 和 NOT IN，因其可能导致全表扫描。对于连续数值，用 BETWEEN 替代 IN  
6.LIKE 查询优化
    避免使用%abc%或%abc的 LIKE 查询，这会导致全表扫描。可以考虑使用全文检索。只有abc%的 LIKE 查询会使用索引。   
7.避免参数化查询导致的全表扫描
    避免在 WHERE 子句中使用参数，这会导致全表扫描。 
8.避免表达式操作
    避免在 WHERE 子句中对字段进行函数操作。 
9.使用 EXISTS 替代 IN

Mysql聚集索引是什么？

MySQL 中的聚集索引是指数据表的记录按照索引的顺序进行物理存储。也就是说，表中的数据行和索引行一起存储，并且数据行的顺序与索引的顺序相同。聚集索引的特点是索引的叶节点包含了实际的数据行。一个表中只能有一个聚集索引，因为只能以一种物理顺序存放。
在 MySQL 中，InnoDB 存储引擎默认使用聚集索引。InnoDB 表必须有一个聚集索引，如果没有显式定义主键，InnoDB 会选择一个唯一的非空索引作为聚集索引。如果没有这样的索引，InnoDB 会自动生成一个名为row_id隐藏的聚集索引。
我们通过InnoDB把数据存放到B+树中，而B+树中的键值就是主键，那么在B+树中的叶子节点存储的就是表中的所有数据（即该主键对应的整行数据），数据文件和索引文件是同一个文件，找到了索引便找到了数据，所以称之为聚集索引。

为什么聚集索引，不要选择频繁更新的列？

1.数据重排
由于聚集索引的特点是数据行按照索引键的顺序进行物理存储，当聚集索引键的值发生变化时，数据库需要将该行移动到新的位置以保持索引顺序。这种数据重排操作会消耗大量的 I/O 和 CPU 资源，导致性能下降。
2.页分裂和合并
当新的数据行插入到现有页面中而页面已经满了时，InnoDB 需要进行页分裂（Page Split），将一个页面分成两个页面，以腾出空间存储新数据。这种操作不仅耗时，还会导致磁盘碎片，影响查询性能。频繁更新聚集索引键会增加页分裂的频率。
3.二级索引的维护
InnoDB 中的二级索引会引用聚集索引的键作为指向数据行的指针。当聚集索引键发生变化时，所有引用该键的二级索引也需要更新。这会增加额外的维护成本，影响整体性能。
4.锁争用和死锁
频繁更新聚集索引键可能导致更多的锁争用和死锁问题。数据行的移动和页分裂操作需要持有独占锁，这会阻塞其他事务的读写操作，增加系统的锁争用和死锁风险。

Mysql的非聚集索引是什么？

MySQL 的非聚集索引（Non-Clustered Index），也称为辅助索引或二级索引，是指索引的叶节点不包含实际的数据行，而是包含指向数据行的指针（通常是聚集索引键）。通俗理解，以主键以外的列作为键值构建的B+树索引。非聚集索引的主要作用是加速特定列上的查询操作，而不改变数据行的物理存储顺序。记录的物理顺序与逻辑顺序没有必然的联系。
非聚集索引表数据存储顺序与索引数据无关，叶节点包含索引字段值及指向数据页数据行的逻辑指针（其行数量与数据表数据量相同），所以想要查找数据还需要根据主键再去聚集索引中查找，根据聚集索引查找数据的过程就称为回表。

Mysql的回表查询是什么？

有了前面聚集索引和非聚集索引基础的小伙伴，可以发现聚集索引叶子结点会存数据，非聚集索引存的是主键值。知道这个前提后，在 MySQL 中，回表查询（也称为回表操作）是指在使用非聚集索引进行查询时，需要从索引中获取行的指针（通常是主键值），然后再根据这些指针访问实际的数据行。这种操作通常发生在查询中需要访问的列不完全包含在索引中的情况下。如果查询的列，包含在索引中，那么就是覆盖索引的概念了，后面会说。

mysql的覆盖索引是什么？

覆盖索引是优化回表查询的好手段。
在 MySQL 中，覆盖索引（Covering Index）是指一个索引包含了查询所需的所有列，从而使查询可以完全从索引中获取数据，而不需要访问实际的数据行。这种技术可以显著提高查询性能，因为它减少了对表数据的访问次数。
想一下，如果我的非聚集索引，在建立的时候，有一个 name 列，而我们查询的时候，也是 select name 这样就在非聚集索引就可以查到。那就不用回表了。

什么是前缀索引?

前缀索引（Prefix Index）是一种索引类型，用于对字符串类型的列（如CHAR、VARCHAR、TEXT等）进行部分索引。通过索引字符串的前一部分，而不是整个字符串，可以显著减少索引的大小，从而提高查询性能，特别是在处理大量数据时。比如一个字符串有 30 个字符，建立索引的时候，发现取前 10 个字符就可以区分出来，这样就可以减少索引大小，也就是前缀索引。

什么情况下应不建或少建索引？

1、表的数据量较小:对于小表，扫描整个表的速度可能比通过索引查找还要快。
2、表的写操作频繁：每次插入、更新或删除操作时，索引也需要更新，这会增加额外的开销。
3、索引列的基数低：基数低的列是指列中重复值较多的列，如性别（男/女）、布尔值（是/否）等。对于这种列，索引的选择性较差，使用索引进行查询可能不会显著提高性能。
4、频繁的批量数据加载：在进行批量数据加载（如批量插入或更新）时，索引的维护会显著增加操作时间。如果数据加载频繁，索引的维护成本会非常高。可以考虑在批量数据加载前暂时删除索引，加载完成后再重新创建索引。
5、查询模式不确定或多变：如果表的查询模式不确定或经常变化，创建索引的效果可能无法持续优化查询性能，反而可能带来不必要的维护开销。在查询模式稳定前，不要急于创建索引，先观察和分析实际查询情况，再决定是否需要索引。
6、索引过多导致的维护开销：一个表上创建过多的索引会增加插入、更新和删除操作的开销，因为每次数据修改都需要更新所有相关的索引。
7、使用不当的复合索引：复合索引是指在多个列上创建的索引。如果查询中未使用索引的前导列，索引可能不会被使用，从而无法发挥其优化作用。

mysql常见索引失效的情况?

使用函数或表达式
在索引列上使用函数或表达式（如UPPER(column)、column + 1）会导致索引失效。
​
隐式类型转换
当查询条件中的数据类型与索引列的数据类型不匹配时，MySQL 可能会进行隐式类型转换，从而导致索引失效。
​
使用OR条件
如果OR条件中的列没有索引或无法同时使用索引，也会导致索引失效。
​
前导模糊查询：
在 LIKE 查询中，如果模式以通配符（如%）开头，索引将失效。
​
不等于操作
使用不等于操作符（如!=或<>）通常会导致索引失效。
​
范围条件后再使用等值条件
复合索引中，如果使用了范围条件（如<、>、BETWEEN），后面的等值条件可能无法使用索引。
​
不满足最左前缀原则
对于复合索引，查询条件必须满足最左前缀原则，否则索引将失效。
​
查询条件中包含负向查询
例如NOT IN、NOT LIKE等负向查询条件会导致索引失效。
​
数据分布不均匀
即使有索引，如果数据分布非常不均匀，MySQL 优化器可能会选择全表扫描而不是使用索引。

唯一索引比普通索引快吗？

在数据库中，唯一索引和普通索引在性能上的差异主要体现在插入和更新操作上，而不是查询操作上。
​
唯一索引与普通索引的区别
唯一索引（Unique Index）：保证索引列中的值是唯一的，即不允许重复值。数据库系统在插入或更新数据时，会检查索引列的值是否已经存在，如果存在则会拒绝该操作。
普通索引（Non-Unique Index）：不强制索引列中的值唯一，可以有重复值。插入和更新操作不需要进行唯一性检查。

A,B,C三个字段组成联合索引，AB,AC,BC三种情况下查询是否能命中索引？

联合索引的基本原则

1. 最左前缀原则：联合索引会按照定义的字段顺序进行排序。查询必须从联合索引的最左边开始，才能利用索引。

2. 连续性原则：如果跳过了联合索引中的某个字段，那么索引在跳过的字段之后就无法继续利用。

结果

查询条件	是否命中索引	说明
(A, B)	是	完全匹配联合索引的前缀部分。
(A)	是	只使用了联合索引的第一列，可以命中。
(A, B, C)	是	完全匹配整个联合索引。
(A, C)	部分	能够利用索引中A的部分，但C不在B之后直接出现，因此只能部分利用索引。
(B, C)	否	没有从最左边开始连续匹配索引定义，故无法利用索引。
(B)	否	未包含联合索引中最左侧的列A，所以不能利用索引。

B+树索引和哈希索引的区别？

B+树索引
B+树是一种平衡树数据结构，所有数据都存储在叶节点上，叶节点通过指针相连形成一个链表。内部节点只存储键值和子节点指针。
在B+树上的常规检索，从根节点到叶子节点的搜索效率基本相当，不会出现大幅波动，而且基于索引的顺序扫描时，也可以利用双向指针快速左右移动，效率非常高。
​
哈希索引
哈希索引基于哈希表实现，通过哈希函数将键值映射到哈希表中的位置。哈希表中的每个位置存储一个指向数据记录的指针。
​
​
总结
如果应用场景中需要频繁的范围查询、排序操作或多字段组合查询，选择 B+树索引。
如果应用场景中等值查询非常频繁且不需要范围查询或排序操作，选择哈希索引。

特性	B+树索引	哈希索引
结构	基于平衡树结构，数据有序。	基于哈希表结构，数据无序。
查询性能	支持等值查询和范围查询；查找时间复杂度为 O(log n)。	等值查询性能高；查找时间复杂度为 O(1)，不支持范围查询。
适用场景	适合范围查询、排序操作以及多字段组合查询。	适合高频等值查询；不适合范围查询及排序操作。
维护成本	插入和删除时需维护树的平衡状态，可能涉及节点分裂或合并。	插入和删除相对简单，但需处理哈希冲突问题。
存储方式	通常存储在磁盘上，且节点大小设计以匹配磁盘页大小。	一般位于内存中，以此来加速数据访问过程。

为什么说B+比B树更适合实际应用中作为数据库索引？

范围查询效率更高
B树的数据存储在内节点和叶节点中，范围查询需要遍历多个节点，效率较低。B+树所有数据都存储在叶节点中，叶节点通过链表相连，形成一个有序的链表。这种结构使得范围查询和顺序访问非常高效，只需遍历叶节点链表即可完成范围查询。
​
内存和磁盘I/O效率更高
B树数据存储在所有节点中，内存使用较为分散，内节点和叶节点都存储数据，导致更多的磁盘I/O操作。
B+树内节点只存储索引键和指针，数据集中存储在叶节点中。这种结构使得内节点更小，可以在内存中存储更多的内节点，减少磁盘I/O操作，提高查询效率。
​
树的高度更低、更均匀
B树叶节点不一定在同一层，可能会导致树的高度不均匀，增加查询的复杂度。B+树所有叶节点都在同一层，树的高度更加均匀。更低、更均匀的树高意味着更少的磁盘I/O操作，查询效率更高。
​
更适合数据库的插入和删除操作
B树插入和删除操作可能会导致内节点和叶节点的分裂和合并，影响树的平衡性。
B+树插入和删除操作主要影响叶节点，内节点的结构相对稳定。叶节点通过链表相连，插入和删除操作在叶节点上进行，不会影响内节点的平衡性。
​
更高的空间利用率
B树：由于数据存储在所有节点中，内节点和叶节点的空间利用率较低。B+树：内节点只存储索引键和指针，空间利用率更高。叶节点通过链表相连，可以更高效地利用磁盘空间。

Mysql如何做分库分表？

MySQL 分库分表主要是为了应对单一数据库或表数据量过大导致的性能瓶颈，通过将数据分散到多个数据库或表中来提高系统的吞吐量和响应速度。
​
垂直分表（Vertical Sharding）
将一个大的表按照列拆分成多个较小的表，每个表只包含部分列。根据业务关系，将不同业务字段的数据分散到不同的表中。垂直拆分后业务清晰，数据维护简单。减少了I/O、锁争用和查询的字段数，提高了查询性能。不过如果单表的数据量、读写压力大，垂直分表可能无法解决问题。部分业务可能无法直接通过 SQL 关联查询，增加了开发复杂度。
​
水平分表（Horizontal Sharding）
将一个大的表按照某个字段的取值范围或哈希值拆分成多个较小的表，每个表存储部分数据。根据业务需求和数据量的分布情况选择合适的字段进行分片。这种方式解决了单一表数据量过大的问题，提高了系统性能和可扩展性。但是增加了跨表查询的复杂性。需要考虑数据路由和跨库查询优化。
​
实现注意事项
数据分片策略：选择合适的分片策略对数据库进行分库分表操作，例如按照用户ID、订单创建时间等字段进行分片。
数据访问路由：通过中间件（如 MyCAT、ShardingSphere、Cobar 等）来实现数据访问的路由和分片规则的管理。
跨库查询优化：优化跨库查询，减少跨库查询的次数和复杂度，提高查询效率。

mysql主从同步？

MySQL 主从同步（Replication）是一种将数据从一个 MySQL 数据库服务器（称为主服务器）复制到一个或多个 MySQL 数据库服务器（称为从服务器）的过程。这种机制通常用于提高数据冗余、负载均衡和数据备份。

mysql主从同步延迟的原因和解决办法？

MySQL 主从同步延迟（Replication Lag）是指从服务器与主服务器之间的数据复制存在时间差，导致从服务器上的数据不够新鲜。这种延迟可能会影响应用程序的性能和数据一致性。
​
延迟原因
1. 主服务器负载过高：
  ○ 主服务器的高负载会影响二进制日志的生成和发送速度，从而导致从服务器的延迟。
2. 从服务器性能瓶颈：
  ○ 从服务器的硬件资源（如 CPU、内存、磁盘 I/O）不足，导致处理中继日志的速度慢。
3. 网络延迟：
  ○ 主从服务器之间的网络延迟或带宽不足，会影响二进制日志的传输速度。
4. 大事务：
  ○ 大事务（如批量插入或更新）会生成大量的二进制日志，从而增加从服务器的处理时间。
5. 从服务器上的锁争用：
  ○ 从服务器在应用中继日志时，可能会遇到锁争用问题，导致延迟。
6. 配置不当：
  ○ MySQL 配置不当（如缓冲区大小、线程数等）会影响复制性能。
  
解决办法
1. 优化主服务器性能：
  ○ 优化主服务器的查询性能，减少不必要的负载。
  ○ 使用缓存（如 Query Cache）来减少数据库查询次数。
2. 提升从服务器性能：
  ○ 升级从服务器的硬件资源，如增加 CPU 核心数、内存容量和磁盘 I/O 性能。
  ○ 确保从服务器的配置（如innodb_buffer_pool_size、innodb_log_file_size）适合其硬件资源。
3. 优化网络性能：
  ○ 确保主从服务器之间的网络连接稳定且带宽充足。
  ○ 使用低延迟、高带宽的网络连接。
4. 拆分大事务：
  ○ 将大事务拆分为多个小事务，以减少单个事务的处理时间。
5. 调整复制配置：
  ○ 增加从服务器上的 I/O 线程和 SQL 线程数量（适用于 MySQL 8.0 及更高版本）。
  ○ 调整slave_parallel_workers参数以启用并行复制。
6. 监控和调整锁争用：
  ○ 使用监控工具（如SHOW PROCESSLIST、SHOW ENGINE INNODB STATUS）监控锁争用情况，并优化应用程序的锁使用策略。
7. 使用半同步复制：
  ○ 启用半同步复制（Semi-Synchronous Replication），确保主服务器在提交事务后等待至少一个从服务器确认已收到二进制日志，从而减少延迟。
8. 定期维护和优化：
  ○ 定期检查和优化数据库表（如索引重建、表碎片整理）以提高查询和写入性能。

mysql的全复制、半复制、异步复制都是什么？

1. 异步复制（Asynchronous Replication）
特点：
● 默认模式：MySQL 默认使用异步复制。
● 数据一致性：主服务器（Master）在提交事务后，不需要等待从服务器（Slave）的确认，事务即被认为完成。
● 性能：由于主服务器不需要等待从服务器的响应，性能较好。
● 延迟：存在复制延迟的可能性，因为从服务器可能会滞后于主服务器。
​
​
2. 半同步复制（Semi-Synchronous Replication）
特点：
● 数据一致性：在主服务器提交事务时，至少需要等待一个从服务器确认已经接收到并写入中继日志（relay log）后，事务才被认为完成。
● 性能：相对于异步复制，性能稍有下降，因为主服务器需要等待从服务器的确认。
● 延迟：减少了数据丢失的风险，但仍然存在一定的复制延迟。
​
3. 全同步复制（Fully Synchronous Replication）
特点：
● 数据一致性：在主服务器提交事务时，必须等待所有从服务器确认已经接收到并应用了该事务后，事务才被认为完成。
● 性能：性能较差，因为主服务器需要等待所有从服务器的确认。
● 延迟：延迟较高，但保证了数据的一致性和可靠性。
​
总结
● 异步复制：高性能，存在数据丢失风险，适用于读多写少的场景。
● 半同步复制：折中方案，较好的性能和数据一致性，适用于对数据一致性有一定要求的场景。
● 全同步复制：高数据一致性，性能较差，适用于对数据一致性要求极高的场景。

mvcc是什么？

多版本并发控制（MVCC，Multi-Version Concurrency Control）是一种用于管理数据库系统中并发访问的方法。它通过维护数据的多个版本来提高数据库系统的并发性和性能，同时确保数据的一致性和隔离性。
​
MVCC 的工作原理
MVCC 通过在数据库中存储每个数据行的多个版本来实现并发控制。每个事务在读取数据时，可以看到一个一致性快照，而不会被其他事务的并发修改所干扰。这种机制主要依赖于以下几个核心概念：
1. 版本控制：每个数据行都有多个版本，每个版本与一个特定的事务相关联。每次数据行被修改时，都会创建一个新版本，而旧版本则被保留。
2. 事务快照：每个事务在开始时都会获取一个一致性快照，这个快照包含了事务开始时数据库的状态。事务在执行期间，只能看到属于这个快照的数据版本，而不会看到其他事务提交的修改。
3. 事务ID：每个事务都有一个唯一的事务ID，用于标识事务的开始和结束时间。事务ID 用于确定哪些数据版本对当前事务可见。
4. 可见性规则：数据库系统使用事务ID 和版本号来决定哪些数据版本对当前事务可见。通常，事务只能看到在其开始之前已经提交的版本，而看不到在其开始之后创建的版本。
​
MVCC 的实现细节
不同的数据库系统对 MVCC 的实现细节有所不同，但通常包括以下几个方面：
1. 版本链：每个数据行维护一个版本链，链中的每个节点表示一个版本。每个版本包含数据行的值、创建该版本的事务ID 和删除该版本的事务ID（如果适用）。
2. 垃圾回收：随着时间的推移，旧的版本会变得不再需要。数据库系统需要定期进行垃圾回收，删除不再需要的旧版本，以释放存储空间。
3. 快照隔离：MVCC 通常与快照隔离级别结合使用，确保事务在执行期间看到一致的快照。快照隔离级别是介于可重复读和串行化之间的一种隔离级别。

MVCC解决了什么问题？

1.提高并发性
MVCC 允许多个事务同时执行读写操作，而无需互相阻塞或等待。这极大地提高了数据库的并发处理能力，特别是在高并发环境中。
2.减少锁争用
在传统的锁机制中，读写操作需要加锁，容易导致锁争用和死锁问题。MVCC 通过版本控制，使得读取操作不需要加锁，从而减少了锁争用的频率。
3.提供一致性视图
MVCC 为每个事务提供一个一致性的快照视图，使得事务在执行过程中看到的数据是固定的，不会受到其他并发事务的影响。
4.避免读写冲突
在 MVCC 中，读操作不会阻塞写操作，写操作也不会阻塞读操作。
5.减少死锁
由于读操作不需要加锁，MVCC 减少了死锁的可能性。
6.提高读性能
MVCC 提供了无锁的读操作，读操作直接读取数据的快照版本，不需要等待其他事务完成。这极大地提高了读操作的性能，尤其是在读操作频繁的场景下。
7.实现更高的隔离级别
MVCC 支持实现更高的隔离级别，如快照隔离（Snapshot Isolation），在这种隔离级别下，事务可以看到一个一致的快照视图，同时避免了脏读和不可重复读等问题。

mysql主键自增达到最大值会发生什么？你会怎么调整?

当达到这些最大值时，再插入新的记录会导致错误，通常是类似ERROR 1062 (23000): Duplicate entry '...' for key 'PRIMARY'。
● 有符号整数：
  ○ TINYINT: 最大值为127
  ○ SMALLINT: 最大值为32767
  ○ MEDIUMINT: 最大值为8388607
  ○ INT: 最大值为2147483647
  ○ BIGINT: 最大值为9223372036854775807
● 无符号整数：
  ○ TINYINT UNSIGNED: 最大值为255
  ○ SMALLINT UNSIGNED: 最大值为65535
  ○ MEDIUMINT UNSIGNED: 最大值为16777215
  ○ INT UNSIGNED: 最大值为4294967295
  ○ BIGINT UNSIGNED: 最大值为18446744073709551615

mysql的blob和text有什么区别?

在 MySQL 中，BLOB和TEXT是两种用于存储大数据的列类型。
1. 存储内容
● BLOB：用于存储二进制数据，如图像、音频、视频等。BLOB字段中的数据以二进制格式存储，不进行字符集转换。
● TEXT：用于存储大文本数据，如长文章、日志等。TEXT字段中的数据以字符格式存储，受字符集和排序规则的影响。
2.存储和检索
● BLOB：存储和检索时不会进行字符集转换，适合存储二进制数据。
● TEXT：存储和检索时会进行字符集转换，适合存储需要字符集支持的文本数据。

Mysql中什么是表分区？

在MySQL中，表分区是一种将表的数据按照某种规则分成多个较小的独立部分（分区）的技术。每个分区可以独立存储在不同的文件或磁盘上，从而提高查询性能、简化管理和优化存储资源的利用。表分区特别适用于处理大型表的数据管理和查询优化。

表分区与分表的区别？

分区（Partitioning）
定义： 分区是将一个大表按照某种规则分成多个较小的部分，每个部分称为一个分区。这些分区在逻辑上仍然属于同一个表，但在物理上可以独立存储。
实现方式：
● 内部实现：分区是在数据库内部实现的，用户在查询或操作时不需要关注分区的存在。
● 分区类型：MySQL支持多种分区类型，如范围分区、列表分区、哈希分区和键分区等。
优点：
1. 查询优化：通过分区裁剪（Partition Pruning），查询可以只在相关的分区上执行，减少扫描的数据量。
2. 管理简化：可以方便地进行分区的添加、删除和归档等操作。
3. 并行处理：分区可以更好地利用并行处理能力，提高多线程查询的性能。
4. 存储优化：不同的分区可以存储在不同的存储设备上，优化存储资源的利用。
​
分表（Sharding）
定义： 分表是将一个大表按照某种规则拆分成多个较小的表，每个表称为一个分片（Shard）。这些分片在逻辑上是独立的表，但在应用层面上被视为一个整体。
实现方式：
● 外部实现：分表通常需要在应用层面实现，应用程序需要知道数据如何分布在不同的表中。
● 分片规则：分表的规则可以是基于某个列的范围、哈希值或者其他自定义规则。
优点：
1. 水平扩展：分表可以将数据分布到多个数据库实例上，实现水平扩展。
2. 负载均衡：通过分表可以将负载均衡到不同的数据库实例上，减少单个实例的压力。
3. 独立管理：每个分片可以独立进行备份、恢复和优化等操作。

mysql什么情况下会产生死锁？

1. 不同顺序的锁定
当两个或多个事务以不同的顺序请求相同的资源时，容易引发死锁。
2. 间隙锁（Gap Lock）
在InnoDB存储引擎中，间隙锁用于防止幻读。在范围查询中，间隙锁可能会导致死锁。
3. 自增列的死锁
在高并发情况下，当多个事务同时插入自增列时，可能会导致死锁。
4. 外键约束
在涉及外键约束的表中，更新或删除操作可能会导致死锁。
5. 锁升级
当MySQL从行级锁升级到表级锁时，可能会导致死锁。
6. 混合使用不同类型的锁
在同一个事务中混合使用不同类型的锁（如读锁和写锁）时，可能会导致死锁。
7. 大量并发事务
在高并发环境中，大量事务同时操作同一资源，可能会导致死锁。
8. 长时间持有锁
当事务长时间持有锁，其他事务可能会在等待过程中产生死锁。
​
处理和预防死锁的方法
1. 自动检测和回滚：InnoDB存储引擎能够自动检测死锁，并回滚其中一个事务以解除死锁。
2. 查看死锁信息：使用命令SHOW ENGINE INNODB STATUS查看最近一次死锁的信息，以帮助诊断问题。
3. 合理的事务设计：尽量避免长时间持有锁，确保事务尽可能短小和高效。
4. 一致的锁定顺序：确保所有事务以相同的顺序请求资源，以减少死锁的可能性。
5. 减少并发事务：通过优化应用程序逻辑，减少同时并发的事务数量。
6. 使用合适的隔离级别：根据应用场景选择合适的事务隔离级别，以减少锁冲突。