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.5k
Other Decks in Programming
See All in Programming
PHPUnitの限界をPlaywrightで補完するテストアプローチ
yuzneri
0
370
リッチエディターを安全に開発・運用するために
unachang113
1
350
商品比較サービス「マイベスト」における パーソナライズレコメンドの第一歩
ucchiii43
0
270
AWS Summit Japan 2024と2025の比較/はじめてのKiro、今あなたは岐路に立つ
satoshi256kbyte
1
260
Google I/O Extended Incheon 2025 ~ What's new in Android development tools
pluu
1
220
オホーツクでコミュニティを立ち上げた理由―地方出身プログラマの挑戦 / TechRAMEN 2025 Conference
lemonade_37
1
430
バイブコーディングの正体——AIエージェントはソフトウェア開発を変えるか?
stakaya
5
720
[DevinMeetupTokyo2025] コード書かせないDevinの使い方
takumiyoshikawa
2
250
No Install CMS戦略 〜 5年先を見据えたフロントエンド開発を考える / no_install_cms
rdlabo
0
430
DynamoDBは怖くない!〜テーブル設計の勘所とテスト戦略〜
hyamazaki
0
180
대규모 트래픽을 처리하는 프론트 개발자의 전략
maryang
0
110
なぜ今、Terraformの本を書いたのか? - 著者陣に聞く!『Terraformではじめる実践IaC』登壇資料
fufuhu
3
390
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
19k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.6k
A better future with KSS
kneath
238
17k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
47
9.6k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
540
GitHub's CSS Performance
jonrohan
1031
460k
Documentation Writing (for coders)
carmenintech
73
5k
How GitHub (no longer) Works
holman
314
140k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
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設計の手助けになればいいな、と思います。