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.3k
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.6k
Other Decks in Programming
See All in Programming
What's New in Web AI?
christianliebel
PRO
0
120
Snowflake リリースに注意を払いたくなる話
masaaya
0
100
なぜ強調表示できず ** が表示されるのか — Perlで始まったMarkdownの歴史と日本語文書における課題
kwahiro
9
5.1k
『HOWはWHY WHATで判断せよ』 〜『ドメイン駆動設計をはじめよう』の読了報告と、本質への探求〜
panda728
PRO
5
1.1k
高単価案件で働くための心構え
nullnull
0
110
Introducing RemoteCompose: break your UI out of the app sandbox.
camaelon
2
540
Promise.tryで実現する新しいエラーハンドリング New error handling with Promise try
bicstone
2
330
AI駆動開発ライフサイクル(AI-DLC)のホワイトペーパーを解説
swxhariu5
0
510
Atomics APIを知る / Understanding Atomics API
ssssota
1
120
Stay Hacker 〜九州で生まれ、Perlに出会い、コミュニティで育つ〜
pyama86
1
320
ボトムアップの生成AI活用を推進する社内AIエージェント開発
aku11i
0
1.6k
Blazing Fast UI Development with Compose Hot Reload (Bangladesh KUG, October 2025)
zsmb
2
500
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Faster Mobile Websites
deanohume
310
31k
Building Applications with DynamoDB
mza
96
6.7k
Raft: Consensus for Rubyists
vanstee
140
7.2k
Writing Fast Ruby
sferik
630
62k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
11
920
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.8k
YesSQL, Process and Tooling at Scale
rocio
174
15k
4 Signs Your Business is Dying
shpigford
186
22k
Why Our Code Smells
bkeepers
PRO
340
57k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
24
1.5k
Optimising Largest Contentful Paint
csswizardry
37
3.5k
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設計の手助けになればいいな、と思います。