MYSQL索引 一百萬條資料進行測試

測試在mysql中使用索引和不使用索引查詢資料的速度區別、

`id` bigint(20) unsigned not nullauto_increment,

`name` varchar(50) default '',

`email` varchar(50) not null,

`phone` varchar(20) default '',

`gender` tinyint(4) unsigned default '0',

`password` varchar(100) not null default '',

`update_time` timestamp not null default current_timestamp on update current_timestamp,

primary key(`id`)

) engine=innodb auto_increment=1000001 default charset=utf8

-- 1、插入100萬資料.

delimiter $$
-- 寫函式之前必須要寫$$標誌
create functionmock_data ()
returns int
begin
declare num int default 1000000;
declare i int default 0;
while i
set i=i+1;
end while;
returni;
end;
-- 2、執行此函式 生成一百萬條資料大約要執行半分鐘
selectmock_data() 
-- 3、查詢表中資料

新增索引後我們再來測試下查詢資料需要多久：

btree是平衡搜尋多叉樹，設樹的度為2d（d>1），高度為h，那麼btree要滿足以一下條件：

btree的結構如下：

在btree的機構下，就可以使用二分查詢的查詢方式，查詢複雜度為h*log(n)，一般來說樹的高度是很小的，一般為3左右，因此btree是乙個非常高效的查詢結構。

btree的查詢、插入、刪除過程可以參考：

b+tree是btree的乙個變種，設d為樹的度數，h為樹的高度，b+tree和btree的不同主要在於：

b+tree的結構如下：

b+tree對比btree的優點：

1、磁碟讀寫代價更低

一般來說b+tree比btree更適合實現外存的索引結構，因為儲存引擎的設計專家巧妙的利用了外存（磁碟）的儲存結構，即磁碟的最小儲存單位是扇區（sector），而作業系統的塊（block）通常是整數倍的sector，作業系統以頁（page）為單位管理記憶體，一頁（page）通常預設為4k，資料庫的頁通常設定為作業系統頁的整數倍，因此索引結構的節點被設計為乙個頁的大小，然後利用外存的「預讀取」原則，每次讀取的時候，把整個節點的資料讀取到記憶體中，然後在記憶體中查詢，已知記憶體的讀取速度是外存讀取i/o速度的幾百倍，那麼提公升查詢速度的關鍵就在於盡可能少的磁碟i/o，那麼可以知道，每個節點中的key個數越多，那麼樹的高度越小，需要i/o的次數越少，因此一般來說b+tree比btree更快，因為b+tree的非葉節點中不儲存data，就可以儲存更多的key。

2、查詢速度更穩定

由於b+tree非葉子節點不儲存資料（data），因此所有的資料都要查詢至葉子節點，而葉子節點的高度都是相同的，因此所有資料的查詢速度都是一樣的。

什麼時候要使用索引？

什麼時候不要使用索引？

索引失效的情況：

百萬條資料分頁

寫出 之前，先說明一下原理，比較簡單。有一張表 test 如下 結構是 id 自動編號 txt 假設40條記錄 現在要每頁顯示10條記錄，則每頁要顯示的資料應該是 第一頁 10 第二頁 11 20 第三頁 21 30 第四頁 31 40 如要顯示第一頁，最簡單的方法就是 select top 10 ...

百萬條資料如何進行分頁查詢

今天面試被問到一張表 有500w條資料，如何進行分頁查詢，瞬間不知道怎麼回答，平時工作中沒接觸到這麼大的資料量。所以回家自己去實驗一下 建立一張user表 create table user id bigint 20 not null auto increment,username varchar ...

MySQL插入百萬條資料 個人總結1

有好多種方法。之前也總結了一些，但放到現在來看，效率都一般，於是重新思考總結這個問題 方法一 使用儲存過程procedure每次insert的時候mysql都會自動提交，然後會有其他的一些耗時的操作，所以。取消掉自動提交不就好了嘛。直接 set autocommit 0 測試結果 80萬 9.67秒...