文章大綱
一、資料庫簡介
二、Mysql資料庫簡介
三、Mysql安裝與服務啟動（Windows版本）
四、Mysql圖形化工具
五、Mysql儲存引擎精講
六、Mysql資料型別介紹
七、Mysql主要專業名稱介紹
八、Mysql常見sql語句
九、Mysql設計與語句優化
十、事務介紹
十一、Mysql資料庫備份與恢復
十二、Mysql分庫分表
十三、Mysql許可權管理
十四、Mysql資料庫之阿里雲
十五、資料下載
十六、參考文章
一、資料庫簡介
1. 資料庫是什麼
資料庫是資料管理的有效技術，是由一批資料構成的有序集合，這些資料被存放在結構化的資料表裡。資料表之間相互關聯，反映客觀事物間的本質聯絡。資料庫能有效地幫助一個組織或企業科學地管理各類資訊資源。
資料是資料庫中儲存的基本物件，是按一定順序排列組合的物理符號。資料有多種表現形式，可以是數字、文字、影像，甚至是音訊或視訊，它們都可以經過數字化後存入計算機。
資料庫是資料的集合，具有統一的結構形式並存放於統一的儲存介質內，是多種應用資料的整合，並可被各個應用程式所共享。
在日常生活中，人們可以直接用中文、英文等自然語言描述客觀事物。在計算機中，則要抽象出對這些事物感興趣的特徵，並組成一個記錄來描述。
2. 資料庫在開發中的作用
從資料庫系統應用角度來看，資料庫系統常見的執行與應用結構有：客戶端/伺服器結構、瀏覽器/伺服器結構。
在客戶端/伺服器（Client/Server，C/S）結構中，資料庫的使用者（如 DBA、程式設計者）通過命令列客戶端、圖形化介面管理工具或應用程式等連線到資料庫管理系統，可以通過資料庫管理系統查詢和處理儲存在底層資料庫中的各種資料。
資料庫使用者與命令列客戶端、圖形化介面管理工具或應用程式等直接互動，而不與資料庫管理系統直接聯絡。
在這種結構中，命令列客戶端、圖形化介面管理工具或應用程式等稱為“客戶端”或“前臺”，主要完成與資料庫使用者的互動任務；而資料庫管理系統則稱為“伺服器”或“後臺”，主要負責資料管理。這種結構經常被稱為“C/S”結構。
在客戶端/伺服器模式中，客戶端和伺服器可以同時工作在同一臺計算機上，這種工作方式稱為“單機方式”；也可以“網路方式”執行，即伺服器被安裝和部署在網路中某一臺或多臺主機上。
對於客戶端應用程式的開發，目前常用的語言工具主要有 Visual C++、Delphi、.NET 框架、Visual Basic、Python 等。
資料庫能有效儲存資料，讀取資料、查詢資料更是方便，其實那些管理軟體就是通過軟體的介面向內部的資料庫進行資料的增、刪、改、查操作。
3.常見資料庫比較
3.1 MySQL資料庫
定位
開源、多平臺、關係型資料庫
目前使用最廣泛、流行度最高的的開源資料庫。
功能
支援事務，符合關係型資料庫原理，符合ACID，支援多數SQL規範，以二維表方式組織資料，有外掛式儲存引擎，支援多種儲存引擎格式
部署
用編譯安裝的方式，或者二進位制包的方式，按照“安裝軟體-建立例項-庫表使用者初始化”，可以很快完成資料庫部署
使用
使用標準的SQL語句進行資料庫管理，簡單SQL語句的併發和效能較好，對檢視、儲存過程、函式、觸發器等支援的不是太好
監控
在命令列介面有一些常用的命令顯示狀態和效能，在圖形介面方面，有比較多的開源監控工具來監控和記錄資料庫的狀態，比如zabbix，nagios，cacti，lepus等
備份
邏輯備份 mysqldump/mysqldumper ，物理備份 用xtrabackup等工具進行備份；
高可用
MySQL高可用有多種方案，官方有基礎的master-slave主從複製，新版本的innodb cluster，第三方的有MHA等高可用方案；
擴充套件
MySQL水平拆分，可以通過水平拆分proxy中間進行邏輯對映和拆分，擴大MySQL資料庫的併發能力和吞吐量。
適用場景
預設的innodb儲存引擎，支援高併發，簡單的絕大部分OLTP場景；
Tokudb儲存引擎，使用高併發insert的場景；
Inforbright儲存引擎，可以進行列壓縮和OLAP統計查詢場景；
選擇注意
使用MySQL進行OLTP業務時，需要注意資料量級，如果資料量級過大，需要進行水平拆分；
如果有OLAP需求，可以結合其他架構綜合考慮。
3.2 SQL Server資料庫
定位
商業、Windows平臺、關係型資料庫
最早接觸、與微軟體系結合緊密的的商業資料庫，屬於“微軟技術體系”
功能
支援事務，符合關係型資料庫原理，符合ACID，支援多數SQL規範，以二維表方式組織資料
部署
在Windows平臺，用圖形介面進行軟體安裝；
使用
在Windows平臺，使用SQL Server Mangement Studio圖形介面進行安裝；
監控
一般通過Windows資源管理和SQL server圖形工具進行系統和資料庫效能顯示；
備份
通常用第三方備份恢復軟體進行備份恢復；
高可用
通過共享儲存和雙機熱備的方式，可以實現SQL Server資料庫的高可用；
擴充套件
SQL Server資料庫叢集採用共存儲存的方式，通過硬體垂直升級來對資料庫叢集進行擴充套件；
適用場景
大多數OLTP場景（與微軟體系配合）
選擇注意
SQL Server與微軟技術體系結合比較緊密，絕大多數工作，都是通過圖形介面完成，對於習慣使用命令列的DBA可能會有不習慣；
SQL server對雙引號，大小寫，元資訊的管理和處理方式，與其他資料庫很不相同，需要注意；
使用SQL Server滿足OLTP業務，會有比較好的效果，但對於大資料量的OLAP業務，最好還是選用專門的OLAP架構，不要在同一個SQL Server例項上混用OLTP和OLAP業務；
SQL server屬於商業軟體，需要注意版權和licence授權費用；
3.3 Oracle資料庫
定位
商業、多平臺、關係型資料庫
功能最強大、最複雜、市場佔比最高的商業資料庫
功能
支援事務，符合關係型資料庫原理，符合ACID，支援多數SQL規範，以二維表方式組織資料
部署
Oracle單例項資料庫部署相對容易，但Oracle RAC叢集環境，部署的步驟和依賴條件都比較多；
使用
通常使用命令列工具，進行各種資料庫的管理，通常也可以用shell指令碼和python指令碼提高Oracle資料庫管理效率；各種管理功能，都比較強大；
監控
Oracle官方有比較全面的監控工具，常用的第三方監控平臺，如zabbix,cacti,lepus等都有對Oracle資料庫的各項指標的完善監控；
備份
支援冷備份和熱備份，可以用 exp/imp , expdp/impdp等進行邏輯備份和恢復，可以使用強大的RMAN工具進行專業的物理熱備份和恢復；
高可用
Oracle資料庫的高可用架構，可以用第三方雙機熱備軟體，結合Oracle單例項實現；可以使用Oracle Dataguard，實現master和standby的備份；可以使用 Oracle RAC叢集實現例項級別的高可用和負載均衡，使用ASM實現儲存級別的高可用；
擴充套件
由於Oracle叢集採用共享儲存的方式，一般只能通過垂直硬體升級進行升級；
適用場景
絕大多數OLTP場景，部分OLAP
選擇注意
Oracle從架構到運維，可以說是最難的資料庫，學習和使用難度較高。
3.4 Hbase資料庫
定位
開源、Linux平臺、列儲存nosql資料庫
可用於海量資料儲存、與Hadoop生態圈結合、定位於“大”的列儲存nosql資料庫
功能
命令執行速度非常看，讀寫效能可達10萬/秒；資料結構是key-value類似字典的功能，可以鍵過期-快取，釋出訂閱-訊息系統，簡單的事物功能；
部署
相對其他資料庫，hbase的部署比較複雜，依賴Hadoop，zookeeper等元件，Hbase叢集包括一個mater節點，多個regionServer，zookeeper管理所有regionServer，需要依次部署Hadoop、zookeeper之後，再部署HBASE叢集；
使用
用redis-cli客戶端連線，一般用簡單的 set ,get,del 進行資料管理； 在單例項redis的基礎上，進行可以資料持久化，主從複製，高可用和分散式等功能；
監控
在命令列介面有一些常用的命令顯示狀態和效能，在圖形介面方面，有開源監控工具來監控和記錄資料庫的狀態，比如cachecloud；
備份
Hbase一般用作海量資料的倉庫，本身通過多層副本來保證資料安全性，不用進行專門的備份
高可用
HBASE叢集基於Hadoop，需要依次部署Hadoop單機模式、叢集模式、HA模式，通過Hadoop HA實現高可用；
擴充套件
HBASE以叢集形式，依次是單機模式，偽分佈模式，完全分佈模式，底層基於HDFS，zookeeper可以很好地進行擴充套件；
適用場景
兩大用途：
用於簡單資料寫入和海量、結構簡單資料查詢的業務場景；
用於成為其他資料庫備份和下沉的資料庫；
選擇注意
Hbase不適合的場景：對資料分析需求高，需要能夠用sql或者簡單的MapReduce實現分析需求的業務場景，不適合用Hbase；
單表資料量，不超過千萬時，使用Hbase，體現不出Hbase的優勢，而且會比較慢，不適合用Hbase。
通過對上面資料庫“七種”武器的描述，也可以看到目前常用資料庫的使用脈絡和選擇順序，對應一個業務，可以優先選擇最流行的開源資料庫——MySQL；如果出於穩定和商業版考慮，可以選擇Oracle資料庫，或者SQL Server資料庫（與Windows體系結合）；如果想用開源，有想要有足夠的功能來應對各種場景，可以使用 postgresql資料庫。這四種資料庫，都是關係型資料庫，可以很好地滿足大多數業務場景，解決通用性問題。
對於一些特殊性問題，尤其是想要在擴充套件性方面有比較高的要求，可以考慮nosql資料庫。Mongodb資料庫，介於關係型資料庫和非關係型資料庫之間，兼具兩者的特點，是非常流行的文件型nosql資料庫；redis定位於記憶體型鍵值nosql資料庫；hbase是海量檔案儲存的列式nosql資料庫。根據合適的業務場景，選擇適合的nosql資料庫，可以對某一類，或某幾類業務問題有很好的解決，可以作為關係型資料庫的一種補充。
換個角度，MySQL，Oracle，SQL Server，Postgresql，mongodb這五種資料庫，也是DB-Engines排行榜上最流行的排名前五的五種資料庫，從使用量和受歡迎程度，也可以看出這些資料庫使用的廣泛性。
4. 資料庫常見功能
二、Mysql資料庫簡介
1. MySQL的優勢
MySQL 使用的 SQL 語言是用於訪問資料庫的最常用的標準化語言。
由於 MySQL 資料庫體積小、速度快、總體擁有成本低、開放原始碼，其有著廣泛的應用，一般中小型網站的開發都選擇 MySQL 作為網站資料庫。由於其社群版的效能卓越，因此搭配 PHP 和 Apache 伺服器可組成良好的開發環境。
MySQL 資料庫管理系統具有以下系統特性：
（1） 使用 C 和 C++ 編寫，並使用多種編譯器進行測試，保證原始碼的可移植性。
（2）支援 AIX、FreeBSD、HP-UX、Linux、Mac OS、NovellNetware、OpenBSD、OS/2 Wrap、Solaris、Windows 等多種作業系統。
（3）為多種程式語言提供了 API。這些程式語言包括 C、C++、Python、Java、Perl、PHP、Eiffel、Ruby 和 Tcl 等。
（4）支援多執行緒，充分利用 CPU 資源。
（5）優化的 SQL 查詢演算法，有效地提高查詢速度。
（6）既能夠作為一個單獨的應用程式應用在客戶端伺服器網路環境中，也能夠作為一個庫而嵌入其他的軟體中。
（7）提供多語言支援，常見的編碼如中文的 GB 2312、BIG 5，日文的 Shift_JIS 等都可以用作資料表名和資料列名。
（8）提供 TCP/IP、ODBC 和 JDBC 等多種資料庫連線途徑。
（9）提供用於管理、檢查、優化資料庫操作的管理工具。
（10）支援大型的資料庫。可以處理擁有上千萬條記錄的大型資料庫。
（11）支援多種儲存引擎。
2. MySQL的版本以及版本號
針對不同的使用者，MySQL 分為兩個版本：
（1）MySQL Community Server（社群版）：該版本完全免費，但是官方不提供技術支援。
（2）MySQL Enterprise Server（企業版）：該版本能夠以很高的價效比為企業提供資料倉儲應用，支援 ACID 事物處理，提供完整的提交、回滾、崩潰恢復和行級鎖定功能，但是該版本需要付費使用，官方提供電話技術支援。
溫馨提示：MySQL Cluster 主要用於架設群伺服器，需要在社群服務或企業版的基礎上使用。
MySQL 的命名機制由 3 個數字和 1 個字尾組成，例如 mysql-5.7.20：
第 1 個數字“5”是主版本號，用於描述檔案的格式，所有版本 5 的發行版都有相同的資料夾格式。
第 2 個數字“7”是發行級別，主版本號和發行級別組合在一起便構成了發行序列號。
第 3 個數字“20”是在此發行系列的版本號，隨每次新發行的版本遞增。通常選擇已經發行的最新版本。
在 MySQL 開發過程中，同時存在多個釋出系列，每個釋出系列的成熟度處在不同階段。
MySQL 5.7 是最新開發的穩定（GA）釋出系列，是將執行新功能的系列，目前已經可以正常使用。
MySQL 5.6 是比較穩定的（GA）釋出系列，只針對漏洞修復重新發布，不增加會影響穩定性的新功能。
MySQL 5.1 是一個穩定的（產品質量）釋出系列，只針對嚴重漏洞修復和安全修復重新發布，不增加影響該系列穩定性的重要功能。
對於 MySQL 4.1 等低於 5.0 的老版本，官方將不再提供支援
3. MySQL 5.7的新特性
與 MySQL 5.6 相比，MySQL 5.7 具有以下幾個方面的新功能。
（1）隨機 root 密碼
MySQL 5.7 資料庫初始化完成後，會自動生成一個 root@localhost 使用者，root 使用者的密碼不為空，而是隨機產生一個密碼。
（2）自定義 test 資料庫
MySQL 5.7 預設安裝完成後沒有 test 資料庫。使用者可以自行建立 test 資料庫並對其進行許可權控制。
（3）預設 SSL 加密
MySQL 5.7 採用了更加簡單的 SSL 安全訪問機制，預設連線使用 SSL 的加密方式。
（4）密碼過期策略
MySQL 5.7 支援使用者設定密碼過期策略，要求使用者在一定時間過後必須修改密碼。
（5）使用者鎖
MySQL 5.7 為管理員提供了暫時禁用某個使用者的功能，使被鎖定的使用者無法訪問和使用資料庫。
（6）全面支援JSON
MySQL 5.7在伺服器端提供了一組便於操作 JSON 的函式。儲存的方法是將 JSON 編碼成 BLOB 後再由儲存引擎進行處理。這樣，MySQL 就同時擁有了關係型資料庫和非關係型資料庫的優點，並且可以提供完整的事務支援。
（7）支援兩類生成列（generated column）
生成列是通過資料庫中的其他列計算得到的一列。當為生成列建立索引時，可以便捷地加快查詢速度。MySQL 5.7 支援虛擬生成列和儲存生成列。虛擬生成列僅將資料儲存在表的後設資料中，作為預設的生成列型別；儲存生成列則是將資料永久儲存在磁碟上，需要更多的磁碟空間。
（8）引入系統庫（sys schema）
系統庫中包含一系列檢視、函式和儲存過程，通過多執行緒、多程式、組合事務提交和基於行的優化方式將複製功能提高 5 倍以上，使用者向外擴充其跨商品系統的工作負載時，得以大幅提升複製的效能和效率。
與 MySQL 5.6 相比，MySQL 5.7 具有以下幾個方面的新功能。
三、Mysql安裝與服務啟動（Windows版本）
1. 下載
使用者可以根據自身的作業系統型別，從 MySQL 官方下載頁面免費下載相應的伺服器安裝包。本書以 MySQL 5.7.20 為例介紹其在 Windows 10 作業系統下的安裝和配置過程。
使用者下載 Windows 圖形化安裝包的步驟如下。
步驟 1)：開啟 MySQL 官方網站（http://www.mysql.com），單擊 DOWNLOAD，進入 MySQL 產品的下載介面，如圖所示。
步驟 2)：在 MySQL 產品分類中選擇 Community 選單，在下載列表中選擇 MySQL Community Server，如圖所示。
步驟3)：在下載頁面中，作業系統選擇 Microsoft Windows，下載的安裝檔案為 mysql-installer-community-5.7.20.0.msi，如圖所示。
2. 安裝教程
Windows 平臺下提供兩種安裝 MySQL 的方式：
- MySQL 二進位制分發版（.msi 安裝檔案）。
- 免安裝版（.zip 壓縮檔案）。
使用者使用圖形化安裝包安裝 MySQL 的步驟如下：
步驟 1)：雙擊下載的 MySQL 安裝檔案，進入 MySQL 安裝介面，首先進入“License Agreement（使用者許可證協議）”視窗，選中“I accept the license terms（我接受系統協議）”核取方塊，單擊“Next（下一步）”按鈕，如圖所示。
步驟 2)：進入“Choosing a Setup Type（安裝型別選擇）”視窗，根據右側的安裝型別描述檔案選擇適合自己的安裝型別，這裡選擇預設的安裝型別，如圖所示。
注意：Developer Default：預設安裝型別；Server only：僅作為服務；Client only：僅作為客戶端；Full：完全安裝；Custom：自定義安裝型別。
步驟 3)：根據所選擇的安裝型別安裝 Windows 系統框架（framework），單擊 Execute 按鈕，安裝程式會自動完成框架的安裝，如圖所示。
當彈出安裝程式視窗時，勾選“我同意許可條款和條件”核取方塊，然後單擊“安裝”按鈕，如圖所示。
彈出“設定成功”的介面，表示該框架已經安裝完成，單擊“關閉”按鈕即可。所有的框架安裝均可參考本操作，如圖所示。
步驟 4)：所需框架均安裝成功後，單擊 “Next（下一步）”按鈕，如圖所示。
步驟 5)：進入安裝確認視窗，單擊 “Execute（執行）”按鈕，開始 MySQL 各個元件的安裝，如圖所示。
步驟 6)：開始安裝 MySQL 檔案，安裝完成後在 “Status（狀態）”列表下顯示 “Complete（安裝成功）”，如圖所示。
3. 判斷是否安裝成功
3.1 啟動與關閉服務
net start mysql為啟動服務，net stop mysql為關閉命令
3.2 登入資料庫
cmd進入資料庫的bin資料夾中
輸入mysql -u root -p命令，再輸入登入密碼，出現以下結果代表登入成功
3.3 檢視資料庫名稱
登入完成後，輸入show databases
四、Mysql圖形化工具
（1）Navicat（重點推薦）
Navicat是MySQL和MariaDB資料庫管理與開發理想的解決方案。它可同時在一個應用程式上連線MySQL和MariaDB資料庫。這種相容前端為資料庫提供了一個直觀而強大的圖形介面管理、開發和維護功能，為初級MySQL和MariaDB開發人員和專業開發人員都提供了一組全面的開發工具。
（2）Induction
Induction是一款用於理解資料關係的開源管理工具，它可用來探索行/列，執行查詢和資料視覺化等方面。該工具支援多種資料庫，包括PostgreSQL，MySQL，SQLite，Redis以及MongoDB。此外，Induction還可以通過編寫新增其他新的介面卡。
（3）SqlWave
SQLWave是一種簡單、快速且易用的MySQL客戶端。使用者可通過該工具輕鬆地連線到遠端主機。SqlWave支援所有MySQL的最新版本，包括它用來管理資料庫結構的所有最新功能，如工作表、檢視、儲存過程、函式、事件、外來鍵和觸發器等。
五、Mysql儲存引擎精講
1. 儲存引擎分類
資料庫儲存引擎是資料庫底層軟體元件，資料庫管理系統使用資料引擎進行建立、查詢、更新和刪除資料操作。不同的儲存引擎提供不同的儲存機制、索引技巧、鎖定水平等功能，使用不同的儲存引擎還可以獲得特定的功能。現在許多資料庫管理系統都支援多種不同的儲存引擎。MySQL 的核心就是儲存引擎。
提示：InnoDB 事務型資料庫的首選引擎，支援事務安全表（ACID），支援行鎖定和外來鍵。MySQL 5.5.5 之後，InnoDB 作為預設儲存引擎。MyISAM 是基於 ISAM 的儲存引擎，並對其進行擴充套件，是在 Web、資料倉儲和其他應用環境下最常使用的儲存引擎之一。MyISAM 擁有較高的插入、查詢速度，但不支援事務。MEMORY 儲存引擎將表中的資料儲存到記憶體中，為查詢和引用其他資料提供快速訪問。
2. MySQL 5.7 支援的儲存引擎
MySQL 支援多種型別的資料庫引擎，可分別根據各個引擎的功能和特性為不同的資料庫處理任務提供各自不同的適應性和靈活性。在 MySQL 中，可以利用 SHOW ENGINES 語句來顯示可用的資料庫引擎和預設引擎。
MySQL 提供了多個不同的儲存引擎，包括處理事務安全表的引擎和處理非事務安全表的引擎。在 MySQL 中，不需要在整個伺服器中使用同一種儲存引擎，針對具體的要求，可以對每一個表使用不同的儲存引擎。
MySQL 5.7 支援的儲存引擎有 InnoDB、MyISAM、Memory、Merge、Archive、Federated、CSV、BLACKHOLE 等。可以使用SHOW ENGINES語句檢視系統所支援的引擎型別，結果如圖所示。
3. MySQL 預設儲存引擎
InnoDB 是系統的預設引擎，支援可靠的事務處理。
使用下面的語句可以修改資料庫臨時的預設儲存引擎
SET default_storage_engine=< 儲存引擎名 >
例如，將 MySQL 資料庫的臨時預設儲存引擎修改為 MyISAM，輸入的 SQL 語句和執行結果如圖所示。
此時，可以發現 MySQL 的預設儲存引擎已經變成了 MyISAM。但是當再次重啟客戶端時，預設儲存引擎仍然是 InnoDB。
六、Mysql資料型別介紹
1. 基本介紹
在 MySQL 中常見的資料型別如下：
- 整數型別
包括 TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，浮點數型別 FLOAT 和 DOUBLE，定點數型別 DECIMAL。 - 日期/時間型別
包括 YEAR、TIME、DATE、DATETIME 和 TIMESTAMP。 - 字串型別
包括 CHAR、VARCHAR、BINARY、VARBINARY、BLOB、TEXT、ENUM 和 SET 等。 - 二進位制型別
包括 BIT、BINARY、VARBINARY、TINYBLOB、BLOB、MEDIUMBLOB 和 LONGBLOB。
2. 整數型別
MySQL 提供了多種數值型資料型別，不同的資料型別提供不同的取值範圍，可以儲存的值範圍越大，所需的儲存空間也會越大。
MySQL 主要提供的整數型別有 TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，其屬性欄位可以新增 AUTO_INCREMENT 自增約束條件。下表中列出了 MySQL 中的數值型別。
從上表中可以看到，不同型別的整數儲存所需的位元組數不相同，佔用位元組數最小的是 TINYINT 型別，佔用位元組最大的是 BIGINT 型別，佔用的位元組越多的型別所能表示的數值範圍越大。
根據佔用位元組數可以求出每一種資料型別的取值範圍。例如，TINYINT 需要 1 個位元組（8bit）來儲存，那麼 TINYINT 無符號數的最大值為 28-1，即 255；TINYINT 有符號數的最大值為 27-1，即 127。其他型別的整數的取值範圍計算方法相同，如下表所示。
提示：顯示寬度和資料型別的取值範圍是無關的。顯示寬度只是指明 MySQL 最大可能顯示的數字個數，數值的位數小於指定的寬度時會由空格填充。如果插入了大於顯示寬度的值，只要該值不超過該型別整數的取值範圍，數值依然可以插入，而且能夠顯示出來。例如，year 欄位插入 19999，當使用 SELECT 查詢該列值的時候，MySQL 顯示的將是完整的帶有 5 位數字的 19999，而不是 4 位數字的值。
3. 小數型別
MySQL 中使用浮點數和定點數來表示小數。
浮點型別有兩種，分別是單精度浮點數（FLOAT）和雙精度浮點數（DOUBLE）；定點型別只有一種，就是 DECIMAL。
浮點型別和定點型別都可以用(M, D)來表示，其中M稱為精度，表示總共的位數；D稱為標度，表示小數的位數。
浮點數型別的取值範圍為 M（1～255）和 D（1～30，且不能大於 M-2），分別表示顯示寬度和小數位數。M 和 D 在 FLOAT 和DOUBLE 中是可選的，FLOAT 和 DOUBLE 型別將被儲存為硬體所支援的最大精度。DECIMAL 的預設 D 值為 0、M 值為 10。
下表中列出了 MySQL 中的小數型別和儲存需求。
FLOAT 型別的取值範圍如下：
有符號的取值範圍：-3.402823466E+38～-1.175494351E-38。
無符號的取值範圍：0 和 -1.175494351E-38～-3.402823466E+38。
DOUBLE 型別的取值範圍如下：
有符號的取值範圍：-1.7976931348623157E+308～-2.2250738585072014E-308。
無符號的取值範圍：0 和 -2.2250738585072014E-308～-1.7976931348623157E+308。
提示：不論是定點還是浮點型別，如果使用者指定的精度超出精度範圍，則會四捨五入進行處理。
FLOAT 和 DOUBLE 在不指定精度時，預設會按照實際的精度（由計算機硬體和作業系統決定），DECIMAL 如果不指定精度，預設為（10，0）。
浮點數相對於定點數的優點是在長度一定的情況下，浮點數能夠表示更大的範圍；缺點是會引起精度問題。
最後再強調一下：在 MySQL 中，定點數以字串形式儲存，在對精度要求比較高的時候（如貨幣、科學資料），使用 DECIMAL 的型別比較好，另外兩個浮點數進行減法和比較運算時也容易出問題，所以在使用浮點數時需要注意，並儘量避免做浮點數比較。
4. 日期和時間型別
MySQL 中有多處表示日期的資料型別：YEAR、TIME、DATE、DTAETIME、TIMESTAMP。當只記錄年資訊的時候，可以只使用 YEAR 型別。
每一個型別都有合法的取值範圍，當指定確定不合法的值時，系統將“零”值插入資料庫中。
下表中列出了 MySQL 中的日期與時間型別。
YEAR 型別
YEAR 型別是一個單位元組型別，用於表示年，在儲存時只需要 1 個位元組。可以使用各種格式指定 YEAR，如下所示：
以 4 位字串或者 4 位數字格式表示的 YEAR，範圍為 '1901'～'2155'。輸入格式為 'YYYY' 或者 YYYY，例如，輸入 '2010' 或 2010，插入資料庫的值均為 2010。
以 2 位字串格式表示的 YEAR，範圍為 '00' 到 '99'。'00'～'69' 和 '70'～'99' 範圍的值分別被轉換為 2000～2069 和 1970～1999 範圍的 YEAR 值。'0' 與 '00' 的作用相同。插入超過取值範圍的值將被轉換為 2000。
以 2 位數字表示的 YEAR，範圍為 1～99。1～99 和 70～99 範圍的值分別被轉換為 2001～2069 和 1970～1999 範圍的 YEAR 值。注意，在這裡 0 值將被轉換為 0000，而不是 2000。
提示：兩位整數範圍與兩位字串範圍稍有不同。例如，插入 3000 年，讀者可能會使用數字格式的 0 表示 YEAR，實際上，插入資料庫的值為 0000，而不是所希望的 3000。只有使用字串格式的 '0' 或 '00'，才可以被正確解釋為 3000，非法 YEAR值將被轉換為 0000。
TIME 型別
TIME 型別用於只需要時間資訊的值，在儲存時需要 3 個位元組。格式為 HH:MM:SS。HH 表示小時，MM 表示分鐘，SS 表示秒。
TIME 型別的取值範圍為 -838：59：59～838：59：59，小時部分如此大的原因是 TIME 型別不僅可以用於表示一天的時間（必須小於 24 小時），還可能是某個事件過去的時間或兩個事件之間的時間間隔（可大於 24 小時，或者甚至為負）。
可以使用各種格式指定 TIME 值，如下所示。
'D HH：MM：SS' 格式的字串。還可以使用這些“非嚴格”的語法：'HH：MM：SS'、'HH：MM'、'D HH' 或 'SS'。這裡的 D 表示日，可以取 0～34 之間的值。在插入資料庫時，D 被轉換為小時儲存，格式為 “D*24+HH”。
'HHMMSS' 格式、沒有間隔符的字串或者 HHMMSS 格式的數值，假定是有意義的時間。例如，'101112' 被理解為'10：11：12'，但是 '106112' 是不合法的（它有一個沒有意義的分鐘部分），在儲存時將變為 00：00：00。
提示：為 TIME 列分配簡寫值時應注意：如果沒有冒號，MySQL 解釋值時，假定最右邊的兩位表示秒。（MySQL 解釋 TIME 值為過去的時間而不是當前的時間）。例如，讀者可能認為 '1112' 和 1112 表示 11：12：00（即 11 點過 12 分鐘），但MySQL 將它們解釋為 00：11：12（即 11 分 12 秒）。同樣 '12' 和 12 被解釋為00：00：12。相反，TIME 值中如果使用冒號則肯定被看作當天的時間，也就是說，'11：12' 表示 11：12：00，而不是 00：11：12。
DATE 型別
DATE 型別用於僅需要日期值時，沒有時間部分，在儲存時需要 3 個位元組。日期格式為 'YYYY-MM-DD'，其中 YYYY 表示年，MM 表示月，DD 表示日。
在給 DATE 型別的欄位賦值時，可以使用字串型別或者數字型別的資料插入，只要符合 DATE 的日期格式即可。如下所示：
以 'YYYY-MM-DD' 或者 'YYYYMMDD' 字元中格式表示的日期，取值範圍為 '1000-01-01'～'9999-12-3'。例如，輸入 '2015-12-31' 或者 '20151231'，插入資料庫的日期為2015-12-31。
以 'YY-MM-DD' 或者 'YYMMDD' 字串格式表示日期，在這裡YY表示兩位的年值。MySQL 解釋兩位年值的規則：'00～69' 範圍的年值轉換為 '20002069'，'7099' 範圍的年值轉換為 '1970～1999'。例如，輸入 '15-12-31'，插入資料庫的日期為 2015-12-31；輸入 '991231'，插入資料庫的日期為 1999-12-31。
以 YYMMDD 數字格式表示的日期，與前面相似，00~69 範圍的年值轉換為 2000～2069，80～99 範圍的年值轉換為 1980～1999。例如，輸入 151231，插入資料庫的日期為 2015-12-31，輸入 991231，插入資料庫的日期為 1999-12-31。
使用 CURRENT_DATE 或者 NOW()，插入當前系統日期。
提示：MySQL 允許“不嚴格”語法：任何標點符號都可以用作日期部分之間的間隔符。例如，'98-11-31'、'98.11.31'、'98/11/31'和'98@11@31' 是等價的，這些值也可以正確地插入資料庫。
DATETIME 型別
DATETIME 型別用於需要同時包含日期和時間資訊的值，在儲存時需要 8 個位元組。日期格式為 'YYYY-MM-DD HH：MM：SS'，其中 YYYY 表示年，MM 表示月，DD 表示日，HH 表示小時，MM 表示分鐘，SS 表示秒。
在給 DATETIME 型別的欄位賦值時，可以使用字串型別或者數字型別的資料插入，只要符合 DATETIME 的日期格式即可，如下所示。
以 'YYYY-MM-DD HH：MM：SS' 或者 'YYYYMMDDHHMMSS' 字串格式表示的日期，取值範圍為 '1000-01-01 00：00：00'～'9999-12-3 23：59：59'。例如，輸入 '2014-12-31 05：05：05' 或者 '20141231050505’，插入資料庫的 DATETIME 值都為 2014-12-31 05：05：05。
以 'YY-MM-DD HH：MM：SS' 或者 'YYMMDDHHMMSS' 字串格式表示的日期，在這裡 YY 表示兩位的年值。與前面相同，'00～79' 範圍的年值轉換為 '2000～2079'，'80～99' 範圍的年值轉換為 '1980～1999'。例如，輸入 '14-12-31 05：05：05'，插入資料庫的 DATETIME 為 2014-12-31 05：05：05；輸入 141231050505，插入資料庫的 DATETIME 為 2014-12-31 05：05：05。
以 YYYYMMDDHHMMSS 或者 YYMMDDHHMMSS 數字格式表示的日期和時間。例如，輸入 20141231050505，插入資料庫的 DATETIME 為 2014-12-31 05：05：05；輸入 140505050505，插入資料庫的 DATETIME 為 2014-12-31 05：05：05。
提示：MySQL 允許“不嚴格”語法：任何標點符號都可用作日期部分或時間部分之間的間隔符。例如，'98-12-31 11：30：45'、'98.12.31 11+30+35'、'98/12/31 113045' 和 '98@12@31 113045' 是等價的，這些值都可以正確地插入資料庫。
TIMESTAMP 型別
TIMESTAMP 的顯示格式與 DATETIME 相同，顯示寬度固定在 19 個字元，日期格式為 YYYY-MM-DD HH：MM：SS，在儲存時需要 4 個位元組。但是 TIMESTAMP 列的取值範圍小於 DATETIME 的取值範圍，為 '1970-01-01 00：00：01'UTC～'2038-01-19 03：14：07'UTC。在插入資料時，要保證在合法的取值範圍內。
提示：協調世界時（英：Coordinated Universal Time，法：Temps Universel Coordonné）又稱為世界統一時間、世界標準時間、國際協調時間。英文（CUT）和法文（TUC）的縮寫不同，作為妥協，簡稱 UTC。
TIMESTAMP 與 DATETIME 除了儲存位元組和支援的範圍不同外，還有一個最大的區別是：
DATETIME 在儲存日期資料時，按實際輸入的格式儲存，即輸入什麼就儲存什麼，與時區無關；
而 TIMESTAMP 值的儲存是以 UTC（世界標準時間）格式儲存的，儲存時對當前時區進行轉換，檢索時再轉換回當前時區。即查詢時，根據當前時區的不同，顯示的時間值是不同的。
提示：如果為一個 DATETIME 或 TIMESTAMP 物件分配一個 DATE 值，結果值的時間部分被設定為 '00：00：00'，因此 DATE 值未包含時間資訊。如果為一個 DATE 物件分配一個 DATETIME 或 TIMESTAMP 值，結果值的時間部分被刪除，因此DATE 值未包含時間資訊。
5. 字串型別
字串型別用來儲存字串資料，還可以儲存圖片和聲音的二進位制資料。字串可以區分或者不區分大小寫的串比較，還可以進行正規表示式的匹配查詢。
MySQL 中的字串型別有 CHAR、VARCHAR、TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT、ENUM、SET 等。
下表中列出了 MySQL 中的字串資料型別，括號中的M表示可以為其指定長度。
VARCHAR 和 TEXT 型別是變長型別，其儲存需求取決於列值的實際長度（在前面的表格中用 L 表示），而不是取決於型別的最大可能尺寸。
例如，一個 VARCHAR(10) 列能儲存一個最大長度為 10 個字元的字串，實際的儲存需要字串的長度 L 加上一個位元組以記錄字串的長度。對於字元 “abcd”，L 是 4，而儲存要求 5 個位元組。
CHAR 和 VARCHAR 型別
CHAR(M) 為固定長度字串，在定義時指定字串列長。當儲存時，在右側填充空格以達到指定的長度。M 表示列的長度，範圍是 0～255 個字元。
例如，CHAR(4) 定義了一個固定長度的字串列，包含的字元個數最大為 4。當檢索到 CHAR 值時，尾部的空格將被刪除。
VARCHAR(M) 是長度可變的字串，M 表示最大列的長度，M 的範圍是 0～65535。VARCHAR 的最大實際長度由最長的行的大小和使用的字符集確定，而實際佔用的空間為字串的實際長度加 1。
例如，VARCHAR(50) 定義了一個最大長度為 50 的字串，如果插入的字串只有 10 個字元，則實際儲存的字串為 10 個字元和一個字串結束字元。VARCHAR 在值儲存和檢索時尾部的空格仍保留。
【例項】下面將不同的字串儲存到 CHAR(4) 和 VARCHAR(4) 列，說明 CHAR 和 VARCHAR 之間的差別，如下表所示。
插入值 CHAR(4) 儲存需求 VARCHAR(4) 儲存需求
' ' ' ' 4位元組 '' 1位元組
'ab' 'ab ' 4位元組 'ab' 3位元組
'abc' 'abc ' 4位元組 'abc' 4位元組
'abcd' 'abcd' 4位元組 'abcd' 5位元組
'abcdef' 'abcd' 4位元組 'abcd' 5位元組
對比結果可以看到，CHAR(4) 定義了固定長度為 4 的列，無論存入的資料長度為多少，所佔用的空間均為 4 個位元組。VARCHAR(4) 定義的列所佔的位元組數為實際長度加 1。
TEXT 型別
TEXT 列儲存非二進位制字串，如文章內容、評論等。當儲存或查詢 TEXT 列的值時，不刪除尾部空格。
TEXT 型別分為 4 種：TINYTEXT、TEXT、MEDIUMTEXT 和 LONGTEXT。不同的 TEXT 型別的儲存空間和資料長度不同。
TINYTEXT 表示長度為 255（28-1）字元的 TEXT 列。
TEXT 表示長度為 65535（216-1）字元的 TEXT 列。
MEDIUMTEXT 表示長度為 16777215（224-1）字元的 TEXT 列。
LONGTEXT 表示長度為 4294967295 或 4GB（232-1）字元的 TEXT 列。
ENUM 型別
ENUM 是一個字串物件，值為表建立時列規定中列舉的一列值。其語法格式如下：
<欄位名> ENUM( '值1', '值1', …, '值n' )
欄位名指將要定義的欄位，值 n 指列舉列表中第 n 個值。
ENUM 型別的欄位在取值時，能在指定的列舉列表中獲取，而且一次只能取一個。如果建立的成員中有空格，尾部的空格將自動被刪除。
ENUM 值在內部用整數表示，每個列舉值均有一個索引值；列表值所允許的成員值從 1 開始編號，MySQL 儲存的就是這個索引編號，列舉最多可以有 65535 個元素。
例如，定義 ENUM 型別的列（'first'，'second'，'third'），該列可以取的值和每個值的索引如下表所示。
值 索引
NULL NULL
'' 0
’first 1
second 2
third 3
ENUM 值依照列索引順序排列，並且空字串排在非空字串前，NULL 值排在其他所有列舉值前。
提示：ENUM 列總有一個預設值。如果將 ENUM 列宣告為 NULL，NULL 值則為該列的一個有效值，並且預設值為 NULL。如果 ENUM 列被宣告為 NOT NULL，其預設值為允許的值列表的第 1 個元素。
SET 型別
SET 是一個字串的物件，可以有零或多個值，SET 列最多可以有 64 個成員，值為表建立時規定的一列值。指定包括多個 SET 成員的 SET 列值時，各成員之間用逗號,隔開，語法格式如下：
SET( '值1', '值2', …, '值n' )
與 ENUM 型別相同，SET 值在內部用整數表示，列表中每個值都有一個索引編號。當建立表時，SET 成員值的尾部空格將自動刪除。
但與 ENUM 型別不同的是，ENUM 型別的欄位只能從定義的列值中選擇一個值插入，而 SET 型別的列可從定義的列值中選擇多個字元的聯合。
提示：如果插入 SET 欄位中的列值有重複，則 MySQL 自動刪除重複的值；插入 SET 欄位的值的順序並不重要，MySQL 會在存入資料庫時，按照定義的順序顯示；如果插入了不正確的值，預設情況下，MySQL 將忽視這些值，給出警告。
七、Mysql主要專業名稱介紹
1. 主鍵
1.1 什麼是主鍵
“主鍵（PRIMARY KEY）”的完整稱呼是“主鍵約束”。MySQL 主鍵約束是一個列或者列的組合，其值能唯一地標識表中的每一行。這樣的一列或多列稱為表的主鍵，通過它可以強制表的實體完整性。
1.2 選取設定主鍵約束的欄位
主鍵約束即在表中定義一個主鍵來唯一確定表中每一行資料的識別符號。主鍵可以是表中的某一列或者多列的組合，其中由多列組合的主鍵稱為複合主鍵。主鍵應該遵守下面的規則：
- 每個表只能定義一個主鍵。
- 主鍵值必須唯一標識表中的每一行，且不能為 NULL，即表中不可能存在兩行資料有相同的主鍵值。這是唯一性原則。
- 一個列名只能在複合主鍵列表中出現一次。
- 複合主鍵不能包含不必要的多餘列。當把複合主鍵的某一列刪除後，如果剩下的列構成的主鍵仍然滿足唯一性原則，那麼這個複合主鍵是不正確的。這是最小化原則。
1.3 建立主鍵
語法規則：<欄位名> <資料型別> PRIMARY KEY [預設值]
2. 外來鍵約束
2.1 什麼是外來鍵約束
MySQL 外來鍵約束（FOREIGN KEY）用來在兩個表的資料之間建立連結，它可以是一列或者多列。一個表可以有一個或多個外來鍵。
外來鍵對應的是參照完整性，一個表的外來鍵可以為空值，若不為空值，則每一個外來鍵的值必須等於另一個表中主鍵的某個值。
外來鍵是表的一個欄位，不是本表的主鍵，但對應另一個表的主鍵。定義外來鍵後，不允許刪除另一個表中具有關聯關係的行。
外來鍵的主要作用是保持資料的一致性、完整性。例如，部門表 tb_dept 的主鍵是 id，在員工表 tb_emp5 中有一個鍵 deptId 與這個 id 關聯。
- 主表（父表）：對於兩個具有關聯關係的表而言，相關聯欄位中主鍵所在的表就是主表。
- 從表（子表）：對於兩個具有關聯關係的表而言，相關聯欄位中外來鍵所在的表就是從表。
2.2 選取設定 MySQL 外來鍵約束的欄位
定義一個外來鍵時，需要遵守下列規則：
（1）父表必須已經存在於資料庫中，或者是當前正在建立的表。如果是後一種情況，則父表與子表是同一個表，這樣的表稱為自參照表，這種結構稱為自參照完整性。
（2）必須為父表定義主鍵。
（3）主鍵不能包含空值，但允許在外來鍵中出現空值。也就是說，只要外來鍵的每個非空值出現在指定的主鍵中，這個外來鍵的內容就是正確的。
（4）在父表的表名後面指定列名或列名的組合。這個列或列的組合必須是父表的主鍵或候選鍵。
（5）外來鍵中列的數目必須和父表的主鍵中列的數目相同。
（6）外來鍵中列的資料型別必須和父表主鍵中對應列的資料型別相同。
2.3 在建立表時設定外來鍵約束
在資料表中建立外來鍵使用 FOREIGN KEY 關鍵字，具體的語法規則如下：
[CONSTRAINT <外來鍵名>] FOREIGN KEY 欄位名 [，欄位名2，…]
REFERENCES <主表名> 主鍵列1 [，主鍵列2，…]
其中：外來鍵名為定義的外來鍵約束的名稱，一個表中不能有相同名稱的外來鍵；欄位名錶示子表需要新增外健約束的欄位列；主表名即被子表外來鍵所依賴的表的名稱；主鍵列表示主表中定義的主鍵列或者列組合。
3. 唯一約束
MySQL唯一約束（Unique Key）要求該列唯一，允許為空，但只能出現一個空值。唯一約束可以確保一列或者幾列不出現重複值。
4. 預設值
4.1 什麼是預設值
“預設值（Default）”的完整稱呼是“預設值約束（Default Constraint）”。MySQL 預設值約束用來指定某列的預設值。
例如女性同學較多，性別就可以預設為“女”。如果插入一條新的記錄時沒有為這個欄位賦值，那麼系統會自動為這個欄位賦值為“女”。
4.2 在建立表時設定預設值約束
建立表時可以使用 DEFAULT 關鍵字設定預設值約束，具體的語法規則如下：
<欄位名> <資料型別> DEFAULT <預設值>;
5. 非空約束
5.1 什麼是非空約束
MySQL 非空約束（NOT NULL）可以通過 CREATE TABLE 或 ALTER TABLE 語句實現。在表中某個列的定義後加上關鍵字 NOT NULL 作為限定詞，來約束該列的取值不能為空。
非空約束（Not Null Constraint）指欄位的值不能為空。對於使用了非空約束的欄位，如果使用者在新增資料時沒有指定值，資料庫系統就會報錯。
5.2 在建立表時設定非空約束
建立表時可以使用 NOT NULL 關鍵字設定非空約束，具體的語法規則如下：
<欄位名> <資料型別> NOT NULL;
6. 觸發器
觸發器（TRIGGER）是由事件來觸發某個操作。這些事件包括INSERT語句、UPDATE語句和DELETE語句。當資料庫系統執行這些事件時，會啟用促發其執行相應的操作。
7. DML
DML（data manipulation language）資料操縱語言：
就是我們最經常用到的 SELECT、UPDATE、INSERT、DELETE。 主要用來對資料庫的資料進行一些操作。
SELECT 列名稱 FROM 表名稱
UPDATE 表名稱 SET 列名稱 = 新值 WHERE 列名稱 = 某值
INSERT INTO table_name (列1, 列2,...) VALUES (值1, 值2,....)
DELETE FROM 表名稱 WHERE 列名稱 = 值
8. DDL
DDL（data definition language）資料庫定義語言：其實就是我們在建立表的時候用到的一些sql，比如說：CREATE、ALTER、DROP等。DDL主要是用在定義或改變表的結構，資料型別，表之間的連結和約束等初始化工作上
CREATE TABLE 表名稱
(
列名稱1 資料型別,
列名稱2 資料型別,
列名稱3 資料型別,
....
)
ALTER TABLE table_name
ALTER COLUMN column_name datatype
DROP TABLE 表名稱
DROP DATABASE 資料庫名稱
9. DCL
DCL（Data Control Language）資料庫控制語言：是用來設定或更改資料庫使用者或角色許可權的語句，包括（grant,deny,revoke等）語句。這個比較少用到。在公司呢一般情況下我們用到的是DDL、DML這兩種。
八、Mysql常見sql語句
1. select語句
請在資料下載中進行學習
2. 函式
請在資料下載中進行學習
3. 多表查詢
請在資料下載中進行學習
4. 表的內連與外連‘
請在資料下載中進行學習’
九、Mysql設計與語句優化
1. 資料庫建立優化
請在資料下載中進行學習
2. sql語句優化
請在資料下載中進行學習
十、事務介紹
1. 事務概述
事務是訪問並更新資料庫中各種資料項的一個程式執行單元。在事務中的操作，要麼都執行修改，要麼都不執行，這就是事務的目的，也是事務模型區別於檔案系統的重要特徵之一。
嚴格上來說，事務必須同時滿足4個特性，即通常所說事務的ACID特性。雖然理論上定義了嚴格的事務要求，但是資料庫廠商出於各種目的並沒有嚴格滿足事務的ACID標準。例如，對於MYSQL的NDB Cluster引擎，雖然支援事務，但是不滿足D的要求，即永續性的要求。對於Oracle資料庫來說，其預設的事務隔離級別為READ COMMITTED，不滿足I的要求，即隔離性的要求。對於InnoDB儲存引擎而言，預設的事務隔離級別是READ REPRATABLE，完全遵循和滿足事務的ACID特性。
A（atomicity），原子性。原子性指整個資料庫事務是不可分割的工作單位。只有使事務中所有的資料庫操作都執行成功，整個事務的執行才算成功。事務中任何一個SQL語句執行失敗，那麼已經執行成功的SQL語句也必須撤銷，資料庫狀態應該退回到事務前的狀態。
C（consistency），一致性。一致性是指事務將資料庫從一種狀態轉變為另一種狀態。在事務的開始之前和事務結束以後，資料庫的完整性約束沒有被破壞。
I（isolation），隔離性。隔離性還有其他的稱呼，如併發控制、可序列化、鎖。事務的隔離性要求每個讀寫事務的物件與其他事務的操作物件能互相分離，即該事務提交前對其他事務都不可見，這通常使用鎖來實現。資料庫系統中提供了一種粒度鎖的策略，允許事務僅鎖住一個實體物件的子集，以此來提高事務之間的併發度。（如果是全表鎖，事務之間基本就無法實現併發，但是如果只鎖住表中處理的行，可以提高事務的併發度）
D（durability），永續性。事務一旦提交，其結果就是永久性的。即使發生當機等故障，資料庫也能將資料恢復。需要注意的是，永續性只能從事務本身的角度來保證結果的永久性，如事務提交後，所有的變化都是永久的，即使當資料庫由於崩潰而需要恢復時，也能保證恢復後提交的資料都不會丟失。
事務的（ACID）特性是由關聯式資料庫管理系統（RDBMS，資料庫系統）來實現的。資料庫管理系統採用日誌來保證事務的原子性、一致性和永續性。日誌記錄了事務對資料庫所做的更新，如果某個事務在執行過程中發生錯誤，就可以根據日誌，撤銷事務對資料庫已做的更新，使資料庫退回到執行事務前的初始狀態。資料庫管理系統採用鎖機制來實現事務的隔離性。當多個事務同時更新資料庫中相同的資料時，只允許持有鎖的事務能更新該資料，其他事務必須等待，直到前一個事務釋放了鎖，其他事務才有機會更新該資料。
2. 事務分類
（1）扁平事務，最簡單，使用最頻繁的事務。在扁平事務中，所有的操作都處於一個層次，其有BEGIN WORK開始，有COMMIT WORK或ROLLBACK WORK結束。處於之間的操作是原子的，要麼全部執行，要麼全部回滾。
（2）帶有儲存點的扁平事務，除了扁平事務支援的操作外，允許在事務執行過程中回滾到同一事務中較早的一個狀態，這是因為可能有些事務在執行過程中出現的錯誤並不會對有的操作都無效，放棄整個事務不合乎要求，開銷也太大。儲存點用來通知系統應該記住事務當前的狀態，以便以後發生錯誤時，事務能回到該狀態。
（3）鏈事務可視為儲存點模式的一個變種。
（4）巢狀事務是一個層次結構框架。
（5）分散式事務
3. 事務控制語句
在MYSQL命令列的預設設定下，事務都是自動提交的，即執行SQL語句後就會馬上執行COMMIT操作。因此要顯示的開啟一個事務必須使用命令BEGIN和START TRANSACTION，或者執行命令SET AUTOCOMMIT = 0，以禁用當前會話的自動提交。事務控制語句如下：
START TRANSACTION | BEGIN：顯示的開啟一個事務。在儲存過程中，MYSQL資料庫的分析器會自動將BEGIN識別為BEGIN...END，因此在儲存過程中只能使用START TRANSACTION語句來開啟一個事務。
COMMIT：要想使用這個語句的最簡形式，只需發出COMMIT。COMMIT會提交事務，並使已對資料庫進行的所有修改成為永久性的。COMMIT和COMMIT WORK語句基本上是一致的，都是用來提交事務。不同的是COMMIT WORK用來控制事務結束後的行為是CHAIN還是RELEASE的。如果是CHAIN方式，那麼事務就變成了鏈事務。使用者可以通過引數completion_type來進行控制，預設該引數是0，表示沒有任何操作。在這種設定下，COMMIT和COMMIT WORK是完全等價的。當引數值為1時，COMMIT WORK等價於COMMIT AND CHAIN，表示馬上自動開啟一個相同隔離級別的事務。當引數值為1時，COMMIT WORK等價於COMMIT AND RELEASE。當提交事務後會自動斷開與伺服器連線。
ROLLBACK：回滾會結束使用者的事務，並撤銷正在進行的所有未提交的修改。
SAVEPOINT identifiter：SAVEPOINT允許使用者在事務中建立一個儲存點，一個事務可以有很多個儲存點。
RELEASE SAVEPOINT identifier：刪除一個事務的儲存點，當沒有一個儲存點執行這語句時，會丟擲一個異常。
ROLLBACK to [SAVEPOINT] identifier：這個語句與SAVEPOINT命令一起使用。可以把事務回滾到標記點，而不回滾到此標記點之前的任何工作。注意：雖然有ROLLBACK，但是它並沒有真正的結束一個事務，因此即使執行了ROLLBACK TO SAVEPOINT，之後也需要顯示的執行COMMIT或ROLLBACK命令。
SET TRANSACTION：這個語句用來設定事務的隔離級別。InnoDB儲存引擎提供的事務隔離級別有READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。
4. 事務的隔離級別
ANSI SQL標準定義的四個隔離級別為：
READ UNCOMMITTED（未提交讀），事務中的修改，即使沒有提交，在其他事務也都是可見的。事務可以讀取未提交的資料，這也被稱為髒讀。
READ COMMITTED（提交讀），一個事務從開始直到提交之前，所做的任何修改對其他事務都是不可見的。這個級別有時候也叫做不可重複讀，因為兩次執行相同的查詢，可能會得到不一樣的結果。因為在這2次讀之間可能有其他事務更改這個資料，每次讀到的資料都是已經提交的。
REPEATABLE READ（可重複讀），解決了髒讀，也保證了在同一個事務中多次讀取同樣記錄的結果是一致的。但是理論上，可重讀讀隔離級別還是無法解決另外一個幻讀的問題，指的是當某個事務在讀取某個範圍內的記錄時，另外一個事務也在該範圍內插入了新的記錄，當之前的事務再次讀取該範圍內的記錄時，會產生幻行。
SERIALIZABLE（可序列化），它通過強制事務序列執行，避免了前面說的幻讀的問題。
1、髒讀（dirty read）：一個事務可以讀取另一個尚未提交事務的修改資料。
2、不可重複讀（nonrepeatable read）：在同一個事務中，同一個查詢在T1時間讀取某一行，在T2時間重新讀取這一行時候，這一行的資料已經發生修改，可能被更新了（update），也可能被刪除了（delete）。
3、幻像讀（phantom read）：在同一事務中，同一查詢多次進行時候，由於其他插入操作（insert）的事務提交，導致每次返回不同的結果集。
InnoDB採用MVCC來支援高併發，並實現了四個標準的隔離級別。其預設級別是REPEATABLE READ（可重複讀），並且通過間隙鎖（next-key locking）策略防止幻讀的出現。間隙鎖使得InnoDB不僅僅鎖定查詢涉及的行，還會對索引中的間隙進行鎖定，以防止幻影的插入。
隔離級別越低，事務請求的鎖越少或保持鎖的時間就越短。所以很多資料庫系統預設的事務隔離級別是READ COMMITTED。質疑SERIALIZABLE隔離級別的效能，但是InnoDB儲存引擎認為兩者的開銷是一樣的，所以預設隔離級別使用REPEATABLE READ。
用命令設定當前會話或全域性會話的事務隔離級別。
SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
{
READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE
}
如果想啟動時就設定事務的預設隔離級別，修改MYSQL的配置檔案，在[mysqld]中新增如下行：
[mysqld]
transaction-isolation = READ-COMMITTED
十一、Mysql資料庫備份與恢復
1. 資料庫備份
資料庫備份是指通過匯出資料或者複製表檔案的方式來製作資料庫的副本。當資料庫出現故障或遭到破壞時，將備份的資料庫載入到系統，從而使資料庫從錯誤狀態恢復到備份時的正確狀態。
可以使用 SELECT INTO OUTFILE 語句把表資料匯出到一個文字檔案中進行備份。
注意：這種方法只能匯出或匯入資料的內容，而不包括表的結構。若表的結構檔案損壞，則必須先設法恢復原來表的結構。
【例項】將資料庫 test_db 的表 tb_students_info 的全部資料備份到 C 盤的資料備份目錄下檔名為 file.txt 的檔案中，要求每個欄位用逗號分開，並且字元用雙引號標註，每行以問號結束。
輸入的SQL語句和執行結果如下所示。
mysql> SELECT * FROM test_db.tb_students_info
-> INTO OUTFILE 'C:/ProgramData/MySQL/MySQL Server 5.7/Uploads/file.txt'
-> FIELDS TERMINATED BY '"'
-> LINES TERMINATED BY '?';
Query OK, 10 rows affected (0.06 sec)</pre>
用記事本檢視 MySQL 備份資料夾下的 file.txt 檔案，內容如下圖所示。
2. MySQL資料庫恢復
資料庫恢復是指以備份為基礎，與備份相對應的系統維護和管理操作。
系統進行恢復操作時，先執行一些系統安全性的檢查，包括檢查所要恢復的資料庫是否存在、資料庫是否變化及資料庫檔案是否相容等，然後根據所採用的資料庫備份型別採取相應的恢復措施。
資料庫恢復機制設計的兩個關鍵問題是：第一，如何建立冗餘資料；第二，如何利用這些冗餘資料實施資料庫恢復。
建立冗餘資料最常用的技術是資料轉儲和登入日誌檔案。通常在一個資料庫系統中，這兩種方法是一起使用的。
資料轉儲是 DBA 定期地將整個資料庫複製到磁帶或另一個磁碟上儲存起來的過程。這些備用的版本成為後備副本或後援副本。
可使用 LOAD DATA…INFILE 語句來恢復先前備份的資料。
【例項】將之前匯出的資料備份檔案 file.txt 匯入資料庫 test_db 的表 tb_students_copy 中，其中 tb_students_copy 的表結構和 tb_students_info 相同。
首先建立表 tb_students_copy，輸入的 SQL 語句和執行結果如下所示：
mysql> CREATE TABLE tb_students_copy
-> LIKE tb_students_info;
Query OK, 0 rows affected (0.52 sec)
mysql> SELECT * FROM tb_students_copy;
Empty set (0.00 sec)
匯入資料與查詢表 tb_students_copy 的過程如下所示：
mysql> LOAD DATA INFILE 'C:/ProgramData/[MySQL](http://c.biancheng.net/mysql/)/MySQL Server 5.7/
Uploads/file.txt'
-> INTO TABLE test_db.tb_students_copy
-> FIELDS TERMINATED BY ','
-> OPTIONALLY ENCLOSED BY '"'
-> LINES TERMINATED BY '?';
Query OK, 10 rows affected (0.14 sec)
Records: 10 Deleted: 0 Skipped: 0 Warnings: 0
mysql> SELECT * FROM test_db.tb_students_copy;
+----+--------+---------+------+------+--------+------------+
| id | name | dept_id | age | sex | height | login_date |
+----+--------+---------+------+------+--------+------------+
| 1 | Dany | 1 | 25 | F | 160 | 2015-09-10 |
| 2 | Green | 3 | 23 | F | 158 | 2016-10-22 |
| 3 | Henry | 2 | 23 | M | 185 | 2015-05-31 |
| 4 | Jane | 1 | 22 | F | 162 | 2016-12-20 |
| 5 | Jim | 1 | 24 | M | 175 | 2016-01-15 |
| 6 | John | 2 | 21 | M | 172 | 2015-11-11 |
| 7 | Lily | 6 | 22 | F | 165 | 2016-02-26 |
| 8 | Susan | 4 | 23 | F | 170 | 2015-10-01 |
| 9 | Thomas | 3 | 22 | M | 178 | 2016-06-07 |
| 10 | Tom | 4 | 23 | M | 165 | 2016-08-05 |
+----+--------+---------+------+------+--------+------------+
10 rows in set (0.00 sec)</pre>
十二、Mysql分庫分表
1. 分庫分表原則
關係型資料庫本身比較容易成為系統效能瓶頸，單機儲存容量、連線數、處理能力等都很有限，資料庫本身的“有狀態性”導致了它並不像Web和應用伺服器那麼容易擴充套件。在網際網路行業海量資料和高併發訪問的考驗下，聰明的技術人員提出了分庫分表技術（有些地方也稱為Sharding、分片）。同時，流行的分散式系統中介軟體（例如MongoDB、ElasticSearch等）均自身友好支援Sharding，其原理和思想都是大同小異的。
目前針對海量資料的優化，其分庫分表是MySQL永遠的話題，一般情況下認為MySQL是個簡單的資料庫，在資料量大到一定程度之後處理查詢的效率降低，如果需要繼續保持高效能運轉的話，必須分庫或者分表了。關於資料量達到多少大是個極限這個事兒，本文先不討論，研究原始碼的同學已經證實MySQL或者Innodb內部的鎖粒度太大的問題大大限制了MySQL提供QPS的能力或者處理大規模資料的能力。在這點上，一般的使用者只好坐等官方不斷推出的優化版本了。
在一般運維的角度來看，我們什麼情況下需要考慮分庫分表？
首先說明，這裡所說的分庫分表是指把資料庫資料的物理拆分到多個例項或者多臺機器上去，而不是類似分割槽表的原地切分。
1.1 能不分就不分
MySQL 是關聯式資料庫，資料庫表之間的關係從一定的角度上對映了業務邏輯。任何分庫分表的行為都會在某種程度上提升業務邏輯的複雜度，資料庫除了承載資料的儲存和訪問外，協助業務更好的實現需求和邏輯也是其重要工作之一。分庫分表會帶來資料的合併，查詢或者更新條件的分離，事務的分離等等多種後果，業務實現的複雜程度往往會翻倍或者指數級上升。所以，在分庫分表之前，不要為分而分，去做其他力所能及的事情吧，例如升級硬體，升級，升級網路，升級資料庫版本，讀寫分離，負載均衡等等。所有分庫分表的前提是，這些你已經盡力了。
1.2 資料量太大，正常的運維影響正常業務訪問
這裡說的運維，例如：
（1）對資料庫的備份。如果單表或者單個例項太大，在做備份的時候需要大量的磁碟IO或者網路IO資源。例如1T的資料，網路傳輸佔用50MB的時候，需要20000秒才能傳輸完畢，在此整個過程中的維護風險都是高於平時的。我們在Qunar的做法是給所有的資料庫機器新增第二塊網路卡，用來做備份，或者SST，Group Communication等等各種內部的資料傳輸。1T的資料的備份，也會佔用大量的磁碟IO，如果是SSD還好，當然這裡忽略某些廠商的產品在集中IO的時候會出一些BUG的問題。如果是普通的物理磁碟，則在不限流的情況下去執行xtrabackup，該例項基本不可用。
（2）對資料表的修改。如果某個表過大，對此表做DDL的時候，MySQL會鎖住全表，這個時間可能很長，在這段時間業務不能訪問此表，影響甚大。解決的辦法有類似騰訊遊戲DBA自己改造的可以線上秒改表，不過他們目前也只是能新增欄位而已，對別的DDL還是無效；或者使用pt-online-schema-change，當然在使用過程中，它需要建立觸發器和影子表，同時也需要很長很長的時間，在此操作過程中的所有時間，都可以看做是風險時間。把資料表切分，總量減小，有助於改善這種風險。
（3）整個表熱點，資料訪問和更新頻繁，經常有鎖等待，你又沒有能力去修改原始碼，降低鎖的粒度，那麼只會把其中的資料物理拆開，用空間換時間，變相降低訪問壓力。
1.3 某些資料表出現了無窮增長
例子很好舉，各種的評論，訊息，日誌記錄。這個增長不是跟人口成比例的，而是不可控的，例如微博的feed的廣播，我發一條訊息，會擴散給很多很多人。雖然主體可能只存一份，但不排除一些索引或者路由有這種儲存需求。這個時候，增加儲存，提升機器配置已經蒼白無力了，水平切分是最佳實踐。拆分的標準很多，按使用者的，按時間的，按用途的，不在一一舉例。
1.4 安全性和可用性的考慮
這個很容易理解，雞蛋不要放在一個籃子裡，我不希望我的資料庫出問題，但我希望在出問題的時候不要影響到100%的使用者，這個影響的比例越少越好，那麼，水平切分可以解決這個問題，把使用者，庫存，訂單等等本來同統一的資源切分掉，每個小的資料庫例項承擔一小部分業務，這樣整體的可用性就會提升。這對Qunar這樣的業務還是比較合適的，人與人之間，某些庫存與庫存之間，關聯不太大，可以做一些這樣的切分。
1.5 業務耦合性考慮
這個跟上面有點類似，主要是站在業務的層面上，我們的火車票業務和烤羊腿業務是完全無關的業務，雖然每個業務的資料量可能不太大，放在一個MySQL例項中完全沒問題，但是很可能烤羊腿業務的DBA 或者開發人員水平很差，動不動給你出一些么蛾子，直接把資料庫搞掛。這個時候，火車票業務的人員雖然技術很優秀，工作也很努力，照樣被老闆打屁股。解決的辦法很簡單:惹不起，躲得起。
2. 分庫分表方案
2.1 垂直拆分（垂直分表）
垂直分表在日常開發和設計中比較常見，通俗的說法叫做“大表拆小表”，拆分是基於關係型資料庫中的“列”（欄位）進行的。通常情況，某個表中的欄位比較多，可以新建立一張“擴充套件表”，將不經常使用或者長度較大的欄位拆分出去放到“擴充套件表”中，如下圖所示：
2.2 垂直拆分（垂直分庫）
垂直分庫在“微服務”盛行的今天已經非常普及了。基本的思路就是按照業務模組來劃分出不同的資料庫，而不是像早期一樣將所有的資料表都放到同一個資料庫中。如下圖：
小結：
系統層面的“服務化”拆分操作，能夠解決業務系統層面的耦合和效能瓶頸，有利於系統的擴充套件維護。而資料庫層面的拆分，道理也是相通的。與服務的“治理”和“降級”機制類似，我們也能對不同業務型別的資料進行“分級”管理、維護、監控、擴充套件等。
眾所周知，資料庫往往最容易成為應用系統的瓶頸，而資料庫本身屬於“有狀態”的，相對於Web和應用伺服器來講，是比較難實現“橫向擴充套件”的。資料庫的連線資源比較寶貴且單機處理能力也有限，在高併發場景下，垂直分庫一定程度上能夠突破IO、連線數及單機硬體資源的瓶頸，是大型分散式系統中優化資料庫架構的重要手段。
然後，很多人並沒有從根本上搞清楚為什麼要拆分，也沒有掌握拆分的原則和技巧，只是一味的模仿大廠的做法。導致拆分後遇到很多問題（例如：跨庫join，分散式事務等）。
優勢：降低高併發情況下，對於表的鎖定。
不足：對於單表來說，隨著資料庫的記錄增多，讀寫壓力將進一步增大。
2.3 水平拆分（水平分表）
水平分表也稱為橫向分表，比較容易理解，就是將表中不同的資料行按照一定規律分佈到不同的資料庫表中（這些表儲存在同一個資料庫中），這樣來降低單表資料量，優化查詢效能。最常見的方式就是通過主鍵或者時間等欄位進行Hash和取模後拆分。如下圖所示：
如果單表的IO壓力大，可以考慮用水平分割，其原理就是通過hash演算法，將一張表分為N多頁，並通過一個新的表（總表），記錄著每個頁的的位置。假如一個入口網站，它的資料庫表已經達到了1000萬條記錄，那麼此時如果通過select去查詢，必定會效率低下（不做索引的前提下）。為了降低單表的讀寫IO壓力，通過水平分割，將這個表分成10個頁，同時生成一個總表，記錄各個頁的資訊，那麼假如我查詢一條id=100的記錄，它不再需要全表掃描，而是通過總表找到該記錄在哪個對應的頁上，然後再去相應的頁做檢索，這樣就降低了IO壓力。
當下分表有靜態分表和動態分表兩種：
靜態分表：事先估算出表能達到的量，然後根據每一個表需要存多少資料直接算出需要建立表的數量。如：1億資料每一個表100W條資料那就要建100張表，然後通過一定的hash演算法計算每一條資料存放在那張表。其實就有點像是使用partition table一樣。靜態分表有一個斃命就是當分的那麼多表還不滿足時，需要再擴充套件難度和成本就會很高。
動態分表：同樣也是對大資料量的表進行拆分，他可以避免靜態分錶帶來的後遺症。當然也需要在設計上多一些東西（這往往是我們能接受的）。
某種意義上來講，有些系統中使用的“冷熱資料分離”（將一些使用較少的歷史資料遷移到其他的資料庫中。而在業務功能上，通常預設只提供熱點資料的查詢），也是類似的實踐。在高併發和海量資料的場景下，分庫分表能夠有效緩解單機和單庫的效能瓶頸和壓力，突破IO、連線數、硬體資源的瓶頸。當然，投入的硬體成本也會更高。同時，這也會帶來一些複雜的技術問題和挑戰（例如：跨分片的複雜查詢，跨分片事務等）
3. 分庫分表難點
3.1 跨庫join的問題
在拆分之前，系統中很多列表和詳情頁所需的資料是可以通過sql join來完成的。而拆分後，資料庫可能是分散式在不同例項和不同的主機上，join將變得非常麻煩。而且基於架構規範，效能，安全性等方面考慮，一般是禁止跨庫join的。那該怎麼辦呢？首先要考慮下垂直分庫的設計問題，如果可以調整，那就優先調整。如果無法調整的情況，下面筆者將結合以往的實際經驗，總結幾種常見的解決思路，並分析其適用場景。
跨庫Join的幾種解決思路：
全域性表
所謂全域性表，就是有可能系統中所有模組都可能會依賴到的一些表。比較類似我們理解的“資料字典”。為了避免跨庫join查詢，我們可以將這類表在其他每個資料庫中均儲存一份。同時，這類資料通常也很少發生修改（甚至幾乎不會），所以也不用太擔心“一致性”問題。
欄位冗餘
這是一種典型的反正規化設計，在網際網路行業中比較常見，通常是為了效能來避免join查詢。
舉個電商業務中很簡單的場景：
“訂單表”中儲存“賣家Id”的同時，將賣家的“Name”欄位也冗餘，這樣查詢訂單詳情的時候就不需要再去查詢“賣家使用者表”。
欄位冗餘能帶來便利，是一種“空間換時間”的體現。但其適用場景也比較有限，比較適合依賴欄位較少的情況。最複雜的還是資料一致性問題，這點很難保證，可以藉助資料庫中的觸發器或者在業務程式碼層面去保證。當然，也需要結合實際業務場景來看一致性的要求。就像上面例子，如果賣家修改了Name之後，是否需要在訂單資訊中同步更新呢？
資料同步
定時A庫中的tab_a表和B庫中tbl_b有關聯，可以定時將指定的表做同步。當然，同步本來會對資料庫帶來一定的影響，需要效能影響和資料時效性中取得一個平衡。這樣來避免複雜的跨庫查詢。筆者曾經在專案中是通過ETL工具來實施的。
系統層組裝
在系統層面，通過呼叫不同模組的元件或者服務，獲取到資料並進行欄位拼裝。說起來很容易，但實踐起來可真沒有這麼簡單，尤其是資料庫設計上存在問題但又無法輕易調整的時候。具體情況通常會比較複雜。
3.2 跨庫事務（分散式事務）的問題
按業務拆分資料庫之後，不可避免的就是“分散式事務”的問題。想要了解分散式事務，就需要了解“XA介面”和“兩階段提交”。值得提到的是，MySQL5.5x和5.6x中的xa支援是存在問題的，會導致主從資料不一致。直到5.7x版本中才得到修復。Java應用程式可以採用Atomikos框架來實現XA事務（J2EE中JTA）。感興趣的讀者可以自行參考《分散式事務一致性解決方案》，連結地址：<u>http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency</u>
根據系統架構和公司實際情況來，如果你們的系統還是個簡單的單體應用，並且沒有什麼訪問量和資料量，那就彆著急折騰“垂直分庫”了，否則沒有任何收益，也很難有好結果。
切記，“過度設計”和“過早優化”是很多架構師和技術人員常犯的毛病。
十三、Mysql許可權管理
1. MySQL許可權簡介
關於mysql的許可權簡單的理解就是mysql允許你做你全力以內的事情，不可以越界。比如只允許你執行select操作，那麼你就不能執行update操作。只允許你從某臺機器上連線mysql，那麼你就不能從除那臺機器以外的其他機器連線mysql。
那麼Mysql的許可權是如何實現的呢？這就要說到mysql的兩階段驗證，下面詳細介紹：第一階段：伺服器首先會檢查你是否允許連線。因為建立使用者的時候會加上主機限制，可以限制成本地、某個IP、某個IP段、以及任何地方等，只允許你從配置的指定地方登陸。第二階段：如果你能連線，Mysql會檢查你發出的每個請求，看你是否有足夠的許可權實施它。比如你要更新某個表、或者查詢某個表，Mysql會檢視你對哪個表或者某個列是否有許可權。再比如，你要執行某個儲存過程，Mysql會檢查你對儲存過程是否有執行許可權等。
2. Mysql許可權種類
3. MySQL許可權經驗原則
許可權控制主要是出於安全因素，因此需要遵循一下幾個經驗原則：
（1）只授予能滿足需要的最小許可權，防止使用者幹壞事。比如使用者只是需要查詢，那就只給select許可權就可以了，不要給使用者賦予update、insert或者delete許可權。
（2）建立使用者的時候限制使用者的登入主機，一般是限制成指定IP或者內網IP段。
（3）初始化資料庫的時候刪除沒有密碼的使用者。安裝完資料庫的時候會自動建立一些使用者，這些使用者預設沒有密碼。
（4）為每個使用者設定滿足密碼複雜度的密碼。
（5）定期清理不需要的使用者。回收許可權或者刪除使用者。
十四、Mysql資料庫之阿里雲
1. 簡介
經過上面的學習，大家已經對mysql資料庫的知識有了很深的瞭解，我們也知道，一個資料庫在實際生產環境中，會面臨許多的問題，比如Sql語句審計、sql讀寫分離、sql備份與恢復、資料庫的許可權管理、資料庫的高可用等等，對於創業公司來講，資料庫是非常重要的，但是花費了很多人力物力去滿足這個事情，那麼還不如直接使用成熟的第三方平臺，比如阿里雲的mysql資料庫產品。
2. 阿里雲資料庫產品功能
2.1 資料庫建立
2.2 連線管理與讀寫分離
2.3 監控與報警
我們可以線上監控到CPU、記憶體、磁碟、IOPS、網路流量等的使用情況，並設定報警規則
2.4 白名單
我們可以設定允許連線資料庫的IP白名單，以保障資料庫連線安全
2.5 服務可用性
阿里雲的資料庫可包含高可用，主備切換、主從備份等
2.6 日誌管理
日誌管理包括訂閱同步、錯誤日誌、慢日誌分析、主備切換日誌
2.7 SQL洞察
對sql語句的操作進行記錄，包括操作的資料庫名、資料庫語句、操作時間、客戶端IP等資訊
2.8 效能優化
阿里雲提供診斷報告、資源分析、SQL分析等服務
2.9 備份恢復
十五、資料下載
連結：https://pan.baidu.com/s/1yvDw2ptCQ4K4x9IhebNo6g
提取碼：4aoo