MySQL通常分爲三層架構，第一層用於處理基於網絡的客戶端/服務器的工具或者服務都有的基礎處理-連接處理、授權認證、安全；第二層用於查詢解析、分析、優化、緩存以及所有的內置函數，所有跨存儲引擎的功能都在這一層實現：存儲過程、觸發器、視圖；第三層包含了存儲引擎。存儲引擎負責MySQL中數據的存儲和提取。服務器通過API與存儲引擎進行通信。這些接口屏蔽了不同引擎之間的差異，使得這些差異對上層的查詢過程透明。
連接管理與安全性
每個客戶端連接都會在服務器進程中擁有一個線程，這個連接的查詢只會在這個單獨的線程中執行，該線程只能輪流在某個CPU核心或者CPU中運行。服務器會負責緩存線程，因此不需要爲每個新建的連接創建或者銷燬線程。
事務
事務是指一組原子性的SQL查詢，或者一個獨立的工作單元。
一個良好的事務處理系統具備如下特徵：
原子性（atomicity):一個事務必須被視爲一個不可分割的最小工作單元，整個事務中的所有操作要麼提交成功，要麼全部失敗滾回。對於一個事務來說，不可能只執行其中的一部分操作，這就是事務的原子性。
一致性(constitency):數據庫總是從一個一致性的狀態轉到另一個一致性的狀態。
隔離性（isolation):一個事務所做的修改在最終提交以前，對其他事務是不可見的。
持久性(durability):一旦事務提交，所做的修改就會永久保存到數據庫。
隔離級別
READ UNCOMMITED：事務中的修改，即使沒有提交，對其他事務也都是可見的。事務可以讀取未提交的數據，這也被稱爲髒讀。
READ COMMITED:大多數數據庫系統的默認級別是READ COMMITTED(但MySQL不是）。READ COMMITTED滿足前面提到的隔離性的簡單定義：一個事務開始時，只能看見已經提交的事務所做的修改。
REPEATABLE READ:解決了髒讀的問題、該級別保證了在同一個事務中多次讀取同樣記錄的結果是一致的。該級別存在另一個問題-幻讀，指當某個事物在讀取某個範圍內的記錄時，會產生幻行。
SERIALIZABLE:是最高的級隔離級別。通過強制事物串行，避免了前面說的幻讀的問題。
死鎖
死鎖產生的原因：有些原因是真正的數據衝突，這種情況通常很難避免，有些則是由於存儲引擎的實現方式導致的。
Mysql中的存儲引擎
InnoDB、Archive、blackhole、CSV、Federated、memory、Merge、NDB Clster以及第三方存儲引擎XtraDB和PBXT。
引擎的特點：
自動提交（AUTOCOMMIT)：MySQL默認模式。通過設置AUTOCOMMIT變量來啓動或者禁用自動提交模式；
AUTOCOMMIT爲1表示啓動，0表示禁用。
多版本併發控制
SELECT
InnoDB會根據以下兩個條件檢查每行記錄：
InnoDB只查找版本遭遇當前事務版本的數據行，這樣可以確保事務讀取的行，要麼是在事務開始前已經存在的，要麼是事務自身插入或者修改過的。
行的刪除版本要麼未定義，要麼大於當前事務版本號。這樣可以確保事務讀取到的行，在事務開始之前未被刪除。
INSERT
InnoDB爲新插入的每一行保存當前系統版本好。
DELETE
ＩｎｎｏＤＢ爲刪除的二米一行保存當前系統版本號作爲行版本號。
UPDATE
ＩｎｎｏＤＢ爲插入一行新紀錄，保存當前系統版本號作爲行版本號，同時保存當前系統版本號到原來的行作爲行刪除標識。
ＭｙＩＳＡＭ
具有全文索引、壓縮、空間函數等特點，但是不支持事務或行級鎖，而且有一個缺陷就是崩潰後無法安全恢復。
就準測試(benchmark)
針對系統設計的一種壓力測試。爲了掌握系統的行爲。
應用場景：
驗證基於系統的一些假設，確認這些假設是否符合實際情況。
重現系統中的某些異常行爲，以解決這些異常。
測試系統當前的運行情況。
模擬比當前系統更高的負載，以便找出系統隨着壓力增加而可能遇到的擴展性瓶頸。
規劃未來的業務增長。
測試應用適應可變環境的能力。
測試不同的硬件、軟件和操作配置。
證明新採購的設備是否配置正確。
基準測試的策略
集成式（full-stack）和單組件（single-component)
集成式測試場景：
測試整個應用系統，包括web服務器、應用代碼、網絡和數據庫；
MySQL並非總是應用的瓶頸，通過整體測試可以揭示這個問題；
只有針對整體測試，才能發現各部分之間的緩存帶來的影響；
整體應員工的集成式測試更能揭示應員工的真實表現。
單組件測試應用場景：
需要比較不同的schema或者查詢的性能。
針對應用中某個具體問題的測試；
爲了避免漫長的基準測試，可以通過短期的基準測試。
測試指標
吞吐量、響應時間或者延遲、併發性（正在進行的併發操作，或者同時工作中的線程數或連接數，同時處理事務的能力）、可擴展性。
基準測試方法
進行基準測試之前應避免如下如問題:
使用真實數據的子集而不是全集。
使用錯誤的數據分佈；
使用不真實的分佈參數；
在多用戶場景中，只做單用戶的測試；
在單服務器上測試分佈式應用；
與真實用戶行爲不匹配；
反覆執行同一個查詢；
沒有檢查錯誤；
忽略了系統預熱的過程；
使用默認的服務器配置；
測試時間太短。
基準測試工具
集成式測試工具：
ab是一個appache HTTP服務器基準測試工具。測試服務器每秒最多可以處理請求數量。
http-load用作web服務器測試，可以通過一個輸入文件提供多個URL，工具在這些URL中隨機選擇進行測試。
JMeter是一個Java應用程序，可以加載其他應用並測試其性能。通常被用於測試Web應用。
單組件測試工具：
mysqlslap：用於模擬服務器的負載，並輸出計時信息。
MySQL Benchmark Suite：MySQL提供的基準測試套件，可以用在不同數據庫服務器上進行比較測試。
Super Smack:用於MySQL和postgreSQL的基準測試工具，可以提供壓力測試和負載生成。
Database Test Suite：由開源軟件開發實驗室（OSDL）設計，類似於某些工業標準測試的測試工具集。
Percona’s TPCC-MySQl Tool：類似於TPC-C的基準工具集。
sysbench：多線程系統壓力測試工具。它可以根據影響數據庫服務器性能的各種因素來評估系統的性能。
sysbench的文件I/O基準測試
準備階段：生成測試用到的數據文件，生成的數據文件至少要比內存大。如果文件中的數據能完全放入內存中，則操作系統緩存大部分的數據，導致測試結果無法體現I/O密集型的工作負載。通過下面的命令創建一個數據集：
sysbench --test=fileio --file-total-size=150G prepare
運行階段：針對不同的I/O類型有不同的測試選項：
seqwr:順序寫入
seqrewr:順序重寫
seqrd:順序讀取
rndrd：隨機讀取
rndwr:隨機寫入
rndnrw:混合隨機讀/寫
sysbench --test=fileio --file-total-size150G --file-test-mode=rndrw/ --init-rng=on --max-time=300 --max-requests=0 run
測試完成之後清除生成的測試文件：
sysbench --test=fileio --file-total-sze=150G cleanup
sysbench的OLTP基準測試
生成數據表：
sysbench --test=oltp --oltp-table=1000000 --mysql-db=test/ --mysql-user=root prepare
執行測試：
sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --mysql-user=root --max-time=60 --oltp-read-only=on --max-requests=0 --num-threads=8 run
其他sysbench特性
內存、線程、互斥鎖、順序寫等