測試在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萬資料.可以看到查詢使用者名為「使用者名稱888888」的資訊,耗費了0.5s左右,在人的眼睛中這是非常短暫的,但是在計算機的世界中,是非常久的。所以我們要做一些優化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秒...