DDL :数据定义语言data definition语言，
eg:create、drop、alter；
DML :数据操作语言数据管理语言，
eg:insert、update、delete； (请提交！ ）
DCL :数据控制语言(管理用户权限)数据控制语言、
eg:grant、deny、revoke；
DQL :数据查询语言data query语言，
eg :选择。
innodb存储引擎内存结构
1 .软件
安装： rpm； 生成安装； yum localinstall rpm*
mysql软件的保管场所(因人而异)、
软件位置：show variables like ‘%base%’；
数据存储位置：show variables like ‘%data%’；
2 .用该软件可以管理很多数据：表
插入
delete
更新
选择
数据区特征：
1 .占用空间较大2 .主要放置表数据、索引数据3 .数据区由多个数据文件组成4 .数据文件的特点：数据块(数据页)一个个被格式化，默认为
对数据行的访问：
1 .具有数据行的数据页在存储器中，直接生成存储器读取，从存储器中读出数据行，向用户发送2 .当存储器中没有具有数据行的数据页时，发生物理读取(physical read ) 用户线程：
-为每个用户连接生成一个线程。
-为每个用户线程分配一个工作区。
数据缓冲区：innodb_buffer_pool
物理存储器中的50%~80%数据缓冲区是共享存储器区域select * fromtwhereid5order by‘name’
在执行SQL时：
1 .建立用户连接，建立用户线程并分配用户区域(最典型的是sort_buffer_size ) 256K ) )向每个用户线程分配sort_buffer ) 2.SQL，示例执行选择、插入、更新和删除； 3 .访问数据页面，选择、dml； 用存储器-”存储器读取； “无内存”物理读取和读取内存。 物理读取：
用户线程发出读取请求，具体物理读取的动作由专用的读取线程执行； 用户线程负责将脏数据(已更改但未提交的数据)写入磁盘。 这由写入线程完成，而不是由用户线程完成。 小知识：在mysql中，增删修改都被称为query！
SQL执行时间：内存搜索物理读取内存读取……执行完成，脏块残留()已修改，但未写入磁盘！ 请参阅。
其中，物理写入不计入SQL的执行时间。 物理写入也称为后台写入！
了解数据库的状态： (eg )读线程数、写线程数) ) )。
show engine innodb status G （没有分号!）
数据文件
showVariableslike‘%file%”； 得到：
重做日志文件： 2个，每50M
log buffer size:8M
dml :修改/添加/删除数据行；
dml生成重做日志
重做格式：数据页地址、数据行、具体动作、动作内容
redo log：日志本身
log buffer：日志缓存
log file：日志文件本身
进行DML操作时，会发生重做log (数据页的地址、数据行、具体动作、动作内容)，重做log写入log buffer，即使没有提交也每隔一定时间不断地写入，log buffer是一个磁盘
重做log修改了n以上的数据后，提交的时候感觉很快！ 原因：其实只是把重做日志写在磁盘的log文件里，大量的脏数据其实没有写在磁盘里，而是在后台慢慢写，请不要担心。 因为重做日志已经写在日志文件中了。
(可以消除没有commit的数据。 不违背mysql的约定！ ）
重做日志详细记录了每个数据页中数据行的更改！
修改前的数据页重做日志”可以制作脏页！
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。能够提升写缓存的速度。（错）