Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
インデックスのパフォーマンス調べてみた
Search
matumoto
October 15, 2022
Technology
0
63
インデックスのパフォーマンス調べてみた
2022/10月に行われた大LTでの発表資料です
イベントページはこちら
https://zli.connpass.com/event/261496/
matumoto
October 15, 2022
Tweet
Share
More Decks by matumoto
See All by matumoto
Goトランザクション処理
matumoto
0
28
いまいちどスライスの 挙動を見直してみる
matumoto
0
300
Go1.22のリリース予定の機能を見る
matumoto
0
58
GoのUnderlying typeについて
matumoto
0
160
Typed-nilについて
matumoto
0
220
GoのType Setsという概念
matumoto
0
16
GoのRateLimit処理の実装
matumoto
0
250
Webプッシュ通知触ってみた
matumoto
0
31
拡張ユークリッドの互除法の紹介
matumoto
0
210
Other Decks in Technology
See All in Technology
データエンジニアリング領域におけるDuckDBのユースケース
chanyou0311
6
1.9k
あれは良かった、あれは苦労したB2B2C型SaaSの新規開発におけるCloud Spanner
hirohito1108
2
890
Exadata Database Service on Cloud@Customer セキュリティ、ネットワーク、および管理について
oracle4engineer
PRO
2
1.5k
Perlの生きのこり - エンジニアがこの先生きのこるためのカンファレンス2025
kfly8
1
240
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
18k
Reading Code Is Harder Than Writing It
trishagee
2
120
Iceberg Meetup Japan #1 : Iceberg and Databricks
databricksjapan
0
290
2/18/25: Java meets AI: Build LLM-Powered Apps with LangChain4j
edeandrea
PRO
0
160
IAMポリシーのAllow/Denyについて、改めて理解する
smt7174
2
180
OSS構成管理ツールCMDBuildを使ったAWSリソース管理の自動化
satorufunai
0
390
次世代KYC活動報告 / 20250219-BizDay17-KYC-nextgen
oidfj
0
460
【内製開発Summit 2025】イオンスマートテクノロジーの内製化組織の作り方/In-house-development-summit-AST
aeonpeople
1
480
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
It's Worth the Effort
3n
184
28k
Being A Developer After 40
akosma
89
590k
Unsuck your backbone
ammeep
669
57k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
430
Building Your Own Lightsaber
phodgson
104
6.2k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
52k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
360
Transcript
インデックスの パフォーマンス 調べてみた matumoto
自己紹介 • ハンドルネーム:matumoto • 本名:松本響輝 • 学年:28期 • 趣味:イカᔦꙬᔨ •
やってきた技術: ◦ ゲーム作り ◦ フロントエンド ◦ AtCoder 水💧 • Twitter:@matumoto_1234
インデックスについて
インデックスとは? • インデックスとは、データの検索速度を向上させるために、どの行がどこにあるかを示した索引のこ と (https://www.techscore.com/tech/sql/15_01 より引用) • DBのテーブルに適切にインデックスを作ることで、パフォーマンス向上につながる • MySQLなどではCREATE
TABLEなどの文でインデックスを指定できる • 例. CREATE TABLE people ( id INT, name VARCHAR(512), age INT, INDEX name_INDEX (name) )
インデックスがどう使われるのか? • クエリに対応して、インデックスが自動で使われる • 例. ◦ peopleという名前の、こんなテーブルがあったとする id name age
1 matumoto 20 2 Aizu Taro 256 • SELECT id FROM people WHERE name = 'matumoto' というような、nameカラムに対しての検索クエリが きたとき、name_INDEXが使われる • SELECT idFROM people WHERE age = 20 というような、ageカラムに対しての検索クエリがきたらイン デックスは使われず、テーブル全体がそのまま読み込まれる
インデックスのパフォーマンス • インデックスは基本的に、ユニーク(重複がない)なもののほうがパフォーマンスが良い ◦ 例. PRIMARY KEYに基づくインデックスやUNIQUE制約のついたインデックスなど →なぜパフォーマンスが良いのか?(本題) →後述
インデックスの内部構造
インデックスを作るとどうなるか • インデックスを作ってもテーブル自体に変更が加わるわけではない • テーブルとは別にインデックス用の領域が取られ、まずはそこにアクセスする テーブル インデックス クエリ ソートとかはされていない! テーブルの場所が効率よく検索で
きるように保存されている
インデックスはどうなっているか • B-treeというようなデータ構造がよく使われている ◦ 厳密にはB+treeや、B*treeという改良版が使われることが多い
B-treeとは? • B-treeは平衡探索木の一種 ◦ よくある、平衡二分探索木とかとは違って多分木 ◦ BはBinaryではなく、Balanceの略 ◦ よくデータベース管理システムや、ファイルシステムで使用される 5
70 2 1 3 8 6 20 82 91 71 85 97
B-treeの特徴 • B-treeの特徴 ◦ 完全に平衡になっている(根から任意の葉までのパスの長さが一定 ) ◦ ノードにいくつかの値を持つ ◦ 一つのノードにm個以下の枝があるものをオーダー
mのB-treeと呼ぶ ◦ これはオーダー3のB-tree 5 70 2 1 3 8 6 20 82 91 71 85 97
挿入操作でB-treeの平衡はどうやって保っているの? • A. 気合い http://wwwa.pikara.ne.jp/okojisan/t23-java/index.html より図を引用
削除操作でB-treeの平衡はどうやって保っているの? • A. もちろん気合い http://wwwa.pikara.ne.jp/okojisan/t23-java/index.html より図を引用
B-treeの計算量 • B-treeの計算量 ◦ nを要素数とする ◦ 挿入:O(log n) ◦ 削除:O(log
n) ◦ 検索:O(log n) • AVL木や、赤黒木といった平衡二分探索木より速い? ◦ そんなことはなくて、遅い ◦ オーダーmのB-treeのノードを辿るときにO(m)回の値比較を行うので遅い ◦ データベース管理システムなどで使われるのは、「枝を辿るコスト」 >「値比較のコスト」な ため
B-treeの亜種 • B+treeというのが存在する ◦ 葉ノードがつながっており、範囲クエリに強い ◦ 葉ノードに実際のレコードが全て存在している ◦ MySQL/InnoDBなどで使われている https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html
より図を引用
インデックスの パフォーマンス
インデックスのパフォーマンス • SQLクエリをEXPLAINすると表示される「type」 • 主なものとしては、以下がある ◦ const:PRIMARY KEYのインデックスやUNIQUEインデックスを使う。最速 ◦ eq_ref:JOINのときにPRIMARY
KEYのインデックスやUNIQUEインデックスを使う ◦ ref:ユニークでないインデックスを使ったときの等価検索など ◦ range:インデックスを用いた範囲検索 (0 <= key <= 10を満たすkeyを検索するなど) ◦ index:フルインデックススキャン。インデックス全体を見る ◦ all:フルテーブルスキャン。インデックスが使用されていない • なぜユニークだと早くなる傾向にあるのか?
インデックスのパフォーマンス • 検索で遅くなるのは葉ノードの走査が大きな原因の一つとしてある • 検索対象がユニークなら、見つけ次第終了できるが、ユニークでない場合は他の 葉ノードを見る必要がある • 例. 20を見つけたとしても、20が他にあるかもしれないので葉ノードを辿る必要があ る
https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html より図を引用
まとめ
まとめ • インデックスの内部構造はB-treeがベースになっていることが多くて、計算量は だ いたい O(log n) ◦ 範囲クエリでk個の要素がみつかるときは、 O(log
n + k) 程度
ご静聴ありがとうございました