MYSQL優化mysql資料庫匯入匯出impexp
MYSQL優化mysql資料庫匯入匯出impexp
MYSQL優化主要分為以下四大方面：
設計：儲存引擎，欄位型別，正規化與逆正規化
功能：索引，快取，分割槽分表。
架構：主從複製，讀寫分離，負載均衡。
合理SQL：測試，經驗。
一、儲存引擎
在建立表的時候我們使用sql語句，Create table tableName () engine=myisam|innodb;
這裡就指明瞭儲存引擎是myisam還是innodb。儲存引擎是一種用來儲存MySQL中物件（記錄和索引）的一種特定的結構（檔案結構），處於MySQL伺服器的最底層，直接儲存資料。導致上層的操作，依賴於儲存引擎的選擇。地位如下圖：
網路介面層：與客戶端通訊，比如傳輸資料等等。儲存引擎層：儲存資料的規則，方式。
本質：儲存引擎就是特定的資料儲存格式（方案）。
可以使用show engines命令來檢視當前MySQL支援的儲存引擎列表。
1、InnoDB儲存引擎介紹
Mysql版本>=5.5 預設的儲存引擎，MySQL推薦使用的儲存引擎。支援事務，行級鎖定，外來鍵約束。事務安全型儲存引擎。更加註重資料的完整性和安全性。
（1）儲存格式
資料，索引集中儲存，儲存於同一個表空間檔案中。
資料：記錄行。索引：一種檢索機制，也需要一定的空間，就相當於一本字典的目錄。
示例： 建立一個test資料庫，新建一張student表，選擇儲存引擎為innodb, 然後開啟
其中db.opt存放了資料庫的配置資訊，比如資料庫的字符集還有編碼格式。student.frm是表結構檔案，僅儲存了表的結構、元資料(meta)，包括表結構定義資訊等。不論是哪個表引擎都會有一個frm檔案。student.ibd是表索引檔案，包括了單獨一個表的資料及索引內容。
如果往表裡插入了新的資料，則在mysql的data目錄下會生成ibdata1檔案，這個檔案是儲存了所有innodb表的資料。
關於innodb引擎的詳細介紹：
使用innodb引擎時，需要理解獨立表空間、共享表空間。
獨立表空間：每個表都會生成以獨立的檔案方式來儲存，每個表都一個.frm的描述檔案，還有一個.ibd檔案。其中這個檔案包括了單獨一個表的資料及索引內容，預設情況下它的儲存在mysql指定的目錄下。
獨立表空間優缺點
優點：
每個表都有自己獨立的表空間；每個表的資料和索引都會儲存在各個獨立的表空間中；可以實現單表在不同的資料進行遷移；表空間可以回收（除了drop table操作，表空不能自己回收）；drop table 操作自動回收表空間，如果對統計分析或是日值表，刪除大量資料後可以通過 ：alter table tablename engin=innodb進行回縮不用的空間；對於使用inodb-plugin的innodb使用truncate table會使用空間收縮。；對於使用獨立表空間，不管怎麼刪除，表空間的碎片都不會太嚴重。
缺點：
單表增加過大，如超過100G。對於單表增長過大的問題，如果使用共享表空間可以把檔案分開，但有同樣有一個問題，如果訪問的範圍過大同樣會訪問多個檔案，一樣會比較慢。對於獨立表空間也有一個解決辦法是：使用分割槽表，也可以把那個大的表空間移動到別的空間上然後做一個連線。其實從效能上出發，當一個表超過100個G有可能響應也是較慢了，對於獨立表空間還容易發現問題早做處理。
共享表空間：某一個數據庫所有的表資料，索引檔案全部都放在一個檔案中，預設這個共享表空間的檔案路徑在data目錄下，預設的檔名為 ibdata1,初始化為10M。
共享表空間優缺點
優點：可以將表空間分成多個檔案存放在各個磁碟上（表空間檔案大小不受表大小的限制，如一個表可以分佈在不同的檔案上），資料和檔案放在一起方便管理。
缺點：所有的資料和索引存放到一個檔案中，將來會是一個很大的檔案，雖然可以把一個大檔案分成多個小檔案，但是多個表及索引在表空間中混合儲存，這樣對一個表做了大量刪除操作後表空間將有大量的空隙，特別是對統計分析、日值系統這類應用最不適合用共享表空間。
如何開啟獨立表空間？
檢視是否開啟獨產表空間：
mysql> show variables like '%per_table';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | OFF |
+-----------------------+-------+
設定開啟：
在my.cnf檔案中[mysqld] 節點下新增innodb_file_per_table=1
或者通過命令：set global innodb_file_per_table=1;
注：
innodb_file_per_table值來進行修改即可，但是對於之前使用過的共享表空間則不會影響，除非手動的去進行修改或者是
innodb_file_per_table=1 為使用獨佔表空間
innodb_file_per_table=0 為使用共享表空間
修改獨佔空表空間的資料儲存位置
innodb_data_home_dir = "C:\mysql\data\"
innodb_log_group_home_dir = "C:\mysql\data\"
innodb_data_file_path=ibdata1:10M:autoextend
innodb_file_per_table=1
引數說明:
這個設定配置一個可擴充套件大小的尺寸為10MB的單獨檔案，名為ibdata1。沒有給出檔案的位置，所以預設的是在MySQL的資料目錄內。【對資料來進行初始化的設定】
innodb_data_home_dir 代表為資料庫檔案所存放的目錄
innodb_log_group_home_dir 為日誌存放目錄
innodb_file_per_table 是否使用共享以及獨佔表空間來
以上的幾個引數必須在一起加入。
對於引數一些注意的地方
InnoDB不建立目錄，所以在啟動伺服器之前請確認”所配置的路徑目錄”的確存在。這對你配置的任何日誌檔案目錄來說也是真實的。使用Unix或DOS的mkdir命令來建立任何必需的目錄。
通過把innodb_data_home_dir的值原原本本地部署到資料檔名，並在需要的地方新增斜槓或反斜槓，InnoDB為每個資料檔案形成目錄路徑。
如果innodb_data_home_dir選項根本沒有在my.cnf中提到，預設值是“dot”目錄 ./，這意思是MySQL資料目錄。
（2）資料按照主鍵順序儲存
插入時做排序工作，效率低。
（3）特定功能
事務、外來鍵約束 ： 都是為了維護資料的完整性。
併發性處理：
innodb擅長處理併發的。因為它使用了行級鎖定，只該行鎖了，其它行沒有鎖。
行級鎖定：row-level locking，實現了行級鎖定，在一定情況下，可以選擇行級鎖來提升併發性。也支援表級鎖定，Innodb會自帶鎖，不需要我們自己設定。
多版本併發控制, MVCC，效果達到無阻塞讀操作。
（4）總結：innodb擅長事務、資料的完整性及高併發處理，不擅長快速插入（插入前要排序，消耗時間）和檢索。
2.MyISAM儲存引擎介紹
MySQL<= 5.5 MySQL預設的儲存引擎。
ISAM：Indexed Sequential Access Method(索引順序存取方法)的縮寫，是一種檔案系統。
擅長與處理，高速讀與寫。
（1）儲存方式
資料和索引分別儲存於不同的檔案中。
（2）資料的儲存順序為插入順序（沒有經過排序）
插入速度快，空間佔用量小。
（3）功能
a.全文索引支援。（mysql>=5.6時innodb 也支援）
b.資料的壓縮儲存。.MYD檔案的壓縮儲存。
壓縮前，資料是25600KB：
進行壓縮：使用工具 myisamPack完成壓縮功能：該工具mysql自帶
進入到需要壓縮表的資料目錄，執行壓縮指令 myisampack 表名。配置環境變數。
壓縮後：
注意，壓縮後，需要重新修復索引：
檢視結果，發現現在的資料變成12741KB了，比之前的更小了：
壓縮優勢：節省磁碟空間，減少磁碟IO開銷。特點：壓縮後的表變成了只讀表，不可寫。
如果需要更新資料，則需要先解壓後更新。利用工具：myisamchk –unpack 表名 進行解壓
解壓後，變成了原來的25600KB
重新整理表的狀態：flush table myisam_2
c.併發性：
僅僅支援表級鎖定，不支援高併發。
支援併發插入。寫操作中的插入操作，不會阻塞讀操作（其他操作）
（4）關於Innodb 和myisam的取捨：
Innodb ：資料完整性，併發性處理，擅長更新，刪除。
myisam：高速查詢及插入。擅長插入和查詢。
具體舉例：
那麼對於微博專案來看，選擇哪一個儲存引擎呢？
a.微博主要是插入微博和查詢微博列表，較為適合MyISAM；
b.微博在更新微博和刪除微博，要少的多，較為適合MyISAM；
c.對資料完整性的需求並沒有那麼強烈，比如使用者刪除微博，關聯的轉播和評論並不要求都做相應的行為，較為適合MyISAM；
那麼對於記賬財務系統，選擇哪一款儲存引擎呢？
a.財務系統除了讀取和插入，經常要進行資料的修改和刪除，較為適合InnoDB；
b.在進行財務變更的時候，如果失敗需要回滾必須用到事務，較為適合InnoDB；
c.每個使用者的財務資料完整性和同步性非常重要，需要外來鍵支援，否則財務將會混亂，較為適合InnoDB。
3.其他儲存引擎
（1）Archive：存檔型，僅提供插入和查詢操作。非常高效阻塞的插入和查詢。
（2）Memory：記憶體型，資料儲存於記憶體中，儲存引擎。快取型儲存引擎。
（3）外掛式儲存引擎：用C和C++開發的儲存引擎。
4.鎖的概念：當客戶端操作表（記錄）時，為了保證操作的隔離性（多個客戶端操作不能互相影響），通過加鎖來處理。
操作方面：
讀鎖：讀操作時增加的鎖，也叫共享鎖，S-lock。特徵是阻塞其他客戶端的寫操作，不阻塞讀操作。（併發讀）
寫鎖：寫操作時增加的鎖，也叫獨佔鎖或排他鎖，X-lock。特徵是阻塞其他客戶端的讀，寫操作。
鎖定粒度（範圍）：
行級：提升併發性，鎖本身開銷大
表級：不利於併發性，鎖本身開銷小。
二、欄位型別選擇
欄位型別應該要滿足需求，儘量要滿足以下需求。
儘可能小（佔用儲存空間少）、儘可能定長（佔用儲存空間固定）、儘可能使用整數。
1.列型別之數值
（1）整型
MySQL資料庫支援五種整型型別，包括：TINYINT、SMALLINT、MEDIUMINT、INT和BIGINT五種。
整型型別佔用空間和取值範圍
型別 位元組 最小值 最大值
TINYINT 1 有符號：-128 無符號：0 有符號：127 無符號：255
SMALLINT 2有符號：-32768無符號：0有符號：32767無符號：65535
MEDIUMINT 3有符號：-8388608無符號：0有符號：8388607無符號：16777215
INT/INTEGER 4有符號：-2147483648無符號：0有符號：2147483647無符號：4294967295
BIGINT 8 有符號：-9223372036854775808無符號：0 有符號：9223372036854775807無符號：18446744073709551615
五種整型的適用場景：
TINYINT，年齡，包含在0~255之間；
SMALLINT，埠號，包含在0~65535之間；
MEDIUMINT，中小型網站註冊會員，1600萬夠用；
INT，身份證編號，42億可以用很久；
BIGINT，Twitter微博量，幾百億
（2）浮點型(非精確)
MySQL資料庫支援兩種浮點型別：FLOAT(單精度)和DOUBLE(雙精度)兩種
浮點型(非精確)佔用空間和取值範圍
型別 位元組 範圍
FLOAT 4 正數範圍：1.175494351E-38~3.402823466E+38，負數範圍：-3.402823466E+38~-1.175494351E-38
DOUBLE 8 正數範圍：1.7976931348623157E-308~2.2250738585072014E+308
負數範圍：-2.2250738585072014E+308~-1.7976931348623157E-308
（3）定點型(精確)
浮點型由於內部的儲存方式是數值，導致它在一定程度上取得的是近似值而非精確值。如果使用定點型，那麼就可以精確取得小數部分，因為它內部儲存方式是字串形式。
定點型(精確)佔用空間和取值範圍
型別 位元組 範圍
DECIMAL/NUMERIC M+2 M最大65位，D最大30位。
建立一個定點型格式：DECIMAL(M,D)，表示小數點D位，整數部分M位及M位內。
2.列型別之日期
MySQL資料庫中有五個可用的日期時間資料型別，分別為：DATE、DATETIME、TIME、YEAR、TIMESTAMP。
日期時間型別佔用空間和取值範圍
型別 位元組 最小值 最大值
YEAR 1 1901 2155
TIME 3 -838:59:59838:59:59
DATE 4 1000-01-01 9999-12-31
TIMESTAMP 4 1970-01-01 00:00:00 2038-01-19 03:14:07
DATETIME 8 1000-01-01 00:00:00 9999-12-31 23:59:59
TIMESTAMP有幾個特點：
a.當更新一條資料的時候，設定此型別根據當前系統更新可自動更新時間；
b.如果插入一條NULL，也會自動插入當前系統時間；
c.建立欄位時，系統會自動給一個預設值；
d.會根據當前時區來儲存和查詢時間，儲存時對當前時區進行轉換，查詢時再轉換為當前的時區。
//檢視當前時區
SHOW VARIABLES LIKE 'time_zone';
//設定為東九區，查詢時間就會加1小時
SET time_zone='+9:00';
DATE佔用3個位元組，包含年月日，範圍和DATETIME一樣。DATE長度是0，無法設定。
YEAR佔用1個位元組，包年年份，長度預設為4位，無法設定。
TIME佔用3個位元組，包含時分秒，長度0到6之間，用於設定微秒。對於TIME的範圍的時是-838到838的原因，是因為TIME型別不但可以儲存一天的時，還可以包含時間之間的間隔。
綜上考慮：使用datetime，當然也可以使用int（11）來儲存時間戳。
關於INT(11)存放時間戳的優點如下：
a.INT佔4個位元組，DATETIME佔8個位元組；
b.INT儲存索引的空間比DATETIME小，查詢快，排序效率高；
c.在計算機時間差等範圍問題，比較方便。
3.列型別之字元
字符集校對規則utf8_general_ci表示校對時不區分大小寫，相對的cs表示區分大小寫。還有一個bin結尾的是位元組比較。而general是地區名，這裡是通用，utf8表示編碼。如果是gbk，可以使用gbk_chinese_ci，如果是utf8則用utf8_general。MySQL提供了多種對字元資料的儲存型別，包括：CHAR、VARCHAR、VARBINARY、BLOB、TEXT、ENUM和SET等多種字元型別。
（1）CHAR是儲存定長字串，而VARCHAR則是儲存變長字串。CHAR(5)表示必須儲存5個字元，而VARCHAR(5)則表示最大儲存字元為5。如果是UTF8編碼下，長度為5的CHAR型別，最多可以儲存15位元組，也就是5個漢字的內容。因為一個漢字佔3個位元組。
由於CHAR型別是定長，MySQL會根據定義的長度進行分配空間，在處理速度上比VARCHAR快的多，所以適合儲存例如手機、身份證這種定長的字元，否則就會造成浪費。那麼CHAR型別最大可以插入255個字元，最多可以儲存765個位元組。
（2）BINARY和VARBINARY是採用二進位制儲存的，沒有字符集概念，意義在於防止字符集的問題導致資料丟失，儲存中文會佔用兩個字元，會亂碼，半截會問號。因為是採用二進位制儲存，在比較字元和排序的時候，都是二進位制進行的，所以只有需要操作二進位制時才需要使用。
（3）八種適合文字內容的大資料型別：TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT、TINYBLOG、BLOB、MEDIUMTEXT、LONGTEXT。
綜上：短文字定長用char，變長用varchar，長文字用text
4.列型別之屬性
無符號(UNSIGNED)和填充零(ZEROFILL)，還有是否為空、預設值、主鍵、自動編號。
嚴格模式
我們使用的是WAMP整合環境，預設安裝的情況下，是非嚴格模式，用於部署階段。而開發除錯階段，強烈建議使用嚴格模式，方便開發中除錯將問題及時暴露出來。因為在非嚴格模式下將NULL插入NOTNULL等非法操作都是被執行的。設定嚴格模式只要開啟my.ini檔案，在末尾新增一句：
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
然後，重啟伺服器即可。檢查SQL_MODE狀態
SELECT @@global.sql_mode;
三、正規化與逆正規化
為了建立冗餘較小、結構合理的資料庫，設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。正規化是符合某一種設計要求的總結。要想設計一個結構合理的關係型資料庫，必須滿足一定的正規化。
第一正規化1NF，原子性
第二正規化2NF，消除部分依賴
第三正規化3NF，消除傳遞依賴
1、正規化
（1）第一正規化：具有原子性，確保每列保持原子性。
第一正規化是最基本的正規化。如果資料庫表中的所有欄位值都是不可分解的原子值，就說明該資料庫表滿足了第一正規化。第一正規化的合理遵循需要根據系統的實際需求來定。比如某些資料庫系統中需要用到“地址”這個屬性本來直接將“地址”屬性設計成一個數據庫表的欄位就行。但是如果系統經常會訪問“地址”屬性中的“城市”部分，那麼就非要將“地址”這個屬性重新拆分為省份、城市、詳細地址等多個部分進行儲存，這樣在對地址中某一部分操作的時候將非常方便。這樣設計才算滿足了資料庫的第一正規化。
（2）第二正規化：主鍵列與非主鍵列遵循完全函式依賴關係，確保表中的每列都和主鍵相關。
第二正規化在第一正規化的基礎之上更進一層。第二正規化需要確保資料庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。也就是說在一個數據庫表中，一個表中只能儲存一種資料，不可以把多種資料儲存在同一張資料庫表中。
（3）第三正規化：非主鍵列之間沒有傳遞函式依賴關係索引，確保每列都和主鍵列直接相關,而不是間接相關。
所謂傳遞函式依賴，指的是如果存在"A→B→C"的決定關係，則C傳遞函式依賴於A。因此，滿足第三正規化的資料庫表應該不存在如下依賴關係：
關鍵欄位→非關鍵欄位x→非關鍵欄位y
比如在設計一個訂單資料表的時候，可以將客戶編號作為一個外來鍵和訂單表建立相應的關係。而不可以在訂單表中新增關於客戶其它資訊（比如姓名、所屬公司等）的欄位。
先滿足第一正規化，再滿足第二正規化，才能滿足第三正規化。
2、逆正規化
逆正規化是指打破正規化，通過增加冗餘或重複的資料來提高資料庫的效能。
示例： 假如有一個商品表Goods：
欄位有Goods_id(商品表), goods_name(商品名稱), cat_id(所屬類別的id)。
還有一個分類表Category：
欄位有Cat_id(類別id), cat_name(類別名稱)。
現在要查詢類別id為3的商品的數量，例如分類列表查詢：
分類ID 分類名稱 商品數量
3 計算機 567
可以使用下列sql語句：
Select c.*, count(g.goods_id) as goods_count from category as c left join goods as g c.cat_id=g.cat_id group by c.cat_id;
但是，假如商品數量較大，那麼就比較耗效能了。這時，我們可以考慮重新設計Category表：增加存當前分類下商品數量的欄位。
Cat_id, cat_name, goods_count
每當商品改動時，修改對應分類的數量資訊。
再查詢分類列表時：Select * from category;
此時額外的消耗，出現在維護該欄位的正確性上，保證商品的任何更新都正確的處理該數量才可以。
四、索引
1．索引概述
利用關鍵字，就是記錄的部分資料（某個欄位，某些欄位，某個欄位的一部分），建立與記錄位置的對應關係，就是索引。索引的關鍵字一定是排序的。索引本質上是表字段的有序子集，它是提高查詢速度最有效的方法。一個沒有建立任何索引的表，就相當於一本沒有目錄的書，在每次查詢時就會進行全表掃描，這樣會導致查詢效率極低、速度也極慢。如果建立索引，那麼就好比一本新增的目錄，通過目錄的指引，迅速翻閱到指定的章節，提升的查詢效能，節約了查詢資源。
測試查詢，新增索引前後比對執行時間：
2．索引種類
從索引的定義方式和用途中來看：主鍵索引，唯一索引，普通索引，全文索引。
無論任何型別，都是通過建立關鍵字與位置的對應關係來實現的。索引是通過關鍵字找對應的記錄的地址。
以上型別的差異：對索引關鍵字的要求不同。
關鍵字：記錄的部分資料（某個欄位，某些欄位，某個欄位的一部分）。
普通索引,index：對關鍵字沒有要求。
唯一索引,unique index：要求關鍵字不能重複。同時增加唯一約束。
主鍵索引,primary key：要求關鍵字不能重複，也不能為NULL。同時增加主鍵約束。
全文索引,fulltext key：關鍵字的來源不是所有欄位的資料，而是從欄位中提取的特別關鍵詞。
關鍵字含義：可以是某個欄位，也可以是某些欄位。如果一個索引通過在多個欄位上提取的關鍵字，稱之為複合索引。 命令:alter table exp add index (field1, field2);
PS：這裡主鍵索引和唯一索引的區別在於：主鍵索引不能為空值，唯一索引允許空值；主鍵索引在一張表內只能建立一個，唯一索引可以建立多個。主鍵索引肯定是唯一索引，但唯一索引不一定是主鍵索引。
3.索引操作
(1)建立主鍵索引
建立一個無符號整型且自動增長的列，然後設定成主鍵即可。
//通過EXPLAIN語句檢視索引狀態
EXPLAIN SELECT * FROM think_user WHERE id=1;
(2)建立普通或唯一索引
直接進入navicat設計表的第二欄，選擇一個欄位(比如user欄位)，新增一個Nomral(普通索引)或Unique(唯一索引)。
//通過EXPLAIN語句檢視索引狀態
EXPLAIN SELECT * FROM think_user WHERE user='蠟筆老新';
//查看錶所有索引情況
SHOW INDEX FROM think_user;
（3）使用sql語句的方式建立索引----建表時就建立索引
注意：索引可以起名字，但是主鍵索引不能起名字，因為一個表僅僅可以有一個主索引，其他索引可以出現多個。名字可以省略，mysql會預設生成，通常使用欄位名來充當。
（4）使用sql語句的方式建立索引----更新表時建立索引
注意：如果表中存在資料，資料符合唯一或主鍵的約束才可能建立成功。auto_increment屬性，依賴於一個KEY。
（5）使用sql語句的方式刪除索引，auto_increment依賴於KEY。
（6）Explain 執行計劃
可以通過在select語句前使用 explain，來獲取該查詢語句的執行計劃，而不是真正執行該語句。
刪除索引時，再看執行計劃：
從查詢的行數可知，有索引時查詢會快的多，因為它只需要查詢一行，而沒有索引時，會造成全表掃描。
注意：select語句才能獲取到執行計劃。（新版本5.6會擴充套件其他語句的執行計劃的獲取）
4.索引原則
如果索引不遵循使用原則，則可能導致索引無效。
（1）列獨立
如果需要某個欄位上使用索引，則需要在欄位參與的表達中，保證欄位獨立在一側。
第三個語句 empno-1就不是列獨立：就不能用索引。類似函式等等。（write_time < unix_timestamp()-$gc_maxlifetime）
其他兩個列獨立可以使用：
（2）左原則
Like：匹配模式必須要左邊確定不能以萬用字元開頭。
假如業務邏輯上出現: field like ‘%keywork%’;類似查詢，需要使用全文索引。
複合索引：一個索引關聯多個欄位，僅僅針對左邊欄位有效果。
示例：新增複合索引
對Ename的查詢，使用了索引，結果如下：
Empno的查詢沒有使用索引，結果如下：
（3）OR的使用
必須要保證 OR 兩端的條件都存在可以用的索引，該查詢才可以使用索引。
為後面的條件增加可以使用的索引後，再檢視執行計劃：
（4）MySQL智慧選擇
即使滿足了上面說原則，MySQL也能棄用索引：如下圖
棄用索引的主要原因：
查詢即使使用索引，會導致出現大量的隨機IO，相對於從資料記錄的第一條遍歷到最後一條的順序IO開銷，還要大。
綜上歸納：
a、不要過度索引。索引越多，佔用空間越大，反而效能變慢；
b.只對WHERE子句中頻繁使用的建立索引；
c.儘可能使用唯一索引，重複值越少，索引效果越強；
d.使用短索引，如果char(255)太大，應該給它指定一個字首長度，大部分情況下前10位或20位值基本是唯一的，那麼就不要對整個列進行索引；
e.充分利用左字首，這是針對複合索引，因為WHERE語句如果有AND並列，只能識別一個索引(獲取記錄最少的那個)，索引需要使用複合索引，那麼應該將WHERE最頻繁的放置在左邊。
f.索引存在，如果沒有滿足使用原則，也會導致索引無效：
5.索引的使用場景
（1）索引檢索：檢索資料時使用索引。
（2）索引排序
如果order by 排序需要的欄位上存在索引，則可能使用到索引。
例如，按照ename欄位排序查詢：
此時，沒有任何索引。在ename欄位上建立索引後：
不會用到查詢檢索索引是因為沒有用where條件查詢，而真實執行時，就會用到排序索引。
Tip：對比以上兩個執行計劃：
extra位置：
其中：extra額外資訊。加了索引後就不用使用檔案排序了。
Using filesort，表示使用檔案排序（外部排序，記憶體外部）。
（3）索引覆蓋
索引擁有的關鍵字內容，覆蓋了查詢所需要的全部資料，此時，就不需要在資料區獲取資料，僅僅在索引區即可。覆蓋就是直接在索引區獲取內容，而不需要在資料區獲取。
例如，利用名字檢索：
可以在ename欄位建立索引：
分析執行：
再增加一個索引：
完成相同的查詢：
查詢的欄位剛好是複合索引包含的欄位。所以就使用了複合索引。
說明，不是非要查詢用到，才可以索引覆蓋，只要滿足要求都可以覆蓋！
建立索引索引時，不要僅僅考慮where檢索，同時考慮其他的使用場景。（在所有的where欄位上增加索引，就是不合理的）
6.字首索引
字首索引是建立索引關鍵字一種方案。通常會使用欄位的整體作為索引關鍵字。有時，即使使用欄位前部分資料，也可以去識別某些記錄。就比如一個班級裡，我要找王xx，假如姓王的只有1個人，那麼就可以建一個字首索引，就是王。
語法：
Index `index_name` (`index_field`(N))使用index_name前N個字元建立的索引。
那麼N究竟是多少？使用N長度所達到的辨識度，極限接近於使用全部長度的辨識度即可！
先計算最大的辨識度M：
公式：先計算總的記錄數m，再求該欄位不重複的記錄數q，那麼M=m/q。然後依次取得前N個字元，N逐步增加，進行對比，直到找到極限接近於M的，那麼最後的N就是我們要找的N。
求得辨識度為1.4774.，也就是說一個字首索引可以對應1.4774條記錄。
然後依次取得前N個字元，進行對比，找到極限接近的：
可見，9 時，已經極限接近，提高長度，不能明顯提升辨識度，因此可以使用前9個字元：
Tip：字首索引不能用於索引覆蓋！
7.全文索引
該型別的索引特殊在：關鍵字的建立上。是為了解決 like‘%keyword%’這類查詢的匹配問題。（mysql的全文索引幾乎不用，因為它不支援中文，我們應該使用sphinx全文索引）。
示例：
假如有一張表，表中有標題和內容兩個欄位，現在要查詢標題或者內容包含 “database” 關鍵字的記錄。
補充：text和varchar的區別是text的資料不存在記錄裡，一條記錄的最大空間是65535.
形成的SQL如下：
Select * from articles where title like ‘%database%’ or body like ‘%database%’;
此時不能建立普通索引，查詢不符合左原則，建立了也使用不了。
此時全文索引就可以發揮其作用了：
直接使用上面的SQL，需要使用特殊的全文索引匹配語法才可以生效： Match() against();
Tip: 該MYSQL提供的全文索引，不能對中文起作用！
使用Match() against() 返回關鍵字的匹配度（關鍵字與記錄的關聯程度）。
停止詞 in：
發現in這個詞，是不能被全文索引所檢索到的。因為in這個詞是不可以用在全文索引的關鍵詞裡的，沒有誰會在一段文本里檢索這樣一個詞。
思考：與 like %in% 是否相同？不同。
原因何在呢？全文索引，索引的的關鍵字，不是整個欄位資料，而是從資料中提取的關鍵詞。
8.索引結構-b-tree介紹
Hash、B-Tree（B樹）兩種資料結構。指的是mysql儲存索引所採用的資料結構。其中，使用者所維護的所有的索引結構 B-Tree結構。
B-Tree的結構如下：
每個節點，儲存多個關鍵字。關鍵字也會對應記錄地址
以上設計為了解決一次性磁碟IO開銷，可以讀取到更多的關鍵字數量。
每個關鍵字之間，存在子節點指標：
如果是複合索引：
關鍵字的排序先排左側欄位，在左側欄位相同的情況下，再排序右側欄位：
9.聚集索引(聚簇索引)
B+Tree(B-Tree的變種)
在innodb的儲存引擎上，主鍵索引是與資料記錄儲存在一起的（聚簇在一起的）。
帶來的問題：
Innodb的其他索引，非主鍵索引（二級索引）：
關鍵字對應的不再是記錄的地址，而是記錄的主鍵。
可見，檢索需要二次檢索。先檢索到主鍵ID，再檢索記錄。
五、查詢快取query_cache
將select的結果，存取起來共二次使用的快取區域：
MySQL提供的快取區：
未開啟前：
兩次查詢時間消耗一致。
開啟查詢快取，通過變數控制：
開啟並設定大小：
再次執行查詢：
可見，第二次查詢，使用了開啟的快取！
注意事項：查詢快取存在判斷是嚴格依賴於select語句本身的：嚴格保證SQL一致。
如果查詢時包含動態資料，則不能被快取。
一旦開啟查詢快取，MySQL會將所有可以被快取的select語句都快取。如果存在不想使用快取的SQL執行，則可以使用 SQL_NO_CACHE語法提示達到目的：
注意：這裡的快取僅當資料表的記錄改變時，快取才會被刪除。而不是依靠過期時間的。
六、分割槽分表
日常開發中我們經常會遇到大表的情況，所謂的大表是指儲存了百萬級乃至千萬級條記錄的表。這樣的表過於龐大，導致資料庫在查詢和插入的時候耗時太長，效能低下，如果涉及聯合查詢的情況，效能會更加糟糕。分表和表分割槽的目的就是減少資料庫的負擔，提高資料庫的效率，通常點來講就是提高表的增刪改查效率。
分割槽，partition，分割槽是將資料分段劃分在多個位置存放，可以是同一塊磁碟也可以在不同的機器。分割槽後，表面上還是一張表，但資料雜湊到多個位置了。app讀寫的時候操作的還是大表名字，db自動去組織分割槽的資料。
其實每個分割槽，就是獨立的表。都要儲存該分割槽資料的資料，索引等資訊。
建立分割槽：在建立表時，指定分割槽的選項：
Create table table_name (定義)
Partition by 分割槽演算法 (引數) 分割槽選項。
例如：Partition by key (id) partitions 5;
採用key取餘演算法，根據id的值進行取餘，即對5取餘，然後分配到5個區裡。
分割槽結果如下：myisam下
Innodb下
Tip：分割槽與儲存引擎無關，是MySQL邏輯層完成的。
可以通過變數檢視當前mysql是否支援分割槽：
1.分割槽演算法
MySQL提供4種分割槽演算法：取餘：Key，hash 條件：List，range 。
參與分割槽的引數欄位需要為主鍵的一部分。
（1）KEY – 取餘 ，按照某個欄位進行取餘
分成5個區，就是對5取餘。將id對5取餘。
（2）Hash – 取餘，按照某個表示式的值進行取餘
示例：學生表分割槽，按照生日的月份，劃分到12個表中。
注意：Key，hash都是取餘演算法，要求分割槽引數（括號裡的），返回的資料必須為整數。
（3）List – 條件 – 列表，需要指定的每個分割槽資料的儲存條件。
示例：按照生日中的月份，分成春夏秋冬四個分割槽。
List，條件依賴的資料是列表形式。
（4）Range - 條件 – 範圍， 條件依賴的資料是一個條件表示式。
邏輯：按照生日的年份分成不同的年齡段。
2.分割槽的管理與選擇
（1）取餘：key，hash
增加分割槽數量： add partition partitions N
減少分割槽數量： COALESCE partition N
採用取餘演算法的分割槽數量的修改，不會導致已有分割槽資料的丟失，因為會重新分配資料到新的分割槽。
（2）條件：list，range
新增分割槽
刪除分割槽：
Drop partition partition_name;
注意：刪除條件演算法的分割槽，會導致分割槽資料丟失。新增分割槽不會。
（3）選擇分割槽演算法
平均分配：就按照主鍵進行key(primary key)即可(非常常見)
按照某種業務邏輯分割槽：選擇那種最容易被篩選的欄位，整數型
3.分表
分表是將一個大表按照一定的規則分解成多張具有獨立儲存空間的實體表，我們可以稱為子表，每個表都對應三個檔案，MYD資料檔案，.MYI索引檔案，.frm表結構檔案。這些子表可以分佈在同一塊磁碟上，也可以在不同的機器上。app讀寫的時候根據事先定義好的規則得到對應的子表名，然後去操作它。分表技術是比較麻煩的，需要手動去建立子表，app服務端讀寫時候需要計運算元表名。採用merge好一些，但也要建立子表和配置子表間的union關係。（需要手動分表）
分表是分割槽之前用的，MYSQL5.1後，就開始用分割槽代替分表了。分表很少用了。
（1）水平分表
建立結構相同的N個表；
再建立用於管理學生ID的表student_id：(該表是為了提供自增的ID)
PHP客戶端邏輯：
Merge，mrg_myisam
是MySQL提供一個可以將多個結構相同的myisam表，合併到一起的儲存引擎：
（2）垂直分表
一張表中存在多個欄位。這些欄位可以分為常用欄位和非常用欄位，為了提高查錶速度，我們可以把這兩類欄位分開來儲存。主要目的，減少每條記錄的長度。
通常我們按以下原則進行垂直拆分:把不常用的欄位單獨放在一張表;把text，blog等大欄位拆分出來放在附表中;經常組合查詢的列放在一張表中;
例如學生表可以分成：
基礎表(Student_base)和額外表(Student_extra)，兩張表中記錄為1:1的關係。
基礎資訊表Student_base
Id name age
額外資訊表Student_extra
Id 籍貫 政治面貌
七、伺服器架構介紹
伺服器架構，不僅僅是用一臺MySQL
主從複製：
Mysql伺服器內部支援複製功能，僅僅需要通過配置完成下面的拓撲結構。一主多從典型結果：主伺服器負責寫資料。從伺服器負責讀資料。複製功能mysql會自帶。
讀寫分離，負載均衡：
php不再操作MYSQL資料庫伺服器，而是去操作讀寫分離、負載均衡伺服器，只要伺服器安裝了mysql proxy或Ameoba軟體就可以實現讀寫分離和負載均衡，讀寫分離是指該伺服器會判斷客戶端的操作是讀還是寫，從而選擇操作mysql主伺服器還是從伺服器。負載均衡演算法是指，客戶端讀操作時，該伺服器會根據取餘演算法去選擇一臺從伺服器。
上面的架構可以提升整體伺服器的效率，高效能。
同時，伺服器架構需要保證，高可用（穩定），7x24不宕機。因此需要增加一些冗餘伺服器以便備用。時時檢測正在用的伺服器。
八、SQL優化
1.對於併發性的SQL
少用（不用）多表操作（子查詢，聯合查詢），而是將複雜的SQL拆分多次執行。如果查詢很原子（很小），會增加查詢快取的利用率。
2.大量資料的插入
多條 insert或者Load data into table（從檔案裡載入資料到表裡）
建議，先關閉約束及索引，完成資料插入，再重新生成索引及約束。
針對於myisam，步驟：
Alter table table_name disable keys; 禁用索引約束
大量的插入
Alter table table_name enable keys; 啟用
針對innodb，步驟：
Drop index, drop constraint 刪除索引及約束，要保留主鍵
Begin transaction|set autocommit=0; 開啟事務，不讓他自動提交
[資料本身已經按照主鍵值排序]
大量的插入
Commit;
Add index, add constraint
3.分頁
分頁假定Limit offset, size; size = 10;
|
Page |
offset |
|
5 |
40, 10 |
|
50 |
490, 10 |
|
5000 |
4990, 10 |
|
500000 |
499990, 10 |
Limit 的使用，會大大提升無效資料的檢索（被跳過），因為是先檢索，檢索會檢索全部，再取得想要的。好的做法是使用條件等過濾方式，將檢索到的資料儘可能精確定位到需要的資料上。
4.隨機選一些資料，不要使用Order by Rand()
上面的查詢，會導致每條記錄都執行rand()，成本很高！
建議，通過mt_rand()，先確定的隨機主鍵，再從資料表中獲取資料。
九、慢查詢日誌的使用
定位執行較慢的查詢語句方案。
show variables like 'slow_query%'; show variables like '%long_query%';
Slow_query_log = 0|1
Long_query_time = N 超過該時間臨界點，就為慢查詢。
開啟日誌
set global slow_query_log=1; set long_query_time=0.5；
執行SQL，檢視：
mysql資料庫匯入匯出
window下
1.匯出整個資料庫
mysqldump -u 使用者名稱 -p 資料庫名 > 匯出的檔名
mysqldump -u dbuser -p dbname > dbname.sql
2.匯出一個表
mysqldump -u 使用者名稱 -p 資料庫名 表名> 匯出的檔名
mysqldump -u dbuser -p dbname users> dbname_users.sql
3.匯出一個數據庫結構
mysqldump -u dbuser -p -d --add-drop-table dbname> d:/dbname_db.sql
-d 沒有資料 --add-drop-table 在每個create語句之前增加一個drop table
4.匯入資料庫
常用source 命令
進入mysql資料庫控制檯，如
mysql -u root -p
mysql>use 資料庫
然後使用source命令，後面引數為指令碼檔案(如這裡用到的.sql)
mysql>source d:/dbname.sql
1. 匯入資料到資料庫
mysql -uroot -D資料庫名
1. 匯入資料到資料庫中得某個表
mysql -uroot -D資料庫名 表名
D:\APMServ5.2.6\MySQL5.1\bin>mysqldump -u root -p erp lightinthebox_tags > ligh
tinthebox.sql
linux下
一、匯出資料庫用mysqldump命令（注意mysql的安裝路徑，即此命令的路徑）：
1、匯出資料和表結構：
mysqldump -u使用者名稱 -p密碼 資料庫名 > 資料庫名.sql
#/usr/local/mysql/bin/ mysqldump -uroot -p abc > abc.sql
敲回車後會提示輸入密碼
2、只匯出表結構
mysqldump -u使用者名稱 -p密碼 -d 資料庫名 > 資料庫名.sql
#/usr/local/mysql/bin/ mysqldump -uroot -p -d abc > abc.sql
注：/usr/local/mysql/bin/ ---> mysql的data目錄
二、匯入資料庫
1、首先建空資料庫
mysql>create database abc;
2、匯入資料庫
方法一：
（1）選擇資料庫
mysql>use abc;
（2）設定資料庫編碼
mysql>set names utf8;
（3）匯入資料（注意sql檔案的路徑）
mysql>source /home/abc/abc.sql;
方法二：
mysql -u使用者名稱 -p密碼 資料庫名 < 資料庫名.sql
#mysql -uabc_f -p abc < abc.sql
\
MYSQL資料庫的匯出和匯入
一、連線伺服器檢視資料庫
使用連線工具（xshell6等）連線到資料庫所在伺服器，執行命令查詢需要匯出的資料庫
1.輸入資料庫管理員賬號密碼進入控制檯：mysql -uroot -p123456 #root為管理員賬號，123456為密碼
2.執行命令：show databases; 查詢資料庫
二、匯出
1 使用MySQL自帶的mysqldump的命令進行匯出：mysqldump -uroot -p123456 -R -E gd_base >/u01/gd_base.sql
匯出多個數據庫：
2 執行匯出命令後，在伺服器對應目錄下可找到匯出的sql檔案
3 匯出命令詳解
MySQL使用MySQL自帶的mysqldump的命令進行匯出時，可進行全庫匯出和單個數據庫匯出。相關命令解析如下： 全庫匯出：mysqldump -u使用者名稱 -p密碼 -R -E 資料庫1 資料庫2... > 儲存路徑/檔名.sql 單個數據庫匯出：mysqldump -u使用者名稱 -p密碼 -R -E 資料庫 > 儲存路徑/檔名.sql
（紅色字型替換成對應的資料庫資訊；使用者名稱：一般指“root”；密碼：使用者名稱對應的密碼，資料庫：需要匯出的資料庫名稱，多資料庫則用空格隔開；儲存路徑/檔名：匯出的路徑和生成的檔名；-R -E：匯出所有(結構&資料&儲存過程&函式&事件&觸發器)）
三、匯入
1 將匯出的sql檔案複製到本地資料庫的安裝目錄的data資料夾下
2.在cmd視窗中，切換到MYSQL資料庫的安裝路徑。輸入本地MYSQL資料庫的賬號密碼進入控制檯：mysql -uroot -pminstone
3.建立資料庫： create database gd_base;
4.執行匯入命令： mysql -uroot -pminstone gd_base <gd_base.sql
（匯入多個數據庫）當匯出的sql檔案為多個數據庫檔案時，匯入時不需指明資料庫，直接匯入sql檔案即可：
(備註：如果匯入的目標資料庫已存在對應資料庫，無需刪除再建立，可直接匯入進行資料覆蓋；匯出的檔案可複製到任務路徑下，匯入時指定路徑即可，如mysql -uroot -pminstone gd_base </home/gd_base.sql)
5.執行完匯入命令後，使用navicat連線mysql，可看到資料庫已成功匯入。