mysql 高级

关键文件

日志文件

错误日志：       -log-err
查询日志：       -log
# 记录SQL超过一定时常的语句
慢查询日志:      -log-slow-queries
更新日志:       -log-update
# 导致数据改变的sql语句
二进制日志：  -log-bin
事务日志：       ib_logfile0,ib_logfile1

数据文件

存放位置： /var/lib/mysql
为每一个数据库新建一个文件夹。 

frm文件：表结构。
ibd文件：数据和索引。

配置文件

位于： /etc/my.cnf 
但是我在我的docker中没找到，还需要研究一下。

---

存储引擎

mysql使用插件式的存储引擎，MySQL存储引擎有InnoDB、MyISAM、Memory、Archive

数据库关键概念：

1. 事务

2. 读锁和写锁
   
   读锁是共享锁，写锁是排他锁。

3. 行锁和表锁
   
   表级锁速度快，但冲突多，行级锁冲突少，但速度慢。

InnoDB存储引擎

InnoDB就是强大的第三方存储引擎，具备较好的性能和自动崩溃恢复特性

支持事务、支持行锁、支持非锁定读、支持外键。支持最大64TB的数据量

首选考虑使用InnoDB

MyISAM存储引擎

官方提供的存储引擎

不支持事务，不支持行级锁，支持表锁，支持全文索引，支持最大256TB的数据量，最大的缺陷是崩溃后无法安全恢复

---

索引详解

索引是在存储引擎层而不是服务器层实现的。

索引可以建立在单列数据上，也可以建立在多列数据上，原则上建议建立索引的列区别应该较大。且主键一定是唯一性索引，但唯一性索引并不一定就是主键。

索引分很多种BTree索引，哈希索引，全文索引等等，其中MyIsam 和 Innodb 引擎使用B+Tree索引。

索引的本质：

索引（Index）是帮助MySQL高效获取数据的数据结构。即索引是一种数据结构

在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。

目前大部分数据库系统及文件系统都采用B-Tree或其变种B+Tree作为索引结构，B-Tree有许多变种，其中最常见的是B+Tree，例如MySQL就普遍使用B+Tree实现其索引结构。

B+Tree与B-Tree的区别：

• 每个节点的指针上限为2d而不是2d+1。
• 内节点不存储data，只存储key，叶子节点不存储指针。
• 一般来说，B+Tree比B-Tree更适合实现外存储索引结构

MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址。

虽然InnoDB也使用B+Tree作为索引结构，但具体实现方式却与MyISAM截然不同。第一个重大区别是InnoDB的数据文件本身就是索引文件。

MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。而在InnoDB中，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。因此本文最初谈论的：frm文件：表结构。ibd文件：数据和索引。是基于InnoDB引擎的。

---

主从复制

主从复制是指一台服务器充当主数据库服务器，另一台或多台服务器充当从数据库服务器，主服务器中的数据自动复制到从服务器之中。对于多级复制，数据库服务器即可充当主机，也可充当从机。MySQL主从复制的基础是主服务器对数据库修改记录二进制日志，从服务器通过主服务器的二进制日志自动执行更新。

主服务器上面的任何修改都会保存在二进制日志Binary log里面，使用主从复制要求主服务器需要开启bin log。

Mysq主从复制的类型

1. 基于语句的复制：
   主服务器上面执行的语句在从服务器上面再执行一遍。存在的问题：时间上可能不完全同步造成偏差，执行语句的用户也可能是不同一个用户。

2. 基于行的复制：
   把主服务器上面改编后的内容直接复制过去，而不关心到底改变该内容是由哪条语句引发的。存在的问题：比如一个工资表中有一万个用户，我们把每个用户的工资+1000，那么基于行的复制则要复制一万行的内容，由此造成的开销比较大，而基于语句的复制仅仅一条语句就可以了。

3. 混合类型的复制：MySQL默认使用基于语句的复制，当基于语句的复制会引发问题的时候就会使用基于行的复制，MySQL会自动进行选择。

Mysql主从复制的过程

MySQL主从复制的两种情况：同步复制和异步复制，实际复制架构中大部分为异步复制。

复制的基本过程如下：

1. Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容。
2. Master接收到来自Slave的IO进程的请求后，负责复制的IO进程会根据请求信息读取日志指定位置之后的日志信息，返回给Slave的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置。
3. Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”。
4. Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。