linux复盘：mysql数据引擎和binlog恢复

使用MySQL当然会接触到MySQL的存储引擎，在新建数据库和新建数据表的时候都会看到。

MySQL默认的存储引擎是MyISAM，其他常用的就是InnoDB了。

至于到底用哪种存储引擎比较好？这个问题是没有定论的，需要根据你的需求和环境来衡量。所以对这两种引擎的概念、原理、异同和各自的优劣点有了详细的了解之后，再根据自己的情况选择起来就容易多了。

	MyISAM	InnoDB
存储结构	每张表被存放在三个文件： frm-表格定义 MYD(MYData)-数据文件 MYI(MYIndex)-索引文件	所有的表都保存在同一个数据文件中（也可能是多个文件，或者是独立的表空间文件），InnoDB表的大小只受限于操作系统文件的大小，一般为2GB
存储空间	MyISAM可被压缩，存储空间较小	InnoDB的表需要更多的内存和存储，它会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引
可移植性、备份及恢复	由于MyISAM的数据是以文件的形式存储，所以在跨平台的数据转移中会很方便。在备份和恢复时可单独针对某个表进行操作	免费的方案可以是拷贝数据文件、备份 binlog，或者用 mysqldump，在数据量达到几十G的时候就相对痛苦了
事务安全	不支持 每次查询具有原子性	支持 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表
AUTO_INCREMENT	MyISAM表可以和其他字段一起建立联合索引	InnoDB中必须包含只有该字段的索引
SELECT	MyISAM更优
INSERT		InnoDB更优
UPDATE		InnoDB更优
DELETE		InnoDB更优 它不会重新建立表，而是一行一行的删除
COUNT without WHERE	MyISAM更优。因为MyISAM保存了表的具体行数	InnoDB没有保存表的具体行数，需要逐行扫描统计，就很慢了
COUNT with WHERE	一样	一样，InnoDB也会锁表
锁	只支持表锁	支持表锁、行锁 行锁大幅度提高了多用户并发操作的新能。但是InnoDB的行锁，只是在WHERE的主键是有效的，非主键的WHERE都会锁全表的
外键	不支持	支持
FULLTEXT全文索引	支持	不支持 可以通过使用Sphinx从InnoDB中获得全文索引，会慢一点

总的来说，MyISAM和InnoDB各有优劣，各有各的使用环境。

但是InnoDB的设计目标是处理大容量数据库系统，它的CPU利用率是其它基于磁盘的关系数据库引擎所不能比的。

我觉得使用InnoDB可以应对更为复杂的情况，特别是对并发的处理要比MyISAM高效。同时结合memcache也可以缓存SELECT来减少SELECT查询，从而提高整体性能。

如果需要修改默认引擎这里给出方案：

因为MySQL默认的是MyISAM数据引擎，不支持事务也不支持外键，所以需要用到Innodb引擎，于是决定将mysql的默认引擎设置为innodb

1 . 查看MySQL存储引擎是用的哪个？登录MySQL数据库，在mysql>提示符下搞入show engines;命令。
+------------+---------+----------------------------------------------------------------+
| Engine | Support | Comment |
+------------+---------+----------------------------------------------------------------+
| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables |
| InnoDB | YES | Supports transactions, row-level locking, and foreign keys |

说明目前默认的数据引擎是MyISAM，并且也支持InnoDB引擎。

2. 设置InnoDB为默认引擎：在配置文件my.cnf中的 [mysqld] 下面加入default-storage-engine=INNODB 一句，保存。

3. 重启mysql服务器：mysqladmin -u root -p shutdown或者service mysqld restart 登录mysql数据库，在mysql>提示符下搞入show engines;命令。如果出现 InnoDB |DEFAULT，则表示我们 设置InnoDB为默认引擎成功。

binlog恢复MySQL数据库

如果不小心对数据库进行误操作，而又没有及时备份怎么办？这恐怕是广大的coder经常遇到的一类问题。
我今天就因为不小心删除了某个数据库，但最后的备份是1个礼拜前的，唯一能解决的办法就是通过mysqlbinlog来恢复了。解决方案如下：

如果MySQL服务器启用了二进制日志，你可以使用mysqlbinlog工具来恢复从指定的时间点开始(例如，从你最后一次备份)直到现在或另一个指定的时间点的数据。
关于启用二进制日志的信息，参见5.11.3节，“二进制日志”。对于mysqlbinlog的详细信息，参见mysql手册8.6节，“mysqlbinlog：用于处理二进制日志文件的实用工具”。
要想从二进制日志恢复数据，你需要知道当前二进制日志文件的路径和文件名。
一般可以从配置文件(一般情况，Linux下为my.cnf ，windows系统下为my.ini，取决于你的系统)中找到路径。如果未包含在选项文件中，当服务器启动时，可以在命令行中以选项的形式给出。
启用二进制日志的选项为–log-bin。
要想确定当前的二进制日志文件的文件名，输入下面的MySQL语句：
SHOW BINLOG EVENTS \G;
或者还可以从命令行输入下面的内容：
mysql –user=root -pmypasswd -e ‘SHOW BINLOG EVENTS \G’ 将密码mypasswd替换为你的MySQL服务器的root密码。

比如得到的日志文件名为：
mysql-bin.000001 1. 指定恢复时间 对于MySQL5.1.54，可以在mysqlbinlog语句中通过–start-date和–stop-date选项指定DATETIME格式的起止时间。

举例说明，比如在今天下午14:02(今天是2012年3月15日)，不小心执行SQL语句删除了一个数据表，但发现没有最新的备份（当然，这只是开发环境，并不是正式的生产环境，正式环境还得定时做数据备份）。要想恢复表和数据，可以通过mysqlbinlog恢复指定时间的备份，输入：
mysqlbinlog –stop-date=”2012-03-15 14:02:00″ /data1/log/mysql/mysql-bin.000001 | mysql -u root -pmypasswd
该命令将恢复截止到在–stop-date选项中以DATETIME格式给出的日期和时间的所有数据。

如果你没有检测到输入的错误的SQL语句，可能你想要恢复后面发生的数据库活动。
根据这些，你可以用起使日期和时间再次运行mysqlbinlog：
mysqlbinlog –start-date=”2012-03-15 00:01:00″ /data1/log/mysql/mysql-bin.000001 | mysql -u root -pmypasswd

在该行中，从今天凌晨0:01登录的SQL语句将运行，组合执行前夜的转储文件和mysqlbinlog的两行可以将所有数据恢复到今天凌晨0:01前一秒钟。
你应检查日志以确保时间确切。下一节介绍如何实现。

2. 指定时间段恢复 通过mysqlbinlog –start-date 和–stop-date恢复指定时间段的数据库活动记录：
mysqlbinlog–start-date=”2012-03-0902:00:00″–stop-date=”2012-03-1514:00:00″/data1/log/mysql/mysql-bin.000001 > /tmp/mysql_restore_030915.sql
通过这种方式，就能获取最后一个备份的文件时间2012-03-09 02:00:00到今天删除数据库之前2012-03-15 14:02这段时间的数据库活动事务操作