速记-MySQL45讲-极客时间

2. hikari:
      connection-timeout: 30000               # 等待连接池分配连接的最大时间（毫秒），超过这个时长还没有可用的连接，则会抛出SQLException
      minimum-idle: 5                         # 最小连接数
      maximum-pool-size: 20                   # 最大连接数
      auto-commit: true                       # 自动提交
      idle-timeout: 600000                    # 连接超时的最大时长（毫秒），超时则会被释放（retired）
      pool-name: DataSourceHikariCP           # 连接池的名字
      max-lifetime: 18000000                  # 连接池的最大生命时长（毫秒），超时则会被释放（retired）
      connection-test-query: SELECT 1

2.更新SQL语句的执行过程：分析器通过词法语法解析发现是更新语句--优化器决定使用ID索引--于是执行器决定找到这一行然后调用存储引擎的接口进行操作。

MySQL可以恢复到半个月内任意一秒的状态----redo log（重做日志）-引擎层InnoDB 特有的 和 binlog（归档日志）-功能层

WAL的全称是Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，比如有的是redo log为一组4个文件分别1G，也就是可以写4G大小文件，超过就持久化到磁盘然后擦除记录。所以InnoDB 具有crash safe

三点不同：redo log是引擎曾-InnoDB引擎特有的，物理日志记录哪个数据页做了什么修改，以及固定空间循环写。

binlog -功能层的日志-不同存储引擎通用的--逻辑日志记录SQL语句---可以追加空间写不进行覆盖

通用不通用-物理和逻辑-固定不固定空间

以及redo log是保持数据一致性和持久性的，而binlog只是通用的为了数据恢复备份的。

两阶段提交--执行器-ID=2的数据页是否存储在内存中否则从磁盘加载--执行器进行数学计算--更新到内存中--随后记录到relog--此时redo log处于prepare 状态--然后执行器得到消息就写入binlog，binlog写入磁盘--然后执行器调用引擎的提交事务接口---引擎就会把redo log改成commit状态-=更新完成

将redo log的写入拆成了两个步骤：prepare和commit，这就是"两阶段提交"。为了保持这两个一致

因此 某个时刻的全量备份 +binlog--就可以恢复数据

一天备份和一周备份取决于对Binlog的忍受程度，存储太多容易出错。redo log是固定空间，所以仍然需要bin log

3.事务隔离级别：

事务特性-ACID-脏读不可重复读幻读-读未提交（事务未提交就可以被其他事务看到）-读已提交（事务提交才可以被看到）-可重复读（事务中执行过程中总是与启动看的一致）-串行化（加读写锁）

read view多个版本，可以回退，回滚日志如果没有事务需要就会删除

4.索引：数据结构有哈希表（适合等值查询比如memcached之类的NoSQL引擎）、有序数组（适合等值查询以及范围查询，适合静态存储引擎（避免大量修改比如2017年人口信息）、N叉树（减少磁盘的访问寻址）

主键索引的叶子节点存的是整行数据--InnoDB里主键索引也被称为聚簇索引。非主键索引的叶子节点存储的是主键的值，也就是非聚簇索引也就是二级索引。基于普通索引的就需要查到主键再查主键索引然后回表到主键索引查询一行数据。

一般都是使用自增主键，但是存在只有一个索引且是唯一索引的场景需求，也就是KV场景，这里直接使用业务字段作为索引即可。

覆盖索引

如果执行的语句是select ID from T where k between 3 and 5，这时只需要查ID的值，而ID的值已经在k索引树上了，因此可以直接提供查询结果，不需要回表。也就是说，在这个查询里面，索引k已经“覆盖了”我们的查询需求，我们称为覆盖索引。

也就是查询的信息都被索引存储的信息全部覆盖不需要回表

所以覆盖索引 -》 性能优化

联合索引

如果高频语句