MySQL数据库体系结构

DDL：数据定义语言 data Definition language，
eg：create、drop、alter；
DML：数据操控语言 data Manipulation language，
eg：insert、update、delete；（要commit！）
DCL：数据控制语言 （管理用户权限）data Control language，
eg：grant、deny、revoke；
DQL：数据查询语言 data Query language，
eg：select。

innodb存储引擎内存结构

---

1.软件
安装：rpm；make install；yum localinstall rpm*

mysql 的软件存放的位置（每个人不一样），

软件存放的位置：show variables like ‘%base%’；
数据存放的位置：show variables like ‘%data%’；

2.通过这个软件可以管理很多数据：表
insert
delete
update
select

数据区的特点：

• 1.占用空间很大；
• 2.主要放的是表数据，索引数据
• 3.数据区由很多数据文件组成
• 4.数据文件特点：被格式化成一个个的数据块（数据页）（data page），默认16K
• 5.表数据放在数据页中，以行的形式存放

数据库启动，在ram中划出一块很大的内存区；
对数据行的访问：

• 1.数据行所在的数据页在内存中，直接产生内存读，将数据行从内存中读取出来，发送给用户；
• 2.数据行所在的数据页不在内存时，产生物理读（physical read），然后通过内存读读取数据。

用户线程：
- 每一个用户连接都会产生一个线程；
- 每一个用户线程会分配一个工作区。

数据缓冲区：（innodb_buffer_pool）

• 物理内存的：50%~80%
• 数据缓冲区是共享内存区

select * from t where id<5 order by ‘name’

执行SQL时：

• 1.建立一个用户连接、建立一个用户线程，分配一个用户空间（最经典的就是sort_buffer_size （256K））（每个用户线程都会分配一个sort_buffer）（256K指的是每个线程分配这么大）；
• 2.执行sql，例select、insert、update、delete；
• 3.访问数据页，select、dml；在内存-》内存读；不在内存–》物理读+内存读。

物理读：

• 用户线程发出读请求，具体物理读这个动作是由专门的读线程执行的；
• 用户写线程负责将脏数据（已修改，但未提交的数据）写给磁盘，这个动作是由写线程来完成的，而不是用户线程来完成。

小知识：mysql里，增删改查都叫 query！！

SQL的执行时间：内存查找+物理读+内存读+…… 执行完成，留下一个脏数据块（修改了，但是没有写到磁盘上!）。

其中，物理写不计算在SQL执行时间里面，物理写也叫作后台写！

---

知道数据库的状态：（eg：读线程数、写线程数）
show engine innodb status \G （没有分号!）

数据文件
show variables like ‘%file%’；得到：
redo logfile：2个，每个50M
log buffer size：8M

dml：修改/增加/删除 数据行；
dml会产生redo log
redo的格式： 数据页的地址、数据行、具体动作、动作内容

redo log：日志本身
log buffer：日志缓存
log file：日志文件本身

进行DML操作，就会产生redo log（数据页的地址、数据行、具体动作、动作内容），redo log 就会往log buffer写，就算没提交，也会每隔一段时间不断的写，然后log buffer再写到磁盘的logfile里。
redo log会给人感觉修改了N多数据后，提交的时候，非常快！原因：其实只是把redo log写到了磁盘的logfile里，而大量的脏数据其实还没有写到磁盘里，而是在后台慢慢写，但我们并不用担心，因为redo log已经写到logfile里了！！！
（没有commit的数据是可以丢的，不违背mysql的承诺！！）
redo log 详细的记录了对每一个数据页里面的数据行的修改！
修改前的数据页+redo log–》可以构造出来脏页！

eg：delete from t where id<10000；
删除一万行数据，至少会产生1000个redo log。
1.可能会非常大，增长很快
2.可以构造脏块

mysql有一个承诺： 只要提交成功的sql，mysql保证这个sql修改的数据会被永久保存！
dml
commit；

commit；
mysql会做一件事情，将log buffer（内存里）里面的日志写入到 logfile里去！
（PS：数据库崩溃之后，都会有自己的崩溃机制！）

---

PS:

• logfile是物理文件，是log存在的场所。一般数据库下的数据文件中有三个日志文件。
• redo log重做日志，记录着数据库所发生的变化，进行一条DML语句时，如果提交会先写入重做日志里。如果数据库出问题了，也可以根据重做日志来进行恢复。

完整的描述sql工作过程中产生的

用户线程建立、工作区分配、
内存读、物理读、
commit、redo log（日志写）（用户空间）
物理写（为什么说是后台物理写）协同工作！

首先用户执行一条输入一条dml，之后产生脏页，redo日志，undo日志，redo日志首先存在于用户空间中，之后到logbuffer中，最后通过commit到磁盘的log.file中，这时候数据脏页还没有到磁盘之中，仅仅存在于内存里，可视redolog已经存在于写缓存中，这样系统就会告诉用户已经已经写成功了，但脏页依旧没有进入磁盘，但只要有redolog在，就可以构建脏块，所以不怕没写入的脏块丢失，之后脏块通过后台写线程慢慢的写入写缓存，之后进入磁盘，完成整个操作，但这个时间不计算在写时间，仅仅在后台进行。
【达到1/2的时候、每隔1s钟写一次、commit的时候，都会把sort_buffer写到log_buffer，log buffer往logfile写。】
【所以，log_buffer里，只有很小的数据，基本不会超过4M（一共8M）】
（sort_buffer虽然只有256K，但是是给每个线程分配256K，而线程很多时，就大了。）

存储中的闪存和缓存

sql执行速度要想更快：

• 1.内存要足够大（从内存读的速度是从磁盘读的几万倍）；
• 2.物理读的速度要足够快（万一产生物理读，得能节省时间）；
• 3.redo log 写入速度要足够快。

cache缓存：
读缓存：对读操作原理上是有性能的提升，但是对于数据库系统来说，性能提升不是很明显，特别是系统稳定以后；对于写操作没有性能的提升（写的时候还是直接写到存储中…）

写缓存：对写性能有显著提升；对读性能基本上和读缓存差不多。

（写缓存原理）
存储里面，主要是写缓存！

存储的写功能是很强大的，如果写缓存失效，则是因为电池导致写cache被关闭：

• 1.电池确实坏了；
• 2.电池生命周期结束（倒计时到了）；
• 3.存储对电池有一个周期性的充放电，自动校正功能。

在充放电期间，存储关闭写缓存。（一般3个月一次）
为什么要充放电？
因为cache要知道电池能给自己充多长时间的电啊~

闪存

现代存储的工作机制：
读数据先到内存（128G）找–》到缓存（20G）找–》到闪存（4T）–》到磁盘，然后在磁盘找到时，直接读到内存。

网络上的方案：
在闪存里单独划出一块空间，给logfile。能够提升写缓存的速度。（错）

• 1.有个前提：写cache坏了，才能提升写缓存的速度；
• 2.而且，万一闪存坏了，那么logfile就没了，数据就没了。