インデックスがあるのにフルスキャン？ - kagamihogeの日記
「なんか遅いから早くして（意訳）」という仕事が回ってきた。大量データ投入後の試験待たずとも、遅いのは前々から分かってたから覚悟は出来てたんだけど･･･人外魔境と化したコードにどう手を入れたもんですかねぇ。 さて。何はともあれ計測一番。SQL Server Profiler を起動して、ブラウザから遅いといわれる機能のボタンを押してみる。･･･とスクロールバーがあっという間に小さくなってしまった。すごい参照系だなぁと思いつつ発効されたクエリ数を見るとその数 400。400 個の SELECT で出来てる画面って･･･一体･･･。 ログを見ると似たようなクエリを大量に出してるので、そういう個所を一つずつ作り直すしかないかなぁ･･･と思っているとログの中に 1 分近くかかっているクエリを発見。このクエリもまた数回走っており、一回ボタン押したら 5 分くらい返って来ない主原因になっている様子。 で
インデックス範囲スキャンとフルテーブルスキャンの損益分岐点 - kagamihogeの日記
損益分岐点というたとえが正確かどうかはわからないが。範囲検索がある一定以上になると、インデックスよりもフルスキャンのほうが速くなるポイントがある。というわけで、それはどのへんにあるのかをやってみる。 やることとしては、連番の数値と文字列の2列からなるテーブルを用意し、数値列に対する範囲検索を実行して、インデックス範囲スキャンとフルテーブルスキャンの実行時間を計測する。数値列には一意インデックスを張る。 環境 Oracle Database Express Edition 11g Release 2をWindows上で動作 Oracle SQL Developer 3.2 SQL*Plus: Release 11.2.0.2.0 Production 準備 検索対象となる適当なテーブルを作る。 create table dest (search integer, rand_str varch
リレーショナルデータベース入門―データモデル・SQL・管理システム - kagamihogeの日記
RDBMSの知識不足を感じて以来、ここのところその勉強に力を入れている。学習方針は、 達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ - kagamihogeのblog等の著書のミック氏が推奨している方法で、理論と実装の両面から進めている。俺の場合、後者は、Oracleで主にパフォーマンスの観点から基本的原則を確認することをやり、前者は、本書のような書籍を通して行っている。 本書は、コンピュータサイエンス初年度の講義の教科書を想定して作られている。そのため、コンパクトながらもトピックの網羅性、それになにより各章が独立していながらも本一冊を通してみると一貫性が保たれているのが素晴らしい。また、章から章への論理展開が極めて明快なので読みやすい。もっとも、これは俺がある程度の実務経験という下地と、まがりなりにもコンピュータサイエンスの学部経験があるからこそ、の部分もあるだろうけど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
