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
Index完全に理解した
Search
k-tky
April 30, 2020
Programming
0
1.2k
Index完全に理解した
こちらで発表した資料です
https://easy2.connpass.com/event/173015/presentation/
k-tky
April 30, 2020
Tweet
Share
More Decks by k-tky
See All by k-tky
複式簿記完全に理解した
ktky
0
1.4k
Other Decks in Programming
See All in Programming
Kaigi on Rails 2024 - Rails APIモードのためのシンプルで効果的なCSRF対策 / kaigionrails-2024-csrf
corocn
5
3.4k
EventSourcingの理想と現実
wenas
6
2.1k
NSOutlineView何もわからん:( 前編 / I Don't Understand About NSOutlineView :( Pt. 1
usagimaru
0
110
Honoの来た道とこれから
yusukebe
19
3k
offers_20241022_imakiire.pdf
imakurusu
2
360
Vue.js学習の振り返り
hiro_xre
2
130
Piniaの現状と今後
waka292
5
1.5k
Vue SFCのtemplateでTypeScriptの型を活用しよう
tsukkee
3
1.5k
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
830
Generative AI Use Cases JP (略称:GenU)奮闘記
hideg
0
150
役立つログに取り組もう
irof
26
8.6k
LLM生成文章の精度評価自動化とプロンプトチューニングの効率化について
layerx
PRO
2
130
Featured
See All Featured
A better future with KSS
kneath
238
17k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
Navigating Team Friction
lara
183
14k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
46
2.1k
How GitHub (no longer) Works
holman
311
140k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.2k
Adopting Sorbet at Scale
ufuk
73
9k
How STYLIGHT went responsive
nonsquared
95
5.2k
Transcript
Index完全に理解した @k-tky
what am I? 所属 ・株式会社TOPGATE やってること ・現場作業員
とあるアプリケーションの開発. Develop... APP DB
とあるアプリケーションの開発.. Test... APP DB
とあるアプリケーションの開発... UAT... APP DB
ある日突然(突然ではない)... UAT... APP DB \オセーゾ!!!/ \ページガヒョウジサレナインダケド ?/ /ドーナッテンダ!\
アプリの遅い原因は色々あると思いますが、 今回はDB(MySQL)が悪いことにします。
DB \モウムリ / SQL SQL SQL SQL SQL SQL SQL
SQL
あー、Full Scanしてるな Index貼るか
よし、Indexアクセスになった な
ちょっと待って!そのIndex効率的? ・indexスキャンになっているが効率的なのか? indexスキャンになっているが効率的ではないことがある ・Indexとは? ・MySQLのデータ、Indexはどのような構造なのか? ・Indexを使った時のデータの取得方法は?
Indexとは? ・Indexとは索引のこと ・検索を行う時にIndexを経由してアクセスすることで、処理の高速化が図れる ・複数の列から構成されるIndexを作成することができる ・更新処理時にはIndexもメンテナンスする必要があるため、Indexのメンテナンス分の オーバーヘッドが発生する。 ・実態のデータとは別にIndexデータを保持する分、データ容量も大きくなる
MySQLの基本的なデータ、Index構造 MySQLのテーブルデータ構造 ・クラスタリングIndexと呼ばれるツリー構造で データが格納される ・root、branch、leafと辿り、leafにデータが格納さ れる MySQLのIndex構造 ・通常のIndexはB-Treeと呼ばれるツリー構造で格納 される
Indexを使った時のデータの取得方法 ・IndexはB-Treeのrootからbranch、leafへと順次データを読み込む ・leafに格納された主キーの情報を使ってテーブルデータを取得する ・テーブルデータの読み込みも rootからbranch、leafへと順次データを読み込 み、leafに格納されたデータを取得する
Indexを効率的に使えるようにするには? ・Indexを使う目的を考えてみる 検索を早くしたい ・Indexを使っても遅い原因とは? データブロックの読み込みが多いから データブロックの読み込みはIOが発生するため、非常に低速
どのようなカラムにIndexをつけるのが効率的? ・カーディナリティが高いカラムにつける カーディナリティとは、全レコード数に対するデータの種類の割合 100レコードに対してフラグなど真偽値をとる場合(2種類)は低い 100レコードに対してデータ内容が50種類ある場合は高い ・概ね20%程度にIndexで検索結果を絞れると最大効率的だと言われています。
カーディナリティの高いデータのアクセスパス ・Index→テーブルデータの順でアクセスする。 結果:読み込むデータブロックの量が少なくなる。 Indexのデータブロックを読み込み、テーブルデータのデータブロックを読み込む
カーディナリティの低いデータのアクセスパス ・Index→テーブルデータの順でアクセスする。 結果:読み込むデータブロックの量が多くなる。 Indexのデータブロックを読み込み、テーブルデータのデータブロックを読み込む
MySQLの全表アクセスパス(フルスキャン) ・全表スキャンはデータ構造のroot、branch、leafのデータブロックを読み込む leafにデータが格納されているので、 leafは横方向に読み込んでいく
Indexを効率的に使えるようにするには?(再度) ・そもそも遅い原因とは?(振り返り) データブロックの読み込みが多い ・Indexを使ってデータブロックの読み込みを少なくする Indexを使うことによってデータブロックの読み込みがどのように行われるか? Indexを使うことによってデータブロックの読み込みが多くなっていないか?
なお ・DBによってアクセスパスは変わります。 ・テーブルデータ構造も変わります。 ・DBによって特性も変わってきますので、その辺りも考慮しつつ設計してみましょう。 ・※データブロックを読み込む量を減らすことを目的としてIndexを貼ることは概ね共通だ と思います。(検索が遅い理由は基本的にデータブロックの読み込みが多いことかと)
まとめ ・Indexのメリット、デメリットを理解する よっぽどではない限り、検索が優先されると思うので貼る方向にはなると思います ・Indexは貼ればいいということではない ・Indexスキャンになっているからといって、必ずしも効率的なデータ取得がされているわ けではない ・DBごとのデータ構造、Indexの種類ごとの構造、アクセスパスを理解することで効率的 なIndex設計の手助けになればいいな、と思います。