MySQL 笔记
数据库存储引擎
MySQL中的数据用各种不同的技术存储在文件(或者内存)中。这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。通过选择不同的技术，你能够获得额外的速度或者功能，从而改善你的应用的整体功能。 存储引擎说白了就是如何存储数据、如何为存储的数据建立索引和如何更新、查询数据等技术的实现方法。
MySQL 5.0 支持的存储引擎包括 MyISAM, InnoDB, MEMORY, ARCHIVE, MRG_MYISAM, CSV, BLACKHOLE, PERFORMANCE_SCHEMA, FEDERATED 。
其中常用的为 InnoDB，MyISAM，MEMORY，ARCHIVE。
InnoDB
InnoDB是一个健壮的事务型存储引擎，这种存储引擎已经被很多互联网公司使用，为用户操作非常大的数据存储提供了一个强大的解决方案。我的电脑上安装的 MySQL 5.6.13 版，InnoDB就是作为默认的存储引擎。InnoDB还引入了行级锁定和外键约束，在以下场合下，使用InnoDB是最理想的选择：
- 更新密集的表。InnoDB存储引擎特别适合处理多重并发的更新请求。
- 事务。InnoDB存储引擎是支持事务的标准MySQL存储引擎。
- 自动灾难恢复。与其它存储引擎不同，InnoDB表能够自动从灾难中恢复。
- 外键约束。MySQL支持外键的存储引擎只有InnoDB。
- 支持自动增加列AUTO_INCREMENT属性。
从5.7开始innodb存储引擎成为默认的存储引擎。
一般来说，如果需要事务支持，并且有较高的并发读取频率，InnoDB是不错的选择。
MyISAM
MyISAM表是独立于操作系统的，这说明可以轻松地将其从Windows服务器移植到Linux服务器；每当我们建立一个MyISAM引擎的表时，就会在本地磁盘上建立三个文件，文件名就是表名。例如，我建立了一个MyISAM引擎的tb_Demo表，那么就会生成以下三个文件：
- tb_demo.frm，存储表定义。
- tb_demo.MYD，存储数据。
- tb_demo.MYI，存储索引。
MyISAM表无法处理事务，这就意味着有事务处理需求的表，不能使用MyISAM存储引擎。MyISAM存储引擎特别适合在以下几种情况下使用：
- 选择密集型的表。MyISAM存储引擎在筛选大量数据时非常迅速，这是它最突出的优点。
- 插入密集型的表。MyISAM的并发插入特性允许同时选择和插入数据。例如：MyISAM存储引擎很适合管理邮件或Web服务器日志数据。
常用引擎对比
不同存储引起都有各自的特点，为适应不同的需求，需要选择不同的存储引擎，所以首先考虑这些存储引擎各自的功能和兼容。
| 特性 | InnoDB | MyISAM | MEMORY | ARCHIVE |
|---|---|---|---|---|
| 存储限制(Storage limits) | 64TB | No | YES | No |
| 支持事物(Transactions) | Yes | No | No | No |
| 锁机制(Locking granularity) | 行锁 | 表锁 | 表锁 | 行锁 |
| B树索引(B-tree indexes) | Yes | Yes | Yes | No |
| T树索引(T-tree indexes) | No | No | No | No |
| 哈希索引(Hash indexes) | Yes | No | Yes | No |
| 全文索引(Full-text indexes) | Yes | Yes | No | No |
| 集群索引(Clustered indexes) | Yes | No | No | No |
| 数据缓存(Data caches) | Yes | No | N/A | No |
| 索引缓存(Index caches) | Yes | Yes | N/A | No |
| 数据可压缩(Compressed data) | Yes | Yes | No | Yes |
| 加密传输(Encrypted data[1]) | Yes | Yes | Yes | Yes |
| 集群数据库支持(Cluster databases support) | No | No | No | No |
| 复制支持(Replication support[2]) | Yes | No | No | Yes |
| 外键支持(Foreign key support) | Yes | No | No | No |
| 存储空间消耗(Storage Cost) | 高 | 低 | N/A | 非常低 |
| 内存消耗(Memory Cost) | 高 | 低 | N/A | 低 |
| 数据字典更新(Update statistics for data dictionary) | Yes | Yes | Yes | Yes |
| 备份/时间点恢复(backup/point-in-time recovery[3]) | Yes | Yes | Yes | Yes |
| 多版本并发控制(Multi-Version Concurrency Control/MVCC) | Yes | No | No | No |
| 批量数据写入效率(Bulk insert speed) | 慢 | 快 | 快 | 非常快 |
| 地理信息数据类型(Geospatial datatype support) | Yes | Yes | No | Yes |
| 地理信息索引(Geospatial indexing support[4]) | Yes | Yes | No | Yes |
如何选择合适的存储引擎
提供几个选择标准，然后按照标准，选择对应的存储引擎即可。使用哪种引擎需要根据需求灵活选择，一个数据库中多个表可以使用不同的引擎以满足各种性能和实际需求。使用合适的存储引擎，将会提高整个数据库的性能。
决定使用什么样的存储引擎是一个问题，这里只考虑最常见的 MyISAM 和 InnoDB 两个存储引擎。
先考虑一些问题：
- 数据库有外键吗？
- 需要事务支持吗？
- 需要全文索引吗？
- 经常使用什么样的查询模式？
- 数据有多大？
如果你需要事务处理或是外键，那么InnoDB可能是比较好的方式。如果你需要全文索引，那么通常来说MyISAM是好的选择，因为这是系统内建的，然而，我们其实并不会经常地去测试两百万行记录。所以，就算是慢一点，我们可以通过使用Sphinx从InnoDB中获得全文索引。
数据的大小，是一个影响选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的大小决定了故障恢复的时间长短，InnoDB可以利用事务日志进行数据恢复，这会比较快。而MyISAM可能会需要 几个小时甚至几天来干这些事，InnoDB只需要几分钟。
操作数据库表的习惯可能也会是一个对性能影响很大的因素。比如： COUNT() 在 MyISAM表中会非常快，而在InnoDB表下可能会很痛苦。而主键查询则在InnoDB下会相当相当的快，但需要小心的是如果我们的主键太长了也会导致性能问题。大批的inserts语句在MyISAM下会快一些，但是updates在InnoDB 下会更快一些——尤其在并发量大的时候。
数据库索引
索引分类
index —-普通的索引,数据可以重复
fulltext—-全文索引，用来对大表的文本域(char，varchar，text)进行索引。语法和普通索引一样。
unique —-唯一索引,唯一索引,要求所有记录都唯一
primary key —-主键索引,也就是在唯一索引的基础上相应的列必须为主键
复合索引
mysql建立多列索引（联合索引）有最左前缀的原则，即最左优先，如：
如果有一个3列索引(col1,col2,col3)，则已经对(col1)、(col1,col2)、(col1,col2,col3)上建立了索引。
此时如果选择 col2 和 col3 进行查询，就不会利用到索引。
设计原则
1．选择唯一性索引
* 唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。例如，学生表中学号是具有唯一性的字段。为该字段建立唯一性索引可以很快的确定某个学生的信息。如果使用姓名的话，可能存在同名现象，从而降低查询速度。2．为经常需要排序、分组和联合操作的字段建立索引
* 经常需要ORDER BY、GROUP BY、DISTINCT和UNION等操作的字段，排序操作会浪费很多时间。如果为其建立索引，可以有效地避免排序操作。3．为常作为查询条件的字段建立索引
* 如果某个字段经常用来做查询条件，那么该字段的查询速度会影响整个表的查询速度。因此，为这样的字段建立索引，可以提高整个表的查询速度。4．限制索引的数目
* 索引的数目不是越多越好。每个索引都需要占用磁盘空间，索引越多，需要的磁盘空间就越大。修改表时，对索引的重构和更新很麻烦。越多的索引，会使更新表变得很浪费时间。5．尽量使用数据量少的索引
* 如果索引的值很长，那么查询的速度会受到影响。例如，对一个CHAR(100)类型的字段进行全文检索需要的时间肯定要比对CHAR(10)类型的字段需要的时间要多。6．尽量使用前缀来索引
* 如果索引字段的值很长，最好使用值的前缀来索引。例如，TEXT和BLOG类型的字段，进行全文检索会很浪费时间。如果只检索字段的前面的若干个字符，这样可以提高检索速度。7．删除不再使用或者很少使用的索引
* 表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。数据库管理员应当定期找出这些索引，将它们删除，从而减少索引对更新操作的影响。8 . 最左前缀匹配原则，非常重要的原则。
* mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。9 .=和in可以乱序。
* 比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式10 . 尽量选择区分度高的列作为索引。
* 区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就 是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条 记录11 .索引列不能参与计算，保持列“干净”。
* 比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本 太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);12 .尽量的扩展索引，不要新建索引。
* 比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可
BTREE 索引与 HASH 索引
MySQL 支持 BTREE 索引与 HASH 索引
BTREE 索引的使用场景通常较 HASH 索引更多，原因如下：
Hash 索引仅仅能满足”=”,”IN”和”<=>”查询，不能加速范围查询。
* 由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样。Hash 索引无法被用来避免数据的排序操作。
* 由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值，而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样，所以数据库无法利用索引的数据来避免任何排序运算；Hash 索引不能利用部分索引键查询。
* 对于组合索引，Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值，而不是单独计算 Hash 值，所以通过组合索引的前面一个或几个索引键进行查询的时候，Hash 索引也无法被利用。Hash 索引在任何时候都不能避免表扫描。
* 前面已经知道，Hash 索引是将索引键通过 Hash 运算之后，将 Hash运算结果的 Hash 值和所对应的行指针信息存放于一个 Hash 表中，由于不同索引键存在相同 Hash 值，所以即使取满足某个 Hash 键值的数据的记录条数，也无法从 Hash 索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。
* 对于选择性比较低的索引键，如果创建 Hash 索引，那么将会存在大量记录指针信息存于同一个 Hash 值相关联。这样要定位某一条记录时就会非常麻烦，会浪费多次表数据的访问，而造成整体性能低下。
数据库事物隔离级别
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| 未提交读（read uncommitted） | 可能 | 可能 | 可能 |
| 已提交读(read committed) | 不可能 | 可能 | 可能 |
| 可重复读(Repeatable read) | 不可能 | 不可能 | 可能 |
| 可串行化(Serializable) | 不可能 | 不可能 | 不可能 |
脏读：一个事务读取到另一事务未提交的更新新据。当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有
提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据， 那么另
外一个事务读到的这个数据是脏数据，依据脏数据所做的操作也可能是不正确的。不可重复读：在同一事务中，多次读取同一数据返回的结果有所不同。换句话说就是，后续读取可以读到另一事务已提交的
更新数据。相反，“可重复读”在同一事务中多次读取数据时，能够保证所读数据一样，也就是，后续读取不能读到另一事务
已提交的更新数据。幻读：事务T1执行一次查询，然后事务T2新插入一行记录，这行记录恰好可以满足T1所使用的查询的条件。然后T1又使用相同
的查询再次对表进行检索，但是此时却看到了事务T2刚才插入的新行。这个新行就称为“幻像”，因为对T1来说这一行就像突然
出现的一样。
InnoDB 默认级别： 可重复读(Repeatable read)
性能分析
使用 explain 查看 sql 查询语句在实际数据库中的查询方式
例如：
mysql> explain select * from servers;
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
| 1 | SIMPLE | servers | ALL | NULL | NULL | NULL | NULL | 1 | NULL |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
1 row in set (0.03 sec)expain出来的信息有10列，分别是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra
id
- id相同时，执行顺序由上至下
- 如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行
- id如果相同，可以认为是一组，从上往下顺序执行；在所有组中，id值越大，优先级越高，越先执行
select_type
示查询中每个select子句的类型
- SIMPLE(简单SELECT,不使用UNION或子查询等)
- PRIMARY(查询中若包含任何复杂的子部分,最外层的select被标记为PRIMARY)
- UNION(UNION中的第二个或后面的SELECT语句)
- DEPENDENT UNION(UNION中的第二个或后面的SELECT语句，取决于外面的查询)
- UNION RESULT(UNION的结果)
- SUBQUERY(子查询中的第一个SELECT)
- DEPENDENT SUBQUERY(子查询中的第一个SELECT，取决于外面的查询)
- DERIVED(派生表的SELECT, FROM子句的子查询)
- UNCACHEABLE SUBQUERY(一个子查询的结果不能被缓存，必须重新评估外链接的第一行)
table
显示这一行的数据是关于哪张表的，有时不是真实的表名字,看到的是derivedx(x是个数字,我的理解是第几步执行的结果)
- type
表示MySQL在表中找到所需行的方式，又称“访问类型”。
常用的类型有： ALL, index, range, ref, eq_ref, const, system, NULL（从左到右，性能从差到好）
1. ALL：Full Table Scan， MySQL将遍历全表以找到匹配的行
2. index: Full Index Scan，index与ALL区别为index类型只遍历索引树
3. range:只检索给定范围的行，使用一个索引来选择行
4. ref: 表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值
5. eq_ref: 类似ref，区别就在使用的索引是唯一索引，对于每个索引键值，表中只有一条记录匹配，简单来说，就是多表连接中使用primary key或者 unique key作为关联条件
6. const、system: 当MySQL对查询某部分进行优化，并转换为一个常量时，使用这些类型访问。如将主键置于where列表中，MySQL就能将该查询转换为一个常量,system是const类型的特例，当查询的表只有一行的情况下，使用system
7. NULL: MySQL在优化过程中分解语句，执行时甚至不用访问表或索引，例如从一个索引列里选取最小值可以通过单独索引查找完成。
- possible_keys
指出MySQL能使用哪个索引在表中找到记录，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用
该列完全独立于EXPLAIN输出所示的表的次序。这意味着在possible_keys中的某些键实际上不能按生成的表次序使用。
如果该列是NULL，则没有相关的索引。在这种情况下，可以通过检查WHERE子句看是否它引用某些列或适合索引的列来提高你的查询性能。如果是这样，创造一个适当的索引并且再次用EXPLAIN检查查询
- Key
key列显示MySQL实际决定使用的键（索引）
如果没有选择索引，键是NULL。要想强制MySQL使用或忽视possible_keys列中的索引，在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
- key_len
表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度（key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的）
不损失精确性的情况下，长度越短越好
- ref
表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值
- rows
表示MySQL根据表统计信息及索引选用情况，估算的找到所需的记录所需要读取的行数
- Extra
该列包含MySQL解决查询的详细信息,有以下几种情况：
Using where:列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候，表示mysql服务器将在存储引擎检索行后再进行过滤
Using temporary：表示MySQL需要使用临时表来存储结果集，常见于排序和分组查询
Using filesort：MySQL中无法利用索引完成的排序操作称为“文件排序”
Using join buffer：改值强调了在获取连接条件时没有使用索引，并且需要连接缓冲区来存储中间结果。如果出现了这个值，那应该注意，根据查询的具体情况可能需要添加索引来改进能。
Impossible where：这个值强调了where语句会导致没有符合条件的行。
Select tables optimized away：这个值意味着仅通过使用索引，优化器可能仅从聚合函数结果中返回一行
使用 profiles 分析 sql 性能
Show profiles是5.0.37之后添加的，要想使用此功能，要确保版本在5.0.37之后。
查看数据库版本
mysql> select version();
查看是否打开了profiles功能,默认是关闭的
mysql> show profiles;
Empty set (0.00 sec)显示为空，说明profiles功能是关闭的。下面开启
mysql> set profiling=1;执行任意查询语句
mysql> explain select distinct player_idfrom task limit 20;
mysql> select distinct player_id from task ;然后执行 show profiles
mysql> show profiles;
+----------+------------+------------------------------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+------------------------------------------------------------------+
8 rows in set (0.00 sec)Duration 字段表示查询所用时间
Query 字段表示查询语句
备份与恢复
备份恢复策略
进行备份或恢复操作时需要考虑一些因素：
确定要备份的表的存储引擎是事务型还是非事务型，两种不同的存储引擎备份方式在处理数据一致性方面是不太一样的。
确定使用全备份还是增量备份。全备份的优点是备份保持最新备份，恢复的时候可以花费更少的时间；缺点是如果数据量大，将会花费很多的时间，并对系统造成较长时间的压力。增量备份相反，只需要备份每天的增量日志，备份时间少，对负载压力也小；缺点就是恢复的时候需要全备份加上次备份到故障前的所有日志，恢复时间长一些。
可以考虑采用复制的方法来做异地备份，但不能代替备份，它对数据库的误操作也无能为力。
要定期做备份，备份的周期要充分考虑系统可以承受的恢复时间。备份要在系统负载较小的时候进行
确保 MySQL 打开 log-bin 选项，有了 binlog，MySQL 才可以在必要的时候做完整恢复，或基于时间点的恢复，或基于位置的恢复。
经常做备份恢复测试，确保备份时有效的，是可以恢复的。
逻辑备份和恢复
在 MySQL 中，逻辑备份的最大优点是对于各种存储引擎都可以用同样的方法来备份；而物理备份则不同，不同的存储引擎有着不同的备份方法，因此，对于不同存储引擎混合的数据库，逻辑备份会简单一点。
- 备份
MySQL 中的逻辑备份是将数据库中的数据备份为一个文本文件，备份的文件可以被查看和编辑。在 MySQL 中，可以使用 mysqldump 工具来完成逻辑备份：
// 备份指定的数据库或者数据库中的某些表
shell> mysqldump [options] db_name [tables] // 备份指定的一个或多个数据库
shell> mysqldump [options] --database DB1 [DB2,DB3...] // 备份所有数据库
shell> mysqldump [options] --all-database如果没有指定数据库中的任何表，默认导出所有数据库中的所有表。
注意： 为了保证数据备份的一致性，myisam 存储引擎在备份时需要加上 -l 参数,表示将所有表加上读锁，在备份期间，所有表将只能读而不能进行数据更新。但是对于事务存储引擎来说，可以采用更好的选项 –single-transaction，此选项使得 innodb 存储引擎得到一个快照(snapshot)，使得备份的数据能够保证一致性。
- 完全恢复
mysqldump 的恢复也很简单，将备份作为输入执行即可：
mysql -uroot -p db_name < backfile注意，将备份恢复后数据并不完整，还需要将备份后执行的日志进行重做：
mysqlbinlog binlog-file | mysql -uroot -p- 基于时间点恢复
由于误操作，比如误删除了一张表，这时使用完全恢复时没有用的，因为日志里面还存在误操作的语句，我们需要的是恢复到误操作之前的状态，然后跳过误操作语句，再恢复后面执行的语句，完成恢复。这种恢复叫不完全恢复，在 MySQL 中，不完全恢复分为 基于时间点的恢复和基于位置的恢复。 基于时间点恢复的操作步骤：
(1) 如果是上午 10 点发生了误操作，可以用以下语句用备份和 binlog 将数据恢复到故障前：
shell>mysqlbinlog --stop-date="2017-09-30 9:59:59" /data/mysql/mysql-bin.123456 | mysql -uroot -ppassword(2) 跳过故障时的时间点，继续执行后面的 binlog，完成恢复。
shell>mysqlbinlog --start-date="2017-09-30 10:01:00" /data/mysql/mysql-bin.123456 | mysql -uroot -ppassword- 基于位置恢复
和基于时间点的恢复类似，但是更精确，因为同一个时间点可能有很多条 sql 语句同时执行。恢复的操作步骤如下：
(1) 在 shell 下执行命令：
shell>mysqlbinlog --start-date="2017-09-30 9:59:59" --stop-date="2017-09-30 10:01:00" /data/mysql/mysql-bin.123456 > /tmp/mysql_restore.sql该命令将在 /tmp 目录创建小的文本文件，编辑此文件，知道出错语句前后的位置号，例如前后位置号分别为 368312 和 368315。
(2) 恢复了以前的备份文件后，应从命令行输入下面的内容：
shell>mysqlbinlog --stop-position="368312" /data/mysql/mysql-bin.123456 | mysql -uroot -ppassword
shell>mysqlbinlog --start-position="368315" /data/mysql/mysql-bin.123456 | mysql -uroot -ppassword 上面的第一行将恢复到停止位置为止的所有事务。下一行将恢复从给定的起始位置直到二进制日志结束的所有事务。因为 mysqlbinlog 的输出包括每个 sql 语句记录之前的 set timestamp 语句，因此恢复的数据和相关的 mysql 日志将反应事务执行的原时间。
物理备份和恢复
物理备份又分为冷备份和热备份两种，和逻辑备份相比，它的最大优点是备份和恢复的速度更快，因为物理备份的原理都是基于文件的 cp。
冷备份
冷备份其实就是停掉数据库服务，cp 数据文件的方法。(基本不考虑这种方法)热备份
在 MySQL 中，对于不同的存储引擎热备份的方法也有所不同。
(1) myisam 存储引擎
myisam 存储引擎的热备份有很多方法，本质其实就是将要备份的表加读锁，然后再 cp 数据文件到备份目录。常用的有以下两种方法：
使用 mysqlhotcopy 工具
mysqlhotcopy 是 MySQL 的一个自带的热备份工具
shell> mysqlhotcopy db_name [/path/to/new_directory]手工锁表 copy
在 mysqlhotcopy 使用不正常的情况下，可以用手工来做热备份
mysql>flush tables for read;
cp 数据文件到备份目录即可，
(2) innodb 存储引擎
使用第三方工具 ibbackup、xtrabackup、innobacupex
mysqldump工具
1.导出所有数据库
该命令会导出包括系统数据库在内的所有数据库
mysqldump -uroot -proot –all-databases >/tmp/all.sql
2.导出db1、db2两个数据库的所有数据
mysqldump -uroot -proot –databases db1 db2 >/tmp/user.sql
3.导出db1中的a1、a2表
注意导出指定表只能针对一个数据库进行导出，且导出的内容中和导出数据库也不一样，导出指定表的导出文本中没有创建数据库的判断语句，只有删除表-创建表-导入数据
mysqldump -uroot -proot –databases db1 –tables a1 a2 >/tmp/db1.sql
4.条件导出，导出db1表a1中id=1的数据
如果多个表的条件相同可以一次性导出多个表
字段是整形
mysqldump -uroot -proot –databases db1 –tables a1 –where=’id=1’ >/tmp/a1.sql
5.生成新的binlog文件,-F
有时候会希望导出数据之后生成一个新的binlog文件,只需要加上-F参数即可
mysqldump -uroot -proot –databases db1 -F >/tmp/db1.sql
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
