MySQL數據庫基礎詳解(非原創）

時間 2019-11-30

原文原文鏈接

文章大綱

1、數據庫簡介
2、Mysql數據庫簡介
3、Mysql安裝與服務啓動（Windows版本）
4、Mysql圖形化工具
5、Mysql存儲引擎精講
6、Mysql數據類型介紹
7、Mysql主要專業名稱介紹
8、Mysql常見sql語句
9、Mysql設計與語句優化
10、事務介紹
11、Mysql數據庫備份與恢復
12、Mysql分庫分表
十3、Mysql權限管理
十4、Mysql數據庫之阿里雲
十5、資料下載
十6、參考文章css

1、數據庫簡介

1. 數據庫是什麼

數據庫是數據管理的有效技術，是由一批數據構成的有序集合，這些數據被存放在結構化的數據表裏。數據表之間相互關聯，反映客觀事物間的本質聯繫。數據庫能有效地幫助一個組織或企業科學地管理各種信息資源。
數據是數據庫中存儲的基本對象，是按必定順序排列組合的物理符號。數據有多種表現形式，能夠是數字、文字、圖像，甚至是音頻或視頻，它們均可以通過數字化後存入計算機。
數據庫是數據的集合，具備統一的結構形式並存放於統一的存儲介質內，是多種應用數據的集成，並可被各個應用程序所共享。
在平常生活中，人們能夠直接用中文、英文等天然語言描述客觀事物。在計算機中，則要抽象出對這些事物感興趣的特徵，並組成一個記錄來描述。html

2. 數據庫在開發中的做用

從數據庫系統應用角度來看，數據庫系統常見的運行與應用結構有：客戶端/服務器結構、瀏覽器/服務器結構。
在客戶端/服務器（Client/Server，C/S）結構中，數據庫的使用者（如 DBA、程序設計者）經過命令行客戶端、圖形化界面管理工具或應用程序等鏈接到數據庫管理系統，能夠經過數據庫管理系統查詢和處理存儲在底層數據庫中的各類數據。
數據庫使用者與命令行客戶端、圖形化界面管理工具或應用程序等直接交互，而不與數據庫管理系統直接聯繫。
在這種結構中，命令行客戶端、圖形化界面管理工具或應用程序等稱爲「客戶端」或「前臺」，主要完成與數據庫使用者的交互任務；而數據庫管理系統則稱爲「服務器」或「後臺」，主要負責數據管理。這種結構常常被稱爲「C/S」結構。
在客戶端/服務器模式中，客戶端和服務器能夠同時工做在同一臺計算機上，這種工做方式稱爲「單機方式」；也能夠「網絡方式」運行，即服務器被安裝和部署在網絡中某一臺或多臺主機上。
對於客戶端應用程序的開發，目前經常使用的語言工具主要有 Visual C++、Delphi、.NET 框架、Visual Basic、Python 等。
數據庫能有效存儲數據，讀取數據、查找數據更是方便，其實那些管理軟件就是經過軟件的界面向內部的數據庫進行數據的增、刪、改、查操做。前端

3.常見數據庫比較

3.1 MySQL數據庫
定位
開源、多平臺、關係型數據庫
目前使用最普遍、流行度最高的的開源數據庫。java

功能
支持事務，符合關係型數據庫原理，符合ACID，支持多數SQL規範，以二維表方式組織數據，有插件式存儲引擎，支持多種存儲引擎格式python

部署
用編譯安裝的方式，或者二進制包的方式，按照「安裝軟件-建立實例-庫表用戶初始化」，能夠很快完成數據庫部署mysql

使用
使用標準的SQL語句進行數據庫管理，簡單SQL語句的併發和性能較好，對視圖、存儲過程、函數、觸發器等支持的不是太好linux

監控
在命令行界面有一些經常使用的命令顯示狀態和性能，在圖形界面方面，有比較多的開源監控工具來監控和記錄數據庫的狀態，好比zabbix，nagios，cacti，lepus等ios

備份
邏輯備份 mysqldump/mysqldumper ，物理備份用xtrabackup等工具進行備份；正則表達式

高可用
MySQL高可用有多種方案，官方有基礎的master-slave主從複製，新版本的innodb cluster，第三方的有MHA等高可用方案；redis

擴展
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. 數據庫常見功能

2、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 23十二、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 具備如下幾個方面的新功能。

3、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（下一步）」按鈕，如圖所示。

進入MySQL安裝界面並接受系統協議

步驟 2)：進入「Choosing a Setup Type（安裝類型選擇）」窗口，根據右側的安裝類型描述文件選擇適合本身的安裝類型，這裏選擇默認的安裝類型，如圖所示。

選擇默認的安裝類型

注意：Developer Default：默認安裝類型；Server only：僅做爲服務；Client only：僅做爲客戶端；Full：徹底安裝；Custom：自定義安裝類型。

步驟 3)：根據所選擇的安裝類型安裝 Windows 系統框架（framework），單擊 Execute 按鈕，安裝程序會自動完成框架的安裝，如圖所示。

檢查並生成安裝所須要的框架列表

當彈出安裝程序窗口時，勾選「我贊成許可條款和條件」複選框，而後單擊「安裝」按鈕，如圖所示。

贊成安裝框架的許可條件

彈出「設置成功」的界面，表示該框架已經安裝完成，單擊「關閉」按鈕便可。全部的框架安裝都可參考本操做，如圖所示。

安裝框架成功

步驟 4)：所需框架均安裝成功後，單擊「Next（下一步）」按鈕，如圖所示。

全部框架安裝完成

步驟 5)：進入安裝確認窗口，單擊「Execute（執行）」按鈕，開始 MySQL 各個組件的安裝，如圖所示。

準備安裝MySQL各個組件

步驟 6)：開始安裝 MySQL 文件，安裝完成後在「Status（狀態）」列表下顯示「Complete（安裝成功）」，如圖所示。

MySQL各個組件安裝成功

3. 判斷是否安裝成功

3.1 啓動與關閉服務
net start mysql爲啓動服務，net stop mysql爲關閉命令

3.2 登陸數據庫
cmd進入數據庫的bin文件夾中

輸入mysql -u root -p命令，再輸入登陸密碼，出現如下結果表明登陸成功

3.3 查看數據庫名稱
登陸完成後，輸入show databases

4、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的最新版本，包括它用來管理數據庫結構的全部最新功能，如工做表、視圖、存儲過程、函數、事件、外鍵和觸發器等。

5、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。

6、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 將忽視這些值，給出警告。

7、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這兩種。

8、Mysql常見sql語句

1. select語句

請在資料下載中進行學習

2. 函數

請在資料下載中進行學習

3. 多表查詢

請在資料下載中進行學習

4. 表的內連與外連‘

請在資料下載中進行學習’

9、Mysql設計與語句優化

1. 數據庫建立優化

請在資料下載中進行學習

2. sql語句優化

請在資料下載中進行學習

10、事務介紹

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（可串行化），它經過強制事務串行執行，避免了前面說的幻讀的問題。
一、髒讀（dirty read）：一個事務能夠讀取另外一個還沒有提交事務的修改數據。

二、不可重複讀（nonrepeatable read）：在同一個事務中，同一個查詢在T1時間讀取某一行，在T2時間從新讀取這一行時候，這一行的數據已經發生修改，可能被更新了（update），也可能被刪除了（delete）。

三、幻像讀（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

11、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>

12、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>

根據系統架構和公司實際狀況來，若是大家的系統仍是個簡單的單體應用，而且沒有什麼訪問量和數據量，那就彆着急折騰「垂直分庫」了，不然沒有任何收益，也很難有好結果。
切記，「過分設計」和「過早優化」是不少架構師和技術人員常犯的毛病。

十3、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）按期清理不須要的用戶。回收權限或者刪除用戶。

十4、Mysql數據庫之阿里雲

1. 簡介

通過上面的學習，你們已經對mysql數據庫的知識有了很深的瞭解，咱們也知道，一個數據庫在實際生產環境中，會面臨許多的問題，好比Sql語句審計、sql讀寫分離、sql備份與恢復、數據庫的權限管理、數據庫的高可用等等，對於創業公司來說，數據庫是很是重要的，可是花費了不少人力物力去知足這個事情，那麼還不如直接使用成熟的第三方平臺，好比阿里雲的mysql數據庫產品。