④ インデックスの間

10万行から1行を探す

②室でmarket_ticksテーブルのB-tree(深さ2)を見ました。木の深さが浅いということは、 「主キーで探す」なら数回のページ読みで届くはずです。逆にインデックスの無い 列で探すと、該当する行を見つけるまで先頭から総当たりするしかありません。 実際のtrader.dbの本物のmarket_ticksテーブル(4銘柄×毎秒で伸び続けている表)で、 その差を実測してみましょう。

「SEARCH ... USING INDEX」「USING COVERING INDEX」はB-treeを辿って直接たどり着いたことを示し、 「SCAN」は先頭から順に調べたことを示します(①室のhexビューアで実際のB-treeページも見比べられます)。 market_ticksの主キーは「銘柄+時刻」の組なので、SQLiteは表の木とは別に sqlite_autoindex_market_ticks_1という索引の木を作ります。主キー検索は 「索引の木で行番号(rowid)を見つけ、表の木でその行を読む」の2段です。 範囲検索のCOUNTは索引の木だけで答えが出るので、表の木を読みません(COVERING INDEX)。

砂場SQL

ここから先はあなた専用の使い捨てSQLiteファイルです(最大1MB・30分で自動削除)。 自由にSQLを実行して、実行のたびにファイルのページがどう変わるかをその場の hexビューアで確認できます。ATTACHとVACUUM INTOは 安全のため使えません。