环境说明

mysql版本：Percona-Server-5.6.30

IP：10.7.15.167

端口：3306

安装目录：/httx/run/mysql

数据目录：/httx/run/mysql/data/

mysqldump的常用参数

mysqldump测试——–研究加–single_transaction参数的区别

开启general_log日志，跟踪mysql操作日志

（general_log日志可以方便跟踪所有mysql上的操作，但是生产环境不建议开启，占用资源、消耗内存）

mysql> show variables like ‘%general%‘;
+------------------+--------------------------------------+
| Variable_name    | Value                                |
+------------------+--------------------------------------+
| general_log      | OFF                                  |
| general_log_file | /httx/run/mysql/data/web-test-46.log |
+------------------+--------------------------------------+
2 rows in set (0.00 sec)

mysql> set global general_log=on;
Query OK, 0 rows affected (0.00 sec)

数据库test情况表情况如下：

mysql> use test
Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| cv             |
| cv2            |
| dept           |
+----------------+

mysqldump命令导出test库数据，不带–single_transaction参数

 [[email protected] run]#mysqldump --socket=/httx/run/mysql/data/mysql.sock  test >/tmp/test-nosingle.sql

不带--single-transaction参数的mysqldump备份过程：
备份前准备：连接到数据库后，设置sql_mode、time_zone等；
 开始备份：先查看数据库有哪些表（show tables），根据表挨个备份：备份前先锁表（LOCK TABLES）,且一个表备份完不会释放锁，而    是继续备份下一个表，直到全部备份好，才会UNLOCK tables.
 注意：不带--single-transaction参数的mysqldump，备份过程全程锁表且没有创建数据一致性快照，这样会导致备份过程会阻塞数据库和数据不一致。

mysqldump命令导出数据，带–single_transaction参数

[[email protected] run]#mysqldump --socket=/httx/run/mysql/data/mysql.sock  test >/tmp/test-nosingle.sql

带上--single-transaction参数的mysqldump备份过程：
备份前准备：连接到数据库后，设置sql_mode、time_zone，设置事务隔离级别为RR；开启一个事务，生成一致性快照，保存数据库此刻的    状态。
开始备份：创建保存点（savepoint sp）,先查看数据库有哪些表（show tables），根据表挨个备份：备份过程先备份表结构（show create t able）再备份数据（select * from）,查询时不使用缓存以免备份脏数据（SQL_NO_CACHE）。备份完之后需要回滚到保存点（ROLL BACK         TO SAVEPOINT sp）,然后接着备份下一个表。
注意：备份一个表前都要回滚到保存点，这样是为了保证数据的一致性，即使数据没有更新也要回滚。

======================================================================================================

mysqldump命令

1、mysqlbinlog常用参数

推荐查看row模式二进制日志的方式：
mysqlbinlog  --base64-output=decode-rows
mysqlbinlog     -v或者mysqlbinlog     -vv

============================================================================================================

其他常用命令

====================================================================================================================

常用存储引擎

1、INNODB存储引擎

innodb存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比myisam存储引擎，innodb写的处理效率差一些且会占用更多的磁盘空间以保留数据和索引。

innodb通过使用MVCC来获取高并发性，且实现SQL标准的4种隔离级别，同时使用一种被称为next-key locking（间隙锁）的策略来避免幻读（phantom）现象。除此之外innodb存储引擎还提供插入缓冲（insert buffer）、二次写（double write）、自适应哈希索引（adaptive hash index）、预读（read ahead）等高性能技术。

（1）MVCC：Multi-Version Concurrency Control 多版本并发控制。大多数的MySQL事务型存储引擎，例如innodb、Falcon都不使用一种简单的行锁机制，而是和MVCC一起使用。MVCC不仅在MySQL中，在oracle、postgreSQL里也同样使用MVCC.
MVCC会保存某个时间点上的数据快照，这意味着事务可以看成一个一致的数据视图，不管他们需要跑多久。这也意味着不同的事务在同一个时间点看到的同一个表的数据可能是不同的。各个存储引擎对于MVCC的实现各不相同，这些不同种的一些包括乐观和悲观并发控制。
我们将通过一个简化的InnoDB版本的行为来展示MVCC工作的一个侧面。InnoDB：通过为每一行记录添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。但是InnoDB并不存储这些事件发生时的实际时间，相反它只存储这些事件发生时的系统版本号。这是一个随着事务的创建而不断增长的数字。每个事务在事务开始时会记录它自己的系统版本号。每个查询必须去检查每行数据的版本号与事务的版本号是否相同。让我们来看看当隔离级别是REPEATABLE READ时这种策略是如何应用到特定的操作的：
（1.1）SELECT： InnoDB必须保证每行数据符合以下2个条件：a、InnoDB必须找到一个行的版本，它至少要和事务的版本一样老(也即它的版本号不大于事务的版本号)。这保证了不管是事务开始之前，或者事务创建时，或者修改了这行数据的时候，这行数据是存在的。b、这行数据的删除版本必须是未定义的或者比事务版本要大。这可以保证在事务开始之前这行数据没有被删除。这里的不是真正的删除数据，而是标志出来的删除。真正意义的删除是在commit的时候。符合这两个条件的行可能会被当作查询结果而返回。
（1.2）INSERT：InnoDB为这个新行记录当前的系统版本号。
（1.3）DELETE：InnoDB将当前的系统版本号设置为这一行的删除ID。
（1.4）UPDATE：InnoDB会写一个这行数据的新拷贝，这个拷贝的版本为当前的系统版本号。它同时也会将这个版本号写到旧行的删除版本里。这种额外的记录所带来的结果就是对于大多数查询来说根本就不需要获得一个锁。他们只是简单地以最快的速度来读取数据，确保只选择符合条件的行。这个方案的缺点在于存储引擎必须为每一行存储更多的数据，做更多的检查工作，处理更多的善后操作。
MVCC只工作在REPEATABLE READ和READ COMMITED隔离级别下。READ UNCOMMITED不是MVCC兼容的，因为查询不能找到适合他们事务版本的行版本；它们每次都只能读到最新的版本。    SERIABLABLE也不与MVCC兼容，因为读操作会锁定他们返回的每一行数据[1]  。

（2）next-key locaking策略：MySQL innodb的间隙锁定（next-key locking）是为了防止幻读（phantom read），当MySQL的isolation level设为repeatable read的时候会触发间隙锁定。next-key的具体工作方式为：a、 选择一个不存在的行，则锁住所有的insert行为；b、用范围select，如select * from test where id>100，会锁住所有id>100的insert行为。
在行级锁定中，InnoDB 使用一个名为next-key locking的算法。InnoDB以这样一种方式执行行级锁定：当它搜索或扫描表的索引之时，它对遇到的索引记录设置共享或独占锁定。因此，行级锁定事实上是索引记录锁定。
InnoDB对索引记录设置的锁定也映像索引记录之前的“间隙”。如果一个用户对一个索引上的记录R有共享或独占的锁定，另一个用户不能紧接在R之前以索引的顺序插入一个新索引记录。这个间隙的锁定被执行来防止所谓的“幽灵问题”。假设你想要从有一个标识符值大于100的子表读并锁定所有子记录，并想着随后在选定行中更新一些列：
SELECT * FROM child WHERE id > 100 FOR UPDATE;
假设在id列有一个索引。查询从id大于100的第一个记录开始扫描。如果设置在索引记录上的锁定不把在间隙生成的插入排除在外，一个新行可能与此同时被插进表中。如果你在同一事务内执行同样的SELECT，你可能会在该查询返回的结果包里看到一个新行。这与事务的隔离原则是相反的：一个事务应该能够运行，以便它已经读的数据在事务过程中不改变。
当InnoDB扫描一个索引之时，它也锁定所以记录中最后一个记录之后的间隙。刚在前一个例子中发生：InnoDB设置的锁定防止任何插入到id可能大过100的表。
你可以用next-key锁定在你的应用程序上实现一个唯一性检查：如果你以共享模式读数据，并且没有看到你将要插入的行的重复，则你可以安全地插入你的行，并且知道在读过程中对你的行的继承者设置的next-key锁定与此同时阻止任何人对你的行插入一个重复。因此，the next-key锁定允许你锁住在你的表中并不存在的一些东西。

innodb特性：
——支持外键
——支持行锁
——支持事务
——非锁定读（读操作不会产生锁）
——聚集索引结构存储数据

2、MyISAM存储引擎

myisam存储引擎，不支持事务也不支持外键，访问速度快。对事务完整性没有要求或者以select、insert为主的应用基本都可以使用这个存储引擎来创建表。

每个myisam在磁盘上存储成3个文件，其中文件名和表名都相同，但是扩展名分别为：.frm .MYI .MYD

来自为知笔记(Wiz)