mysql之普通索引和唯一索引

常見的索引類型：哈希表、有序數組、搜索樹。

網站的建設創新互聯公司專注網站定制,經驗豐富,不做模板,主營網站定制開發.小程序定制開發,H5頁面制作!給你煥然一新的設計體驗!已為咖啡廳設計等企業提供專業服務。

mysql之普通索引和唯一索引。

執行查詢的語句是 select id from T where k=5

這個查詢語句在索引樹上查找的過程，先是通過 B+ 樹從樹根開始，按層搜索到葉子節點，也就是圖中右下角的這個數據頁，然后可以認為數據頁內部通過二分法來定位記錄。

InnoDB的索引組織結構：

change buffer:持久化的數據。InnoDB將更新操作緩存在 change buffer中,也就是說,change buffer 在內存中有拷貝，也會被寫入到磁盤，主要節省的則是隨機讀磁盤的IO消耗。

change buffer 只限于用在普通索引的場景下，而不適用于唯一索引.

merge:將 change buffer 中的操作應用到原數據頁，得到最新結果的過程。

merge執行流程：

1、從磁盤讀入數據頁到內存

2、從change buffer里找出這個數據頁的change buffer記錄，依次應用，得到新版數據頁

3、寫redo log,這個redo log包含了數據的變更和change buffer的變更。

change buffer 用的是 buffer pool 里的內存，因此不能無限增大。change buffer 的大小，可以通過參數 innodb_change_buffer_max_size=50 表示 change buffer 的大小最多只能占用 buffer pool 的 50%。

如果要在這張表中插入一個新記錄 (4,400) 的話，InnoDB 的處理流程是怎樣的。

第一種情況是，這個記錄要更新的目標頁在內存中

這時，InnoDB 的處理流程如下：

第二種情況是，這個記錄要更新的目標頁不在內存中

這時，InnoDB 的處理流程如下：

mysql insert into t(id,k) values(id1,k1),(id2,k2); 當前 k 索引樹的狀態，查找到位置后，k1 所在的數據頁在內存 (InnoDB buffer pool) 中，k2 所在的數據頁不在內存中。

分析這條更新語句，你會發現它涉及了四個部分：內存、redo log（ib_log_fileX）、 數據表空間（t.ibd）、系統表空間（ibdata1）。這條更新語句做了如下的操作（按照圖中的數字順序）：

帶change buffer的更新過程：

select * from t where k in (k1, k2) ,如果讀語句發生在更新語句后不久，內存中的數據都還在，那么此時的這兩個讀操作就與系統表空間（ibdata1）和 redo log（ib_log_fileX）無關了.

mysql：更新唯一索引的值

order為關鍵字，作為字段使用是需要加`引上，如下：

update test_t set `order`=5 where id=15;

Mysql索引

建立索引，要使用離散度（選擇度）更高的字段。

我們先來看一個重要的屬性列的 離散度，

count(distinct(column_name)) : count(*) -- 列的全部不同值個數：所有數據行行數

數據行數相同的情況下，分子越大，列的離散度就越高。簡單來說，如果列的重復值越多，離散度就越低，重復值越少，離散度就越高。

當字段值比較長的時候，建立索引會消耗很多的空間，搜索起來也會很慢。我們可以通過截取字段的前面一部分內容建立索引，這個就叫前綴索引。

創建一張商戶表，因為地址字段比較長，在地址字段上建立前綴索引

create table shop(address varchar(120) not null);

alter table shop add key(address(12));? // 截取12個字符作為前綴索引是最優的嗎？

問題是，截取多少呢？截取得多了，達不到節省索引存儲空間的目的，截取得少了，重復內容太多，字段的散列度（選擇性）會降低。怎么計算不同的長度的選擇性呢？

先看一下字段在全部數據中的選擇度計算公式：

select count(distinct address) / count(*) from shop;

select count(distinct left(address, n)) / count(*) as subn from shop;

count(distinct left(address,n)) / count(*) 的結果是會隨著 n 的變大而變大。舉個例子，現在有兩個address（東大街長興小區，東大街福樂小區），那么 distinct(address，2) distinct(address，3）

==所以，截取的長度越長就會越接近字段在全部數據中的選擇度

==所以，我們要權衡索引大小和查詢速度。

舉個例子，通過不同長度去計算，與全表的選擇性對比：

SELECT? COUNT(DISTINCT(address))/COUNT(*) sub,? ? ? ? ? ? -- 字段在全部數據中的選擇度

COUNT(DISTINCT(LEFT(address,5)))/COUNT(*) sub5,? -- 截取前5個字符的選擇度

COUNT(DISTINCT(LEFT(address,7)))/COUNT(*) sub7,?

COUNT(DISTINCT(LEFT(address,9)))/COUNT(*) sub9,

COUNT(DISTINCT(LEFT(address,10)))/COUNT(*) sub10,? -- 截取前10個字符的選擇度

COUNT(DISTINCT(LEFT(address,11)))/COUNT(*) sub11,

COUNT(DISTINCT(LEFT(address,12)))/COUNT(*) sub12,

COUNT(DISTINCT(LEFT(address,13)))/COUNT(*) sub13,

COUNT(DISTINCT(LEFT(address,15)))/COUNT(*) sub15

FROM shop;

+--------+--------+--------+--------+--------+--------+--------+--------+--------+

| sub? ? | sub5? | sub7? | sub9? | sub10? | sub11? | sub12? | sub13? | sub15? |

+--------+--------+--------+--------+--------+--------+--------+--------+--------+

| 0.9993 | 0.0225 | 0.4663 | 0.8618 | 0.9734 | 0.9914 | 0.9943 | 0.9943 | 0.9958 |

+--------+--------+--------+--------+--------+--------+--------+--------+--------+

可以看到在截取 11 個字段時 sub11(0.9993) 就已經很接近字段在全部數據中的選擇度 sub(0.9958)了，而且長度也相較后面更短一些， 綜合考慮比較合適。

ALTER TABLE shop ADD KEY (address(11));

1.索引的個數不要過多（浪費空間，更新變慢）

2.在用于 where 判斷 order 排序和 join 的（on）字段上創建索引

3.區分度低的字段，例如性別，不要建索引（離散度太低，導致掃描行數過多）

4.更新頻繁的值，不要作為主鍵或者索引（頁分裂）

5.不建議用無序的值作為索引，例如身份證、UUID（在索引比較時需要轉為ASCII，并且插入時可能造成頁分裂）

6.若在多個字段都要創建索引的情況下，聯合索引優于單值索引

7.聯合索引把散列性高（區分度高）的值放在前面

新聞名稱：mysql索引怎么更新 mysql索引升序
URL網址：http://www.yijiale78.com/article32/ddocipc.html

成都網站建設公司_創新互聯，為您提供搜索引擎優化、網站改版、營銷型網站建設、Google、全網營銷推廣、網站營銷

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯