《Mysql技术内幕》札记（下）

第七章 事务

一、redo和undo

当一个事务开始时，会记录这个事务的日志序列号，当此事务执行时，会往日志缓冲池插入数据，当事务提交时，日志缓冲区的数据存入磁盘。（innodb_flush_log_at_trx_commit=1时）

show engine innodb status
---
LOG
---
Log sequence number 1759155   （当前的lsn ）
Log flushed up to  1759155(已经被刷新到重做日志lsn )
Last checkpoint at 1759155(已经被刷新到磁盘的lsn )

重做日志的增量= Log flushed up to- Lastcheckpoint at

Undo当事务或语句因为某些原因失败了，就利用undo段事务回滚。他不像重做日志以日志文件存在，他以段的形式存在。Undo是逻辑回滚，回滚时执行的语句恰恰相反（前面是insert 回滚时就用delete）。在共享文件中 当事务提交后undo段不是马上回收，是由master thread慢慢回收。

二、事务控制
begin 显示开启事务 
Commit work指事务提交后做什么 
Completion_type=0不做任何操作
=1时提交后自动开启新事务 
=2提交 断开与服务器连接 所有参数都没了

TPS是Mysql性能监控的重要参数

show global status like '%commit%';
+----------------+-------+
| Variable_name  |Value |
+----------------+-------+
| Com_commit     |1     |显示提交   |
| Handler_commit | 214  |隐式提交
+----------------+-------+
 
show global status like '%rollback%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Com_rollback               | 0     |
| Handler_rollback           | 0     |
+----------------------------+-------+

TPS=（Com_commit+ Handler_commit+ Com_rollback+ Handler_rollback）/time

分布式本机事务参与全局调配 其隔离级别使用串行的 修改过程不能读 

三、不好的事务习惯

1. 

create procedure load()
…………
While s<=count do
Insert into t1 select NULL,c
Commit  
........
end

实例一中，忘记mysql有自动提交功能,自己又写了commmit，引起两次刷新到重做日志。

2.事务的控制语句最好由客户端来完成，因为程序可以轻松抓取错误信息。存储过程只完成逻辑操作。

第八章   备份

一、备份分类

备份的方法：热备，冷备，温备
温备对服务器有影响。

冷备：需要共享表空间文件，独立表空间文件，frm文件，重做日志文件 

优点：恢复快，操作简单。缺点：文件大（包括undo段，插入缓冲等）
备份内容:逻辑备份,裸文件备份
逻辑备份：备份文件可读的,比如通过outfile和mysqldump方法导出的数据(行数据或sql语句)但恢复时间长
数据库备份内容：完全备份，增量备份，日志备份
增量备份页原理：该页当前日志点大于全量备份的日志点，就备份该页。
日志备份 结合全量备份和日志备份可以将数据库恢复到一个点的数据
二、逻辑备份 

1.mysqldump
如果数据库中有myism 有innodb存储引擎备份时只能用--lock-tables选项。--lock-tables与--single-transaction两个互斥，备份时只能选择一个。--lock-tables选项在备份时虽然是依次锁住架构的表级锁，但表可以读取 
Mysqldump 如果有二进制就要用--hex-blob选项，将二进制用16进制显示，否则二进制字符不可见 
Mysqldump 可以不能导出视图

Single transaction 一致性不能隔离ddl语句，即隐式提交（注：将ddl语句前未提交的语句也一并提交）。

2. Mysqlimport 多个文件导入
Mysqlimport可以并发倒入多个表 use-thread可以定义并发数

/usr/local/mysql/bin/mysqlimporttest --use-threads=2 /opt/a6.txt /opt/a9.txt

并发导入文件名/opt/ a6.txt/opt/a9.txt 到test.a6和test. a9表中,文件名就是表名

三、有关binlog和重做日志参数

INNODB_FLUSH_LOG_AT_TRX_COMMIT针对的是重做日志

=1：每次提交都将log buffer刷新到logfile硬盘上

=0：每秒将log buffer数据刷新到logfile硬盘里

=2：每次提交将log buffer的数据刷新到ios内存里，每秒将ios内存的数据刷新到磁盘

SYNC_BINLOG针对binlog的

=0 mysql不控制binlog的刷新

=n 每提交n次事务刷新到磁盘

innodb_support_xa=1（事务二段式提交）保证binlog与重做日志的一致性。当事务提交时，将数据刷新到重做日志日志文件并标为prepare ，当数据写到binlog后，重做日志将数据prepare状态改为commit状态。

具体的介绍可以参考：

 http://www.woqutech.com/?p=769

http://www.linuxidc.com/Linux/2015-11/124942.htm

四、复制的状态参数解析

mysql> show slave status\G
***************************1. row ***************************
               Slave_IO_State: Waiting formaster to send event
                  Master_Host: 192.168.188.211
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000487
          Read_Master_Log_Pos: 841366505
               Relay_Log_File: relaylog.000548
                Relay_Log_Pos: 841366648
        Relay_Master_Log_File: binlog.000487
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:voyage_intelligence,voyage_massive,voyage_static_zh_cn,voyage_static_zh_tw
          Replicate_Ignore_DB:mysql,test,information_schema
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 841366505
              Relay_Log_Space: 841366837
              Until_Condition: None

Read_Master_Log_Pos表示已经从主库拉到从库的读到的偏移位置（841366505表示已经同步读到了binlog.000487的802M）

Exec_Master_Log_Pos表示已经同步了的偏移量

Sql线程延迟=Read_Master_Log_Pos-Exec_Master_Log_Pos

（841366505-841366505=0，表示没有sql延迟）

主库

mysql> show master status\G

***************************1. row ***************************

            File: binlog.000487

        Position: 842561811

    Binlog_Do_DB:voyage_massive,voyage_intelligence,voyage_static_zh_cn,voyage_static_zh_tw

Binlog_Ignore_DB:

1 row in set (0.00sec)

io线程延迟= Position- Read_Master_Log_Pos（可以看出io延迟有1M之差）

            第九章 性能调优

一、数据库分类
数据库根据应用分类：oltp（在线事务处理），olap（在线事务分析）
oltp操作简单，数据容量小但并发大

Olap则恰恰相反
消耗Cpu:语句复杂 比较 排序 连接 
Olap 密集在cpu oltp密集在io 

mysql 只有一个进程，修改innodb_read_io_threads和innodb_write_io_threads来提高io线程

 

mysql> set innodb_read_io_threads=1;

ERROR 1238 (HY000): Variable 'innodb_read_io_threads' isa read only variable

可以看到这个参数的修改需要重启服务器，然后修改配置表才能修改线程个数。

二、内存的重要性

缓冲池的增大，每秒处理事务的能力也线性增加，当缓冲池的大小大于数据文件本身时，TPS性能不再提高

缓冲池的命中率

mysql> show global status like '%innodb%read%';  （查看数据库运行状况）
+---------------------------------------+--------------+
| Variable_name                         | Value     |
+---------------------------------------+--------------+      |
| Innodb_buffer_pool_read_ahead         | 101128   |（预读的次数）
| Innodb_buffer_pool_read_ahead_evicted | 805        |（预读没被选中页）
| Innodb_buffer_pool_read_requests  | 761299912003 |（从缓存读取页次数）
| Innodb_buffer_pool_reads              | 645038 |（从磁盘读取页次数）
| Innodb_data_read                     | 29097275392|（总共读入字节数）
| Innodb_data_reads              | 79435  |（读取请求次数，一次多个页）|
+---------------------------------------+--------------+

缓冲池命中率= Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests+Innodb_buffer_pool_read_ahead+ Innodb_buffer_pool_reads)

缓冲命中率为=761299912003/761300658169=99.99%

缓冲池命中率不小于99%说明内存是够用的不存在瓶颈

第三、磁盘RAID

RAID0：读取速度最快，一个数据被分成多段，数据并行写在各个的磁盘上，但没有冗余，易丢失 
RAID1 最可靠，两两做镜像，读取速度慢 
RAID5 （常用）在存数据时还增加了奇偶检验信息，数据和检验存储到各个磁盘，一个磁盘坏了，可以通过其他磁盘的检验信息恢复磁盘，需要至少三磁盘。
RAID10（常用）先做RAID1 再做raid0。两个为一组组内备份，组间并行。与raid0的区别在于会将数据做条带，分别存储于不同的备份组里

RAID6 和RAID5相比有两个校验盘，以应对两个磁盘同时坏的问题。

参考：http://xuegodlinux.blog.51cto.com/10844319/1709964