1.為什么使用Msyql
開放、免費
2.mysql介紹
關系型數據庫管理系統（RDBMS）來存儲和管理的大數據量。
所謂的關系型數據庫，是建立在關系模型基礎上的數據庫，借助於集合代數等數學概念和方法
來處理數據庫中的數據。
RDBMS即關系數據庫管理系統(Relational Database Management System)的特點：
1.數據以表格的形式出現
2.每行為各種記錄名稱
3.每列為記錄名稱所對應的數據域
4.許多的行和列組成一張表單
5.若干的表單組成database
注：
保證數據一致性。
關系型數據庫，表與表之間存在對應關系。
非關系行數據庫，表之間不存在關系，數據獨立，隨便存。
MYSQL是最流行的關系型數據庫管理系統 。
支持大型的數據庫。可以處理擁有上千萬條記錄的大型數據庫。
使用標准的SQL數據語言形式。
可以允許於多個系統上，並且支持多種語言。
這些編程語言包括C、C++、Python、Java、Perl、PHP、Eiffel、Ruby和Tcl等。
對PHP有很好的支持，PHP是目前最流行的Web開發語言。
支持大型數據庫，支持5000萬條記錄的數據倉庫，32位系統表文件最大可支持4GB，
64位系統支持最大的表文件為8TB。
是可以定制的，采用了GPL協議，你可以修改源碼來開發自己的MYSQL系統。
GPL協議 。雙向授權協議，就是通過賬號密碼繼續訪問。 GPL就是一個為了保護軟件自由的一個協議，它強調的是開源，與錢無關。
3.mysql執行原理
闡述mysql系統的各個模塊是如何相親相愛的完成一個我們認為的很簡單的查詢工作的。
我們對啟動mysql，客戶端建立連接，請求query，得到返回結果，最終退出。這樣一整個過程來進行分析。
第一步：當我們執行啟動mysql系統的命令之后，mysql的初始化模塊就從系統配置文件中讀取系統參數和命令行參數，並按照參數來初始化整個系統，如申請並分配buffer，初始化全局變量，以及各種結構等。同時各個存儲引擎也被啟動，進行各自的初始化工作。當整個系統初始化結束后，由連接管理模塊接手，連接管理模塊會啟動處理客戶端連接請求的監聽程序，包括tcp/ip的網絡監聽，還有unix的socket，這時候，mysql server就基本啟動完成，准備好接受客戶端的請求了。
第二步：當連接管理模塊監聽到客戶端的連接請求（借助網絡交互模塊的相關功能），雙方通過Client & Server交互協議模塊所定義的協議“寒暄”幾句之后，連接管理模塊就會將連接請求轉發給線程管理模塊，去請求一個連接線程。
第三步：線程管理模塊接着將控制權交給連接線程模塊，告訴連接線程模塊，現在我這邊連接請求過來了，需要建立連接，你趕快處理一下。連接線程模塊會在接收到連接請求后，首先檢查當前連接線程池中是否有被cache的空閑連接線程，如果有，就取出一個和客戶端請求連接上，如果沒有空閑的連接線程，則建立一個新的連接線程與客戶端請求連接。當然，連接線程模塊並不是在接收到連接請求后馬上就會取出一個連接線程和客戶端連接，而是首先通過調用用戶模塊進行授權檢查，只有客戶端請求通過了授權檢查后，他才會將客戶端請求和負責請求的連接線程連上。
在MySQL中，將客戶端的請求分為了兩種類型，一種是query，需要調用Parser也就是Query解析和轉發模塊的解析才能夠執行的請求；一種是command，不需要調用Parser就可以執行的請求。如果我們的初始化配置打開了Full Query Logging(慢日志)的功能，那么Query解析與轉發模塊就會調用日志記錄模塊將請求計入日志。不管是一個Query類型的請求還是一個command類型的請求，都會被記錄進入日志，所以出於性能考慮一般很少打開Full Query Logging的功能。
第四步：當客戶端請求和連接線程“互換暗號（互通協議）”接上頭之后，連接線程就開始處理客戶端請求發送過來的各種命令（或者query），接受相關請求。他將收到的query語句轉發給Query解析和轉發模塊，Query解析器先對Query進行基本的語義和語法解析，然后根據命令類型的不同，有些會直接處理，有些會分發給其他模塊來處理。
如果是一個Query類型的請求，會將控制權交給Query解析器，Query解析器首先分析是不是一個select類型的query，如果是，則調用查詢緩存模塊，讓它檢查該query在query cache中是否已經存在。如果有，則直接將cache中的數據返回給連接線程模塊。然后通過與客戶端連接的線程將數據輸出給客戶端。如果不是一個可以被cache的query類型，或者cache中沒有改query的數據，那么query將被繼續傳回Query解析器，讓Query解析器進行相應處理，在通過Query分發器分發給相關處理模塊。
第五步：如果解析器解析結果是一條未被cache的select語句，則將控制權交給Optimizer，也就是Query優化器模塊，如果是DML或者是DDL語句，則會交給表變更管理模塊，如果是一些更新統計信息、檢測、修復和整理類的query則會交給表維護模塊去處理，復制相關的query則轉交給復制模塊去進行相應的處理，請求狀態的query則交給狀態收集報告模塊。實際上表變更管理模塊根據所對應的處理請求的不同，是分別由insert處理器、delete處理器、update處理器、create處理器，以及alter處理器這些小模塊來負責不同的DML和DDL的。
第六步：在各個模塊收到Query解析與分發模塊發過來的請求后，首先會通過訪問控制模塊檢查連接用戶是否有訪問控制目標表以及目標字段的權限，如果有，就會調用表管理模塊請求相應的表，並獲取對應的鎖。表管理模塊首先會看到該表是否已經存在於table cache中，如果已經打開則直接進行鎖相關的處理，如果沒有在cache中，則需要在打開表文件獲取鎖，然后將打開的表交給表變更管理模塊。
第七步：當表變更管理模塊“獲取”打開的表之后，就會根據該表的相關meta信息，判斷表的存儲引擎類型和其它相關信息。根據表的存儲引擎類型，提交請求給存儲引擎接口模塊，調用對應的存儲引擎實現模塊，進行相應處理。
不過，對於表變更管理模塊來說，可見的僅是存儲引擎接口模塊提供的一系列“標准”接口，底層存儲引擎實現模塊的具體實現，對於表變更管理模塊來說是透明的。他只需要調用對應的接口，並指定表類型，接口模塊會根據表類型調用正確存儲引擎來進行相應的處理。
第八步：當一條query或者是一個command處理完成（成功或者失敗）之后，控制權都會交還給連接線程模塊。如果處理成功，則將處理結果（可能是一個Result set，也可能是成功或者失敗的標識）通過連接線程反饋給客戶端。如果處理過程中發生錯誤，也會將相應的錯誤信息發送給客戶端，然后連接線程模塊會進行相應的清理工作，並繼續等待后面的請求，重復上面提到的過程，或者完成客戶端斷開連接的請求。
第九步：如果在上面的過程中，相關模塊使數據庫中的數據發生了變化，而且MySQL打來了bin-log功能，則對應的處理模塊還會調用日志處理模塊將相應的變更語句以更新事件的形式記錄到相關參數指定的二進制日志文件中。
在上面各個模塊的內容處理過程中，各自的核心運算處理功能部分都會高度依賴整個MySQL API模塊，比如內存管理，文件I/O，數字和字符串處理等。