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這段時間的數據庫活動事務操做