MySQL中索引和優化的用法總結

一、什麼是數據庫中的索引？索引有什麼做用？

　　引入索引的目的是爲了加快查詢速度。若是數據量很大，大的查詢要從硬盤加載數據到內存當中。

二、InnoDB中的索引原理是怎麼樣的？

　　InnoDB是Mysql的默認存儲引擎,InnoDB有兩種索引：B+樹索引和哈希索引，其中哈希索引是自適應性的，存儲引擎會根據表的使用狀況，自動建立哈希索引，不能人爲的干涉。

　　B樹、B-樹、B+樹、B*樹四種數據結構在索引中的運用，這四種數據結構的順序必須是這樣的。分別闡述以下：

B樹：二叉樹，每一個結點只存儲一個關鍵字，等於則命中，小於走左結點，大於走右結點；

B-樹：多路搜索樹，每一個結點存儲M/2到M個關鍵字，非葉子結點存儲指向關鍵字範圍的子結點；全部關鍵字在整顆樹中出現，且只出現一次，非葉子結點能夠命中；

B+樹：在B-樹基礎上，爲葉子結點增長鏈表指針，全部關鍵字都在葉子結點中出現，非葉子結點做爲葉子結點的索引；B+樹老是到葉子結點才命中；

B*樹：在B+樹基礎上，爲非葉子結點也增長鏈表指針，將結點的最低利用率從1/2提升到2/3；

　　首先，B樹也叫做二叉搜索樹，字如其義。B樹有以下三個特色：全部非葉子節點至多擁有兩個兒子；全部節點存儲一個關鍵字；非葉子節點的左指針指向小於其關鍵字的子樹，右指針指向大於其關鍵字的子樹。

　　B樹的搜索，從根結點開始，若是查詢的關鍵字與結點的關鍵字相等，那麼就命中，不然，若是查詢關鍵字比結點關鍵字小，就進入左兒子；若是比結點關鍵字大，就進入右兒子；若是左兒子或右兒子的指針爲空，則報告找不到相應的關鍵字。若是B樹的全部非葉子結點的左右子樹的結點數目均保持差很少（平衡），那麼B樹的搜索性能逼近二分查找；但它比連續內存空間的二分查找的優勢是，改變B樹結構（插入與刪除結點）不須要移動大段的內存數據，甚至一般是常數開銷。最右邊也是一個B樹，但它的搜索性能已是線性的了；一樣的關鍵字集合有可能致使不一樣的樹結構索引；因此，使用B樹還要考慮儘量讓B樹保持左圖的結構，和避免右圖的結構，也就是所謂的「平衡」問題；實際使用的B樹都是在原B樹的基礎上加上平衡算法，即「平衡二叉樹」；如何保持B樹結點分佈均勻的平衡算法是平衡二叉樹的關鍵；平衡算法是一種在B樹中插入和刪除結點的策略；

　　其次，B-樹。數據量越大，B樹的高度會越高，之因此會越高，主要是由於二叉引發的。因此在此基礎上咱們定義了B-樹的規範以下：B-樹不是二叉的，因此又叫做多路搜索樹。

B-樹是一種多路搜索樹（並非二叉的）：

1.定義任意非葉子結點最多隻有M個兒子；且M>2；
2.根結點的兒子數爲[2, M]；除根結點之外的非葉子結點的兒子數爲[M/2, M]；
3.每一個結點存放至少M/2-1（取上整）和至多M-1個關鍵字；（至少2個關鍵字）
4.非葉子結點的關鍵字個數=指向兒子的指針個數-1；
5.非葉子結點的關鍵字：K[1], K[2], …, K[M-1]；且K[i] < K[i+1]；
6.非葉子結點的指針：P[1], P[2], …, P[M]；其中P[1]指向關鍵字小於K[1]的子樹，P[M]指向關鍵字大於K[M-1]的子樹，其它P[i]指向關鍵字屬於(K[i-1], K[i])的子樹；
7.全部葉子結點位於同一層；如圖所示中（M=3）

B-樹的搜索，從根結點開始，對結點內的關鍵字（有序）序列進行二分查找，若是命中則結束，不然進入查詢關鍵字所屬範圍的兒子結點重複，直到所對應的兒子指針爲空，或已是葉子結點。

B-樹的特性：

       1.關鍵字集合分佈在整顆樹中；

       2.任何一個關鍵字出現且只出如今一個結點中；

       3.搜索有可能在非葉子結點結束；

       4.其搜索性能等價於在關鍵字全集內作一次二分查找；

       5.自動層次控制；

       因爲限制了除根結點之外的非葉子結點，至少含有M/2個兒子，確保告終點的至少利用率，其最底搜索性能如圖，
其中，M爲設定的非葉子結點最多子樹個數，N爲關鍵字總數；
因此B-樹的性能老是等價於二分查找（與M值無關），也就沒有B樹平衡的問題；因爲M/2的限制，在插入結點時，若是結點已滿，須要將結點分裂爲兩個各佔M/2的結點；刪除結點時，需將兩個不足M/2的兄弟結點合併；

　　其次，B+樹。B樹、B-樹、B+樹、B*樹。B樹是二叉搜索樹，B-樹、B+樹、B*樹都是多路搜索樹。B-樹定義了基本的規範，它有個特色，關鍵字出如今非葉子節點或者葉子節點，子樹的指針比關鍵字個數大一個。B+樹在這兩方面分別作了升級，定義以下：

 B+樹是B-樹的變體，也是一種多路搜索樹：

       1.其定義基本與B-樹同，除了：

       2.非葉子結點的子樹指針與關鍵字個數相同；

       3.非葉子結點的子樹指針P[i]，指向關鍵字值屬於[K[i], K[i+1])的子樹

（B-樹是開區間）；

       5.爲全部葉子結點增長一個鏈指針；

       6.全部關鍵字都在葉子結點出現；


B+的搜索與B-樹也基本相同，區別是B+樹只有達到葉子結點才命中（B-樹能夠在非葉子結點命中），其性能也等價於在關鍵字全集作一次二分查找；

B+的特性：

       1.全部關鍵字都出如今葉子結點的鏈表中（稠密索引），且鏈表中的關鍵字剛好是有序的；

       2.不可能在非葉子結點命中；

       3.非葉子結點至關因而葉子結點的索引（稀疏索引），葉子結點至關因而存儲（關鍵字）數據的數據層；

       4.更適合文件索引系統；

　　最後B*樹，它是B+樹的變體，在B+樹的非根和非葉子結點再增長指向兄弟的指針。

 

B*樹定義了非葉子結點關鍵字個數至少爲(2/3)*M，即塊的最低使用率爲2/3（代替B+樹的1/2）；

B+樹的分裂：當一個結點滿時，分配一個新的結點，並將原結點中1/2的數據複製到新結點，最後在父結點中增長新結點的指針；B+樹的分裂隻影響原結點和父結點，而不會影響兄弟結點，因此它不須要指向兄弟的指針；

B*樹的分裂：當一個結點滿時，若是它的下一個兄弟結點未滿，那麼將一部分數據移到兄弟結點中，再在原結點插入關鍵字，最後修改父結點中兄弟結點的關鍵字（由於兄弟結點的關鍵字範圍改變了）；
  若是兄弟也滿了，則在原結點與兄弟結點之間增長新結點，並各複製1/3的數據到新結點，最後在父結點增長新結點的指針；

因此，B*樹分配新結點的機率比B+樹要低，空間使用率更高；

三、如何在Navicat中對錶添加索引？

#刪除表
DROP TABLE test.idc_work_order_main

# 建立表結構idc_work_order_main
CREATE TABLE `idc_work_order_main` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵ID',
  `creator` varchar(128) NOT NULL DEFAULT '0' COMMENT '建立人',
  `gmt_create` timestamp NULL DEFAULT NULL COMMENT '建立時間',
  `modifier` varchar(128) DEFAULT '0' COMMENT '修改人',
  `gmt_modified` timestamp NULL DEFAULT NULL COMMENT '修改時間',
  `title` varchar(64) DEFAULT NULL COMMENT '工單標題',
  `category` varchar(32) DEFAULT NULL COMMENT '工單類別',
  `subject` varchar(32) DEFAULT NULL COMMENT '工單類型',
  `demander` varchar(30) DEFAULT NULL COMMENT '需求方',
  `is_atomic` char(1) DEFAULT 'y' COMMENT '是否原子工單',
  `atomic_id` int(11) DEFAULT NULL COMMENT '當前原子工單在列表中ID',
  `site` varchar(50) DEFAULT NULL COMMENT '工單所在機房',
  `operationer` varchar(32) DEFAULT NULL COMMENT '當前處理人',
  `operation_role` varchar(50) DEFAULT NULL COMMENT '當前處理角色',
  `state` varchar(50) DEFAULT NULL COMMENT '工單狀態',
  `sub_state` varchar(50) DEFAULT NULL COMMENT '工單子狀態',
  `expect_time` timestamp NULL DEFAULT NULL COMMENT '預期結單時間',
  `sla` bigint(20) DEFAULT NULL COMMENT 'sla',
  `evaluation` varchar(200) DEFAULT NULL COMMENT '評價',
  `create_source` varchar(32) DEFAULT 'TBOSS' COMMENT '建立源',
  `source_key` varchar(32) DEFAULT NULL COMMENT '建立源惟一標示',
  `is_deleted` char(1) DEFAULT 'n' COMMENT '是否已刪除y,n',
  `remark` varchar(500) DEFAULT NULL COMMENT '備註',
  `parent_id` int(11) DEFAULT '0' COMMENT '父工單ID',
  `asset_total` int(11) DEFAULT '0' COMMENT '設備總數',
  `sla_standard` double DEFAULT NULL COMMENT '標準時間',
  `sla_unit` char(1) DEFAULT NULL COMMENT 'sla 單位',
  `effective_date` timestamp NULL DEFAULT NULL COMMENT '提單時間（生效時間）',
  `is_timeout` char(1) DEFAULT 'n' COMMENT '是否超時，‘y’超時，‘n’未超時',
  `statement_date` timestamp NULL DEFAULT NULL COMMENT '結單的時間',
  `source_creator` varchar(32) DEFAULT NULL COMMENT '第三方建立人信息（域帳號）',
  `atomic_order_id` int(11) DEFAULT NULL COMMENT '當前原子工單編號',
  `order_device_type` varchar(50) DEFAULT 'SERVER' COMMENT '工單設備類型(server=服務器,network_serve等)',
  `finish_asset_total` int(11) DEFAULT '0' COMMENT '完成設備數',
  PRIMARY KEY (`id`),
  KEY `idx_statement_date` (`statement_date`),
  KEY `idx_parent_id` (`parent_id`),
  KEY `idx_gmt_modified` (`gmt_modified`),
  KEY `idx_gmt_create` (`gmt_create`)
) ENGINE=InnoDB AUTO_INCREMENT=182431 DEFAULT CHARSET=utf8 COMMENT='工單主表';

#顯示建表信息
SHOW CREATE TABLE idc_work_order_main

#添加索引
ALTER TABLE idc_work_order_main ADD INDEX atomic_order_id (atomic_order_id)
SHOW INDEX FROM idc_work_order_main
EXPLAIN SELECT * FROM idc_work_order_main WHERE atomic_order_id = '9956'

#添加主鍵 (惟一)
ALTER TABLE idc_work_order_main ADD PRIMARY KEY source_creator (source_creator)

#添加惟一索引
ALTER TABLE idc_work_order_main ADD UNIQUE source_creator (source_creator)
SHOW INDEX FROM idc_work_order_main

#添加聯合索引
ALTER TABLE idc_work_order_main ADD INDEX id_source_parent_create_atomic (id,source_creator,parent_id,gmt_create,atomic_order_id)
SHOW INDEX FROM idc_work_order_main

　　關於索引：

1.一本書光目錄就佔半本書，目錄（索引）還有意義嗎？索引過多必定狀況下會致使索引文件過大（指數增加），系統在尋址時查詢時間增加。
2.性別字段就男女兩個，加索引純浪費。一個索引會在 update 或 insert 時增長一次 I/O，對於操做系統底層來講是很是損耗性能的。

3.首先mysql是B+樹索引，這種做爲索引的好處是能夠對有序的記錄做logN級的查找，不過對於沒有大小之分的數據來講，仍是創建哈希索引更好，由於哈希索引的時間複雜度基本是log1的。(注意此處有序和無序的概念)。

4.索引的命名規則：表名_字段名，須要加索引的字段，要在where條件中，數據量少的字段不須要加索引，若是where條件中是OR關係，加索引不起做用，符合最左原則。

四、索引中的index和key的使用

　　key 是數據庫的物理結構，處於模型層面的，它包含兩層意義和做用，一是約束（偏重於約束和規範數據庫的結構完整性），二是索引（輔助查詢用的）。包括primary key, unique key, foreign key 等。

primary key 有兩個做用，一是約束做用（constraint），用來規範一個存儲主鍵和惟一性，但同時也在此key上創建了一個index；
unique key 也有兩個做用，一是約束做用（constraint），規範數據的惟一性，但同時也在這個key上創建了一個index；
foreign key也有兩個做用，一是約束做用（constraint），規範數據的引用完整性，但同時也在這個key上創建了一個index；

可見，mysql的key是同時具備constraint和index的意義，這點和其餘數據庫表現的可能有區別。index是數據庫的物理結構，處於實現層面的，它只是輔助查詢的，它建立時會在另外的表空間（mysql中的innodb表空間）以一個相似目錄的結構存儲。索引只是索引，它不會去約束索引的字段的行爲（那是key要作的事情）。Mysql常見索引有：主鍵索引、惟一索引、普通索引、全文索引、組合索引。

參考：

1.http://www.data.5helpyou.com/article392.html

2.關於where條件中or對索引影響：http://blog.csdn.net/hguisu/article/details/7106159