MySQL：
大規模，高併發web服務器體系結構：
Mysql複製（主從複製，組複製），nginx，lnmp，memcached，tomcat（java，serverlet，集羣），varnish（web object緩存 squid）
Nosql（redis，mongodb）
Mysql日誌類型：
錯誤日誌：啓動，運行，停止mysql時出現的問題
查詢日誌：記錄建立的客戶端連接和執行的語句
更新日誌：記錄更改數據的語句（不贊成使用該日誌）
慢日誌：記錄所有執行時間超過long_query_time秒的所有查詢或不使用索引的查詢
二進制日誌：
格式：基於語句statement；基於row行的；混合的（Mix）
默認位置：數據目錄
mysql-bin.xxxxx （編號向後轉移）
Mysql-bin.index:二進制文件索引文件
查看當前使用的二進制文件是哪一個並且處於哪一個prisation上：
mysql>show master status;
查看二進制文件內容：
Mysql>show BINLOG EVENTS IN “FILES”;
Mysql>show BINARY LOGS；查看當前mysql上所存在的仍然能夠使用的二進制文件列表。
滾動：二進制日誌達到上限就會滾動；執行flush logs；服務器重啓
mysql 裏面刪除日誌文件（不推薦使用rm命令）：
Mysql>PURGE
最大文件大小，
事物日誌，錯誤日誌，查詢日誌，中繼日誌，慢查詢日誌
Mysql記錄一個事件event：
1，Timestamp：時間戳
2.Position：位置，偏移量，offest
3，事件本身
4，server-id
雙主架構中，無法實現寫操作。如果同時寫互相矛盾的操作就有問題
垂直拆分：一個庫分成多個庫
水平拆分：拆表（依據不同的標準）
路由：知道你要查詢的目標在哪個服務器上，再整合每個查詢結果返回給用戶
二進制日誌（記錄MySQL服務器的每一次操作）用來即時點還原：
二進制日誌恢復的數據跟原來的數據不是完全一樣， 服務器有多個cpu，在處理數據的時候併發交叉進行，而二進制文件只有一個（只有一個來執行寫的操作，串行），
事務的隔離級別比較低，在並行恢復的時候仍然會產生影響。
Mysql隔離級別：
READ-UNCOMITTED:髒讀，不可重複讀，幻讀
可以看到未提交的數據
READ-COMITTED：不可重複讀，幻讀
讀取提交的數據，但是可能每次讀取的數據不一致。讀取的數據可以寫。
REPEATABLE-READ###默認使用：幻讀
可以重複讀取，但是有幻讀。讀取的行行數據不可寫，但可以往表中新增數據，在mysql中，其他事務新增的數據看不到，不會產生幻讀。採用多版本併發控制（MVCC）機制解決幻讀問題
SERIALIZABLE：
可讀，不可寫。想JAVA中的鎖，寫事務必須等待另一個事務結束。
如果使用的默認隔離級別，二進制日誌格式是statement，就很可能導致二進制文件恢復的數據不一致。
READ-*和mixed時也可能導致數據不一致，建議使用row格式。
二進制日誌本身不能替代數據備份，太慢。
Mysql複製 ： 在1上寫入數據到數據庫，與此同時在二進制文件中保存一份操作，將此文件發送到另一個服務器2上，2在收到這個文件的時候先保存的本地日誌relay log（中繼日誌）中，然後在MySQL裏面執行，執行之後保存到數據庫中。中繼日誌除了中繼從服務器的日誌外沒有任何其他作用。
Mysql允許多級複製：從服務器也可以擁有自己的從服務器，此時，主服務器的從服務器就可以使用自己的二進制文件來進行從自己到從服務器的主從複製。如果從服務器過多的話可以採用多級複製，避免了因爲複製使用過多的線程，減輕主服務器的複製線程。如果中間的服務器不需要保存數據，可以將數據庫引擎設置爲black hole （/dev/null）該創建創建，該寫就寫，寫完之後就丟棄，不保存。
複製的作用：
輔助實現備份
高可用
異地容災
分擔負載scale out；
Mysql引擎：innodb ；mylASM ；black hole
Mysql讀寫分離：mysql-proxy amoebacobar（業務邏輯拆分工具，數據拆分）
通過mysql代理來實現，當客戶端訪問的sql語句是讀語句的時候分配到從服務器上，當是寫語句的時候分配到主服務器上。
異步 半同步 同步 ：
Mysql主從複製（可以一主多從）默認是異步
MySQL5.5以後支持半同步：在一主多從中，只要有一個從服務器返回執行的消息，master就認爲是所有從服務器複製完成。
針對數據庫的不同設置從服務器的寫權限
冷備份
Drbd中的半同步：數據只要發送到tcp/ip的緩存中就好了
一個salve只能有一個master
Mysql 5.5 之前複製
5.6gtid全局事務號，在多事務執行的時候不會產生事務混亂，引入multi-thread replication多線程複製
主服務器端自動啓動dump線程，從服務器啓動I/O線程，主動去查看主服務器的二進制文件是否有改動，如果有，主服務器就會啓動dump線程複製bin-log文件到從服務器I/O線程，從服務器再開啓sql線程，讀取中繼日誌進行本地執行回放
SSL雙向驗證
Mysql主從複製過濾：結合通配符% __
主master：
Binlog-do-db:僅將指定數據庫的相關修改操作記入二進制日誌
Bin-ignore-db
從slave：
Replicate-do-db
Replicate-ignore-db
Replicate-do-table
Replicate-ingore-table
Replicate-wild-do-table
Replicate-wild-ingore-table
Mysql5.6：
1.Gtid:標識每一個主機上的事務的id，追蹤比較事務 innodb高可用依靠gtid來實現
2.多線程複製：每個數據庫只能使用一個線程。多個數據庫時使用多線程複製
併發線程工作數Slave-parallel-workers=n##0 禁用多線程功能
Mysqlreplication
Mysqlrplcheck
Mysql優化：
1，sql語句優化
2，索引優化
3，數據庫結構優化
4，innodb表優化
5，myiasm表優化
6，memroy表優化
7，理解查詢執行計劃
8，緩衝和緩存緩存常用的表，緩衝數據
9，鎖優化只能有一個操作--》用不同級別的鎖（表鎖，頁鎖，行鎖）
10，MySQL服務器優化
11，性能評估
12，mysql優化內幕
MySQL優化需要在三個不同層次協調進行：
MySQL級別，OS級別和硬件級別
1，MySQL級別的優化包括表優化，查詢優化和MySQL服務器配置優化。MySQL的各種數據結構有最終作用於OS直至硬件設備，因此還需要了解每種結構OS級別的資源的需要並最終導致的cpu和I/O操作，並在此基礎上將CPU及I/O操作需要儘量降低以提升其效率。
2，數據庫層面的優化着眼點：
1）是否正確設置了表結構的相關屬性，尤其是每個字段的字段類型是否爲最佳，是否爲特定類型的工作設置了合適的表及表字段。
2）是否爲高效查詢創建了合適的索引。
3）是否爲每張表設置了合適的村成功與引擎，並且有效利用了存儲引擎本身的優勢和特徵。
4）是否基於存儲引擎爲表選用了合適的行格式。
5）是否使用了合適的鎖策略
6）是否爲innodb的緩衝池，myiasm的鍵緩存以及MySQL查詢緩存設定了合適大小的內存空間，以便存儲頻繁訪問的數據切不會引起頁面換出。
操作系統和硬件級別的優化：
1）是否爲實際工作選用了合適的cpu
2）是否有着合適的大小的物理內存，並通過合理的配置平衡內存和磁盤資源
3）是否選用了合適的網絡設備並正確地配置了網絡對整體系統也有着重大影響。延遲和帶寬是網絡延遲的限制因素。常見問題有丟包。
4）是否基於操作系統選擇了合適的文件系統
5）MySQL是否對線程進行了有效的管理。
Mylasm引擎：數據挖掘，性能較優
.MYD數據
.MYI索引
.frm表結構
Innodb引擎：在線事務
.frm表結構
.ibd: 表空間
數據
索引