关于DataBase没有用的小知识

关于DataBase没有用的小知识

我会把工作中收集到的有关于数据库的小知识记录在这里，与君共勉！！！
提示：以下内容是我自己总结的，不一定对哈

日常

while(!world.destroy){
     System.out.println("I am working");
 }

---

一、Mysql？

1、Mysql5.6 以后创建表的方式变成了DYNAMIC也就是动态建表。

当用DYNAMIC创建表的时候，INNODB会把可变的列长度（比如varchar，varbinary，BLOB和Text类型）的值剥离出来，存储到一个溢出页上，只在该列上保存一个20个字节的指针指向溢出页

2、溢出页

在InnoDB存储引擎中，B+树索引是一种常见的数据结构，用于加速数据的检索。每个索引页都包含一组按顺序排列的索引键。然而，在某些情况下，索引键的大小可能会超出一个索引页的容量。这就引入了溢出页的概念。

以下是有关溢出页的一些关键信息：

溢出页的用途：

1：当一个索引页无法容纳更多的索引键时，InnoDB会创建一个或多个溢出页来存储这些额外的索引键。
2：溢出页包含超出原始索引页容量的索引键，它们按照相同的顺序排列。

链式结构：

溢出页之间通过链式结构连接在一起，以便按顺序访问它们。这个链式结构允许查询操作能够正确地遍历包含大量索引键的索引。

性能影响：

使用溢出页可以避免在插入大量数据时立即进行页分裂（splitting）操作，从而提高了性能。但需要注意，访问溢出页的操作可能会稍微降低查询性能，因为需要额外的磁盘IO。

内部维护：

InnoDB存储引擎负责内部维护溢出页的创建、管理和清理。
开发人员通常无需直接操作或担心溢出页的维护，因为这是InnoDB的内部机制。

总之，溢出页是InnoDB存储引擎用于处理大型索引键的一种内部机制。它们允许索引能够容纳比一个索引页能够存储的更多数据，从而提高了性能和效率。开发人员通常无需直接干预或管理溢出页，因为InnoDB负责处理它们。

3、MySQL 自增主键一定是连续的吗？

在 MySQL 5.7 及之前的版本，自增值保存在内存里，并没有持久化。每次重启后，第一次打开表的时候，都会去找自增值的最大值 max(id)，然后将 max(id)+1 作为这个表当前的自增值。
在 MySQL 8.0 版本，将自增值的变更记录在了 redo log 中，重启的时候依靠 redo log 恢复重启之前的值。可以通过看表详情查看当前自增值，以及查看表参数详情UTO_INCREMENT值(AUTO_INCREMENT就是当前数据表的自增值)

也就是说这个时候主键的自增是受到事务影响的，如果这个键增上去了，但是时候事务发生了回滚，那么这个主键就相当于作废了，这个时候主键就不是连续的了（其实在校的新手应该都见过这个问题）。

在MySQL8.0之后版本，已经默认设置为 innodb_autoinc_lock_mode=2 ， binlog_format=row.。这样更有利与我们在 insert … select 这种批量插入数据的场景时，既能提升并发性，又不会出现数据一致性问题。

4、Mysql 报错 Public Key Retrieval is not allowed？

我自己在家里的电脑里用docker搭建环境的时候遇到的问题，一查原来是mysql的版本太高了导致的，但是我还是不想用低版本。问题的原因如下：
mysql 8.0 默认使用 caching_sha2_password 身份验证机制 （即从原来mysql_native_password 更改为 caching_sha2_password。），
从 5.7 升级 8.0 版本的不会改变现有用户的身份验证方法，但新用户会默认使用新的 caching_sha2_password 。 客户端不支持新的加密方式。 修改用户的密码和加密方式。
解决方案把url重新改一下就好了：

jdbc:mysql://172.17.0.2:3306/test_db?useUnicode=true&serverTimezone=Asia/Shanghai&useSSL=false&characterEncoding=utf-8

改成

jdbc:mysql://172.17.0.2:3306/test_db?useUnicode=true&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai&useSSL=false&characterEncoding=utf-8

就解决了！！不知道这样做在生产环境上会不会有什么隐患。