MySQL優化十大技巧

時間 2019-11-11

標籤 mysql 優化十大技巧欄目 MySQL 简体版

原文原文鏈接

轉自：https://m.2cto.com/database/201701/557910.htmlphp

MYSQL優化主要分爲如下四大方面：html

設計：存儲引擎，字段類型，範式與逆範式mysql

功能：索引，緩存，分區分表。web

架構：主從複製，讀寫分離，負載均衡。算法

合理SQL：測試，經驗。sql

1、存儲引擎數據庫

在建立表的時候咱們使用sql語句，Create table tableName () engine=myisam|innodb;緩存

這裏就指明瞭存儲引擎是myisam仍是innodb。存儲引擎是一種用來存儲MySQL中對象（記錄和索引）的一種特定的結構（文件結構），處於MySQL服務器的最底層，直接存儲數據。致使上層的操做，依賴於存儲引擎的選擇。地位以下圖：安全

網絡接口層：與客戶端通訊，好比傳輸數據等等。存儲引擎層：存儲數據的規則，方式。服務器

本質：存儲引擎就是特定的數據存儲格式（方案）。

可使用show engines命令來查看當前MySQL支持的存儲引擎列表。

一、InnoDB存儲引擎介紹

Mysql版本>=5.5 默認的存儲引擎，MySQL推薦使用的存儲引擎。支持事務，行級鎖定，外鍵約束。事務安全型存儲引擎。更加註重數據的完整性和安全性。

（1）存儲格式

數據，索引集中存儲，存儲於同一個表空間文件中。

數據：記錄行。索引：一種檢索機制，也須要必定的空間，就至關於一本字典的目錄。

示例：建立一個test數據庫，新建一張student表，選擇存儲引擎爲innodb, 而後打開mysql的data下的test目錄，發現有如下3個文件。

其中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。特徵是阻塞其餘客戶端的讀，寫操做。

鎖定粒度（範圍）：

行級：提高併發性，鎖自己開銷大

表級：不利於併發性，鎖自己開銷小。

2、字段類型選擇

字段類型應該要知足需求，儘可能要知足如下需求。

儘量小（佔用存儲空間少）、儘量定長（佔用存儲空間固定）、儘量使用整數。

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;

3、範式與逆範式

爲了創建冗餘較小、結構合理的數據庫，設計數據庫時必須遵循必定的規則。在關係型數據庫中這種規則就稱爲範式。範式是符合某一種設計要求的總結。要想設計一個結構合理的關係型數據庫，必須知足必定的範式。

第一範式1NF，原子性

第二範式2NF，消除部分依賴

第三範式3NF，消除傳遞依賴

一、範式

（1）第一範式：具備原子性，確保每列保持原子性。

第一範式是最基本的範式。若是數據庫表中的全部字段值都是不可分解的原子值，就說明該數據庫表知足了第一範式。第一範式的合理遵循須要根據系統的實際需求來定。好比某些數據庫系統中須要用到「地址」這個屬性原本直接將「地址」屬性設計成一個數據庫表的字段就行。可是若是系統常常會訪問「地址」屬性中的「城市」部分，那麼就非要將「地址」這個屬性從新拆分爲省份、城市、詳細地址等多個部分進行存儲，這樣在對地址中某一部分操做的時候將很是方便。這樣設計纔算知足了數據庫的第一範式。
（2）第二範式：主鍵列與非主鍵列遵循徹底函數依賴關係，確保表中的每列都和主鍵相關。

第二範式在第一範式的基礎之上更進一層。第二範式須要確保數據庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。也就是說在一個數據庫表中，一個表中只能保存一種數據，不能夠把多種數據保存在同一張數據庫表中。
（3）第三範式：非主鍵列之間沒有傳遞函數依賴關係索引，確保每列都和主鍵列直接相關,而不是間接相關。

所謂傳遞函數依賴，指的是若是存在"A→B→C"的決定關係，則C傳遞函數依賴於A。所以，知足第三範式的數據庫表應該不存在以下依賴關係：

關鍵字段→非關鍵字段x→非關鍵字段y

好比在設計一個訂單數據表的時候，能夠將客戶編號做爲一個外鍵和訂單表創建相應的關係。而不能夠在訂單表中添加關於客戶其它信息（好比姓名、所屬公司等）的字段。

先知足第一範式，再知足第二範式，才能知足第三範式。

二、逆範式

逆範式是指打破範式，經過增長冗餘或重複的數據來提升數據庫的性能。

示例：假若有一個商品表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;

此時額外的消耗，出如今維護該字段的正確性上，保證商品的任何更新都正確的處理該數量才能夠。

4、索引

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，再檢索記錄。

5、查詢緩存query_cache

將select的結果，存取起來共二次使用的緩存區域：

MySQL提供的緩存區：

未開啓前：

兩次查詢時間消耗一致。

開啓查詢緩存，經過變量控制：

開啓並設置大小：

再次執行查詢：

可見，第二次查詢，使用了開啓的緩存！

注意事項：查詢緩存存在判斷是嚴格依賴於select語句自己的：嚴格保證SQL一致。

若是查詢時包含動態數據，則不能被緩存。

一旦開啓查詢緩存，MySQL會將全部能夠被緩存的select語句都緩存。若是存在不想使用緩存的SQL執行，則可使用 SQL_NO_CACHE語法提示達到目的：

注意：這裏的緩存僅當數據表的記錄改變時，緩存纔會被刪除。而不是依靠過時時間的。

6、分區分表

平常開發中咱們常常會遇到大表的狀況，所謂的大表是指存儲了百萬級乃至千萬級條記錄的表。這樣的表過於龐大，致使數據庫在查詢和插入的時候耗時太長，性能低下，若是涉及聯合查詢的狀況，性能會更加糟糕。分表和表分區的目的就是減小數據庫的負擔，提升數據庫的效率，一般點來說就是提升表的增刪改查效率。

分區，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 籍貫政治面貌

7、服務器架構介紹

服務器架構，不只僅是用一臺MySQL

主從複製：

Mysql服務器內部支持複製功能，僅僅須要經過配置完成下面的拓撲結構。一主多從典型結果：主服務器負責寫數據。從服務器負責讀數據。複製功能mysql會自帶。

讀寫分離，負載均衡：

php再也不操做MYSQL數據庫服務器，而是去操做讀寫分離、負載均衡服務器，只要服務器安裝了mysql proxy或Ameoba軟件就能夠實現讀寫分離和負載均衡，讀寫分離是指該服務器會判斷客戶端的操做是讀仍是寫，從而選擇操做mysql主服務器仍是從服務器。負載均衡算法是指，客戶端讀操做時，該服務器會根據取餘算法去選擇一臺從服務器。

上面的架構能夠提高總體服務器的效率，高性能。

同時，服務器架構須要保證，高可用（穩定），7x24不宕機。所以須要增長一些冗餘服務器以便備用。時時檢測正在用的服務器。

8、SQL優化

1.對於併發性的SQL

少用（不用）多表操做（子查詢，聯合查詢），而是將複雜的SQL拆分屢次執行。若是查詢很原子（很小），會增長查詢緩存的利用率。

2.大量數據的插入

多條 insert或者Load data into table（從文件裏載入數據到表裏）

建議，先關閉約束及索引，完成數據插入，再從新生成索引及約束。

針對於myisam，步驟：

Alter table table_name disable keys; 禁用索引約束

大量的插入

Alter table table_name enable keys; 啓用