由數據庫和數據庫實例組成，是單進場多線程架構。
數據庫：物理操作系統文件或者其它文件的集合，在mysql中，數據庫文件可以是frm、myd、myi、ibd等結尾的文件，當使用ndb存儲引擎時候，不是os文件，是存放於內存中的文件。
數據庫實例：由數據庫後台進程/線程以及一個共享內存區組成，共享內存可以被運行的後台進程/線程所共享。
Mysql主要文件類型有如下幾種：
參數文件：mysql實例啟動的時候在哪裡可以找到數據庫文件，並且指定某些初始化參數，這些參數定義了某種內存結構的大小等設置，還介紹了參數類型以及定義作用域。
日志文件：記錄mysql對某種條件做出響應時候寫入的文件。
Socket文件：當用linux的mysql命令行窗口登錄的時候需要的文件
Pid文件：mysql實例的進程文件
Mysql表結構文件：存放mysql表結構定義文件
存儲引擎文件：記錄存儲引擎信息的文件。
? 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
我們可以在錯誤日志文件裡面看到一些數據庫啟動信息，以及告警信息還有就是報錯信息
慢查詢日志就是記錄運行較慢的sql語句信息，給sql語句的優化帶來很好的幫助，可以設置一個閥值，將運行時間超過該閥值的sql語句的運行信息都記錄到slow log日志裡面去。該閥值可以通過long_query_time來設置，也可以設置到毫秒微秒：
但是需要注意一點：對於運行時間等於該閥值的，就不會記錄在內了。
另外一個參數是log_queries_not_using_indexes，如果運行的sql沒有使用索引，只要超過閥值了也會記錄在慢查詢日志裡面的。
long_query_time=0 （記錄所有sql可以做審計） ，dba可以通過這個審計來推動業務的發展，可以知道哪些業務開展的好那些業務開展的不好，通過慢sql可以分析出哪些應用性能較差需要優化改進，dba的最大職能以及貢獻就在於通過對數據庫的維護來推動業務的發展和進步。從數據到業務，這是我們需要一直努力的方向。
慢查詢日志還可以記錄在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日志參數：
max_binlog_size：指定了單個二進制文件的最大值，如果超過了該值，就會產生新的日志文件，後綴名+1，並且記錄到.index文件裡面。默認值是1G，不過從多年的dba生涯總結來說，64M是通用的大小設置。
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、row、mixed格式
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)會出現問題).
2.Row:不記錄sql語句上下文相關信息，僅保存哪條記錄被修改。
優點： binlog中可以不記錄執行的sql語句的上下文相關的信息，僅需要記錄那一條記錄被修改成什麼了。所以rowlevel的日志內容會非常清楚的記錄下每一行數據修改的細節。而且不會出現某些特定情況下的存儲過程，或function，以及trigger的調用和觸發無法被正確復制的問題
缺點:所有的執行的語句當記錄到日志中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日志內容,比如一條update語句，修改多條記錄，則binlog中每一條修改都會有記錄，這樣造成binlog日志量會很大，特別是當執行altertable之類的語句的時候，由於表結構修改，每條記錄都發生改變，那麼該表每一條記錄都會記錄到日志中。
3.Mixedlevel: 是以上兩種level的混合使用，一般的語句修改使用statment格式保存binlog，如一些函數，statement無法完成主從復制的操作，則采用row格式保存binlog,MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日志形式，也就是在Statement和Row之間選擇一種.新版本的MySQL中隊rowlevel模式也被做了優化，並不是所有的修改都會以rowlevel來記錄，像遇到表結構變更的時候就會以statement模式來記錄。至於update或者delete等修改數據的語句，還是會記錄所有行的變更。
使用以下函數的語句也無法被復制：
*LOAD_FILE()
*UUID()
*USER()
*FOUND_ROWS()
*SYSDATE() (除非啟動時啟用了--sysdate-is-now 選項)
同時在INSERT ...SELECT 會產生比 RBR 更多的行級鎖
row、mixed
Linux系統下 本地連接mysql可以采用linux域套接字socket方式 ，需要一個套接字socket發文件，可以有參數socket控制，一般默認在/tmp目錄下，也可以通過如下2種方式查看：
1， 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]#
2，
3，my.cnf
socket = /usr/local/mysql/mysql.sock
當mysql實例啟動的時候，會將自己的進程id寫入一個文件中，該文件即為pid文件，由參數pid_file控制，默認路徑位於數據庫目錄下，可以通過以下三種方式查看：
1)、show variableslike 'pid_file';
2)、ps -eaf|grepmysql |grep pid
3)、My.cnf （pid-file = /usr/local/mysql/mysqld.pid）
*.frm
*.ibd
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 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%';
存在於共享表空間ibdata1裡面，有一個回滾段地址，裡面存放了頭信息，配置頭信息，段的頭信息，裡面存儲了與redo相反的數據更新操作，如果rollback的話，就把undo段裡面數據回寫到數據文件裡面。
如果用了獨立表空間的話，則直接存儲到表私自的空間中，而不存儲到共享表空間中。在innodb存儲引擎中，undo log用來完成事務的回滾以及MVCC的功能
Redo與undo他們並不是各自獨立沒有關系的，他們是有關聯的，交替合作來保證數據的一致性和安全性，
