MySql體系結構
由數據庫和數據庫實例組成，是單進場多線程架構。
數據庫：物理操作系統文件或者其它文件的集合，數據庫文件可以是frm、myd、myi、ibd等結尾的文件。當使用ndb存儲引擎時候，不是os文件，是存放於內存中的文件。
數據庫實例：由數據庫後臺進程/線程以及一個共享內存區組成，共享內存可以被運行的後臺進程/線程所共享。
MySql文件類型
Mysql主要文件類型有如下幾種：
參數文件：mysql實例啓動的時候在哪裏可以找到數據庫文件，並且指定某些初始化參數，這些參數定義了某種內存結構的大小等設置，還介紹了參數類型以及定義作用域。
日誌文件：記錄mysql對某種條件做出響應時候寫入的文件。
Socket文件：當用linux的mysql命令行窗口登錄的時候需要的文件
Pid文件：mysql實例的進程文件
Mysql表結構文件：存放mysql表結構定義文件
存儲引擎文件：記錄存儲引擎信息的文件。
參數文件my.cnf
Mysql實例啓動時，會先讀取配置參數文件my.cnf
尋找my.cnf位置
（1）：默認情況： mysql–help|grep my.cnf
（2）：後臺進程去找：ps–eaf|grep mysql
（3）：全局搜索：find /-name my.cnf
可以用vi直接維護修改裏面的參數值
（1）dynamic ：可以通過set進行實時修改
（2）static，只能在my.cnf裏面修改，需要restart生效
Mysql參數文件中的參數可以分爲2種類型：動態（dynamic）參數和靜態參數（staitic）
動態參數意味着可以在mysql實例運行中進行修改，set global sort_buffer_size=32999999;修改後，別的connection重新進行連接就可以生效了。
生效範圍分爲：global和session。
靜態的說明在整個mysql實例運行期間不得進行修改，就類似一個只讀的read only
日誌文件
日誌文件記錄了影響mysql數據庫的各種類型活動，常見的日誌文件有錯誤日誌、二進制日誌、慢查詢日誌、全查詢日誌、redo日誌、undo日誌
錯誤日誌
錯誤日誌對mysql的啓動、運行、關閉過程進行了記錄，mysql dba在遇到問題時候，第一時間應該查看這個錯誤日誌文件，該文件不但記錄了出錯信息，還記錄了一些警告信息以及正確信息，這個error日誌文件類似於oracle的alert文件，只不過默認情況下是以error結尾。可以通過show variables like ‘log_error’;
錯誤文件的文件名爲服務器的主機名。當然也可以在my.cnf裏面設置錯誤日誌文件的路徑：
Vim my.cnf
log-error=/usr/local/mysql/mysqld.log我們可以在錯誤日誌文件裏面看到一些數據庫啓動信息，以及告警信息還有就是報錯信息
慢查詢日誌slow log
慢查詢日誌就是記錄運行較慢的sql語句信息，給sql語句的優化帶來很好的幫助，可以設置一個閥值，將運行時間超過該閥值的sql語句的運行信息都記錄到slow log日誌裏面去。該閥值可以通過long_query_time來設置，也可以設置到毫秒微秒：
對於運行時間等於該閥值的，就不會記錄在內了。
另外一個參數是log_queries_not_using_indexes，如果運行的sql沒有使用索引，只要超過閥值了也會記錄在慢查詢日誌裏面的。
慢查詢日誌還可以記錄在table裏面，
Slow_log表，也可以將慢查詢日誌放入一張表裏面
show variables like ‘log_output’;查看如果是file就存放在slow log裏面，如果是table就在slow_log表裏面。
全查詢日誌
記錄了對mysql數據庫所有的請求信息，不論這些請求信息是否得到了正確的執行，默認文件名爲主機名.log，你可以看到對access denied的請求。
數據庫審計+ 問題排查跟蹤（損失3%-5%性能）
二進制日誌
記錄了對數據庫進行變更的操作，但是不包括select操作以及show操作，因爲這類操作對數據庫本身沒有沒有修改，如果你還想記錄select和show的話，你就需要查看前面的全查詢日誌，另外binlog還包括了執行數據庫更改操作時間和執行時間等信息。
二進制的主要作用有如下2個：
1.恢復 recovery。某些數據的恢復需要二進制日誌，在全庫文件恢復後，可以在此基礎上通過二進制日誌進行point-to-time的恢復。
2.複製（replication）。其原理和恢復類似，通過複製和執行二進制日誌使得一臺遠程的mysql數據庫（slave）於一臺mysql數據庫（master）進行實時同步。
通過在my.cnf裏面設置log-bin =/home/data/mysql/binlog/mysql-bin.log生效，默認是在數據目錄datadir下面
binlog_cache_size：
使用innodb存儲引擎時候，所有未提交uncommitted的二進制日誌會被記錄到一個緩存中，等該事務提交時committed直接將緩衝中的二進制日誌寫入二進制日誌文件裏面，而該緩衝的大小就由binlog_cache_size來決定，這個緩衝區是基於session的，也就是每一個線程需要事務的時候，mysql都會分配一個binlog_cache_size的緩存，因此改值設置需要非常小心，不能設置過大，免得內存溢出了。
sync_binlog：
sync_binlog=N，大概就是表示每次寫緩衝N次就同步到磁盤文件中，如果將N設置爲1的話，每次都會寫入binlog磁盤文件中，這是最保險最安全的，如果N>1，在意外發生的時候，就表示會有N-1個dml沒有被寫入binlog中，有可能就會發生主動數據不一致的情況。
binlog-do-db、binlog-ingore-db：
表示需要寫入或者忽略寫入哪些庫的日誌，默認爲空，表示可以將所有庫的日誌寫入到二進制文件裏面。
log-slave-update：
啓用從機服務器上的slave日誌功能，使這臺計算機可以用來構成一個鏡像鏈(A->B->C) ，可以讓從庫上面產生二進制日誌文件，在從庫上再掛載一個從庫。
binlog-format：日誌格式
Statement：每一條會修改數據的sql都會記錄在binlog中。
優點：不需要記錄每一行的變化，減少了binlog日誌量，節約了IO，提高性能。(相比row能節約多少性能與日誌量，這個取決於應用的SQL情況，正常同一條記錄修改或者插入row格式所產生的日誌量還小於Statement產生的日誌量，但是考慮到如果帶條件的update操作，以及整表刪除，alter表等操作，ROW格式會產生大量日誌，因此在考慮是否使用ROW格式日誌時應該跟據應用的實際情況，其所產生的日誌量會增加多少，以及帶來的IO性能問題。)
缺點：由於記錄的只是執行語句，爲了這些語句能在slave上正確運行，因此還必須記錄每條語句在執行的時候的一些相關信息，以保證所有語句能在slave得到和在master端執行時候相同的結果。另外mysql 的複製,像一些特定函數功能，slave可與master上要保持一致會有很多相關問題(如sleep()函數，last_insert_id()，以及user-definedfunctions(udf)會出現問題).
使用以下函數的語句也無法被複制：
*LOAD_FILE()
*UUID()
*USER()
*FOUND_ROWS()
*SYSDATE() (除非啓動時啓用了–sysdate-is-now 選項)
同時在INSERT …SELECT 會產生比 RBR 更多的行級鎖
Row:不記錄sql語句上下文相關信息，僅保存哪條記錄被修改。
優點： binlog中可以不記錄執行的sql語句的上下文相關的信息，僅需要記錄那一條記錄被修改成什麼了。所以rowlevel的日誌內容會非常清楚的記錄下每一行數據修改的細節。而且不會出現某些特定情況下的存儲過程，或function，以及trigger的調用和觸發無法被正確複製的問題
缺點:所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容,比如一條update語句，修改多條記錄，則binlog中每一條修改都會有記錄，這樣造成binlog日誌量會很大，特別是當執行altertable之類的語句的時候，由於表結構修改，每條記錄都發生改變，那麼該表每一條記錄都會記錄到日誌中。
Mixedlevel: 是以上兩種level的混合使用，一般的語句修改使用statment格式保存binlog，如一些函數，statement無法完成主從複製的操作，則採用row格式保存binlog,MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種.新版本的MySQL中隊rowlevel模式也被做了優化，並不是所有的修改都會以rowlevel來記錄，像遇到表結構變更的時候就會以statement模式來記錄。至於update或者delete等修改數據的語句，還是會記錄所有行的變更。
套接字socket文件
Linux系統下 本地連接mysql可以採用linux域套接字socket方式 ，需要一個套接字socket發文件，可以有參數socket控制，一般默認在/tmp目錄下，也可以通過如下方式查看：
ps -eaf|grep mysql |grep socket
[root@data01 binlog]# ps -eaf|grep mysql|grep socket
mysql 3152 1979 0 Feb28 ? 00:00:02 /usr/local/mysql/bin/mysqld--basedir=/usr/local/mysql --datadir=/home/data/mysql/data--plugin-dir=/usr/local/mysql/lib/plugin --user=mysql--log-error=/usr/local/mysql/mysqld.log --open-files-limit=8192--pid-file=/usr/local/mysql/mysqld.pid --socket=/usr/local/mysql/mysql.sock--port=3306
[root@data01 binlog]#show variables like 'socket';my.cnf, socket = /usr/local/mysql/mysql.sockpid文件
當mysql實例啓動的時候，會將自己的進程id寫入一個文件中，該文件即爲pid文件，由參數pid_file控制，默認路徑位於數據庫目錄下，可以通過以下三種方式查看：
show variableslike 'pid_file';ps -eaf|grepmysql |grep pidMy.cnf （pid-file = /usr/local/mysql/mysqld.pid）表結構文件
*.frm
*.ibd
innodb存儲文件
innodb存儲引擎在存儲設計上模仿了oracle，該文件就是默認的表空間文件，可以通過參數innodb_data_file_path來進行設置，格式如下：
innodb_data_file_path= IBdata1:128M;IBdata2:128M:autoextend可以用多個文件組成一個表空間，同時制定文件的屬性，
IBdata1和IBdata2位於不同的磁盤組上，則可以對性能帶來一定程度的提升。文件後面的屬性表示文件大小，autoextend表示還可以擴展。
但是如果設置了innodb_file_per_table爲true後，那麼表數據文件就會在單獨的.ibd文件裏面，不在這個ibdata文件裏面了。
redo文件
所有的數據庫都是日誌先行，先寫日誌，再寫數據文件，所以纔會有redo log的規則。
默認情況下會有2個文件名稱分別爲ib_logfile0 和ib_logfile1 ，在mysql數據庫目錄下可以看到這2個文件，這個對innodb存儲引擎非常重要，因爲它們記錄了對於innodb存儲引擎的事務日誌。
重做日誌文件的主要目的是：萬一實例或者介質失敗media failure，重做日誌就可以派上用場，如果數據庫由於所在主機掉電導致實例失敗，innodb存儲引擎會使用重做日誌恢復到掉電前的時刻，以此來保證數據的完整性。
每個innodb存儲引擎至少有一個重做日誌組，每組至少有2個重做日誌文件，如默認的ib_logfile0 和ib_logfile1，爲了得到更高的可靠性，你可以設置多個組，也可以將每組放在不同的磁盤上面，來提高性能
LSN logsequence number：
遞增產生的，可以唯一的標記一條redo日誌，對於我們數據庫故障恢復都是非常重要的，可以唯一定位數據庫運行狀態，至於如何定位細節，大家可以去看下redo、undo的源碼，源碼：在”storage/innobase/include/log0log.h”
查看參數設置：
show variables like 'innodb%log%';undo日誌
存在於共享表空間ibdata1裏面，有一個回滾段地址，裏面存放了頭信息，配置頭信息，段的頭信息，裏面存儲了與redo相反的數據更新操作，如果rollback的話，就把undo段裏面數據回寫到數據文件裏面。
如果用了獨立表空間的話，則直接存儲到表私自的空間中，而不存儲到共享表空間中。在innodb存儲引擎中，undo log用來完成事務的回滾以及MVCC的功能