======================================================
3、如何針對具體的SQL做優化？
* 使用Explain分析SQL語句執行計劃
mysql> explain select * from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789;
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | t_online_group_records | ALL | NULL | NULL | NULL | NULL | 47 | Using where |
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)
如上面例子所示，重點關注下type，rows和Extra：
type：使用類別，有無使用到索引。結果值從好到壞：... > range(使用到索引) > index > ALL(全表掃描)，一般查詢應達到range級別
rows：SQL執行檢查的記錄數
Extra：SQL執行的附加信息，如"Using index"表示查詢只用到索引列，不需要去讀表等
* 使用Profiles分析SQL語句執行時間和消耗資源
mysql> set profiling=1; (啟動profiles，默認是沒開啟的)
mysql> select count(1) from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789; (執行要分析的SQL語句)
mysql> show profiles;
+----------+------------+----------------------------------------------------------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+----------------------------------------------------------------------------------------------+
| 1 | 0.00043250 | select count(1) from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789 |
+----------+------------+----------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> show profile cpu,block io for query 1; (可看出SQL在各個環節的耗時和資源消耗)
+----------------------+----------+----------+------------+--------------+---------------+
| Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
+----------------------+----------+----------+------------+--------------+---------------+
...
| optimizing | 0.000016 | 0.000000 | 0.000000 | 0 | 0 |
| statistics | 0.000020 | 0.000000 | 0.000000 | 0 | 0 |
| preparing | 0.000017 | 0.000000 | 0.000000 | 0 | 0 |
| executing | 0.000011 | 0.000000 | 0.000000 | 0 | 0 |
| Sending data | 0.000076 | 0.000000 | 0.000000 | 0 | 0 |
...
* SQL優化的技巧 (只提一些業務常遇到的問題)
1、最關鍵：索引，避免全表掃描。
對接觸的項目進行慢查詢分析，發現TOP10的基本都是忘了加索引或者索引使用不當，如索引字段上加函數導致索引失效等(如where UNIX_TIMESTAMP(gre_updatetime)>123456789)
+----------+------------+---------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+---------------------------------------+
| 1 | 0.00024700 | select * from mytable where id=100 |
| 2 | 0.27912900 | select * from mytable where id+1=101 |
+----------+------------+---------------------------------------+
另外很多同學在拉取全表數據時，喜歡用select xx from xx limit 5000,1000這種形式批量拉取，其實這個SQL每次都是全表掃描，建議添加1個自增id做索引，將SQL改為select xx from xx where id>5000 and id<6000;
+----------+------------+-----------------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------------------------+
| 1 | 0.00415400 | select * from mytable where id>=90000 and id<=91000 |
| 2 | 0.10078100 | select * from mytable limit 90000,1000 |
+----------+------------+-----------------------------------------------------+
合理用好索引，應該可解決大部分SQL問題。當然索引也非越多越好，過多的索引會影響寫操作性能
2、只select出需要的字段，避免select *
+----------+------------+-----------------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------------------------+
| 1 | 0.02948800 | select count(1) from ( select id from mytable ) a |
| 2 | 1.34369100 | select count(1) from ( select * from mytable ) a |
+----------+------------+-----------------------------------------------------+
3、盡量早做過濾，使Join或者Union等後續操作的數據量盡量小
4、把能在邏輯層算的提到邏輯層來處理，如一些數據排序、時間函數計算等
5、......
PS：關於SQL優化，KM已經有足夠多文章了，所以就不講太全面了，只重點說自己1個感受：索引！基本都是因為索引！
======================================================
4、SQL層面已難以優化，請求量繼續增大時的應對策略？
* 下面是我能想到的幾個方法，每個方法又都是一篇大文章了，這裡就不展開
分庫分表
使用集群(master-slave)，讀寫分離
增加業務的cache層
使用連接池
======================================================
5、Mysql如何做主從數據同步？
* 復制機制（Replication）
master通過復制機制，將master的寫操作通過binlog傳到slave生成中繼日志(relaylog)，slave再將中繼日志redo，使得主庫和從庫的數據保持同步
* 復制相關的3個Mysql線程
1、slave上的I/O線程：向master請求數據
2、master上的Binlog Dump線程：讀取binlog事件並把數據發送給slave的I/O線程
3、slave上的SQL線程：讀取中繼日志並執行，更新數據庫
屬於slave主動請求拉取的模式
* 實際使用可能遇到的問題
數據非強一致：默認為異步復制，master和slave的數據會有一定延遲(稱為主從同步距離，一般<1s)
主從同步距離變大：可能是DB寫入壓力大，也可能是slave機器負載高，網絡波動等原因，具體問題具體分析
* 相關監控命令
show processlist ：查看Mysql進程信息，包括3個同步線程的當前狀態
show master status ：查看master配置及當前復制信息
show slave status ：查看slave配置及當前復制信息
======================================================
6、如何防止DB誤操作和做好容災？
* 業務側應做到的幾點：
重要DB數據的手工修改操作，操作前需做到2點：1 先在測試環境操作 2 備份數據
根據業務重要性做定時備份，考慮系統可承受的恢復時間
進行容災演練，感覺很必要
* Mysql備份和恢復操作
1、備份：使用mysqldump導出數據
mysqldump -u 用戶名 -p 數據庫名 [表名] > 導出的文件名
mysqldump -uroot -p test mytable > mytable.20140921.bak.sql
2、恢復：導入備份數據
mysql -uroot -p test < mytable.20140921.bak.sql
3、恢復：導入備份數據之後發送的寫操作。先使用mysqlbinlog導出這部分寫操作SQL(基於時間點或位置)
如導出2014-09-21 09:59:59之後的binlog：
mysqlbinlog --database="test" --start-date="2014-09-21 09:59:59" /var/lib/mysql/mybinlog.000001 > binlog.data.sql
如導出起始id為123456之後的binlog：
mysqlbinlog --database="test" --start-position="123456" /var/lib/mysql/mybinlog.000001 > binlog.data.sql
最後把要恢復的binlog導入db
mysql -uroot -p test < binlog.data.sql
======================================================
7、該選擇Mysql哪種存儲引擎，Innodb具有什麼特性？
* 存儲引擎簡介
插件式存儲引擎是Mysql的重要特性，Mysql支持多種存儲引擎以滿足用戶的多種應用場景
存儲引擎解決的問題：如何組織mysql數據在介質中高效地讀取，需考慮存儲機制、索引設計、並發讀寫的鎖機制等
Mysql5.0支持的存儲引擎有MyISAM、InnoDB、Memory、Merge等
* MyISAM和InnoDB的區別(只說重點了)
1、InnoDB
Mysql5.5之後默認引擎。
1 支持行鎖：並發性能好
2 支持事務：故InnoDB稱為事務性存儲引擎，支持ACID，提供了具有提交、回滾和崩潰恢復能力的事務安全
3 支持外鍵：當前唯一支持外鍵的引擎
2、MyISAM
Mysql5.5之前默認引擎。
1 支持表鎖：插入+查詢速度快，更新+刪除速度慢
2 不支持事務
* 使用show engines可查看當前Mysql支持的存儲引擎詳情
======================================================
8、Mysql內部結構有哪些層次？
* 非專業DBA，這裡只簡單貼個結構圖說明下。Mysql是開源系統，其設計思路和源代碼都出自大牛之手，有空可以學習下。
系統管理和控制工具
3 Connection Pool: 連接池。管理用戶連接
4 SQL Interface: SQL接口。接受用戶的SQL命令，並且返回用戶需要查詢的結果
5 Parser: 解析器。驗證和解析SQL語句成內部數據結構
6 Optimizer: 查詢優化器。為查詢語句選擇合適的執行路徑
7 Cache和Buffer：查詢緩存。緩存查詢的結果，有命中即可直接返回
8 Engine ：存儲引擎。Mysql數據最後組織並存儲成具體文件
