[過去ﾛｸﾞ] スレ立てるまでもない質問はここで 165匹目 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
318(2): デフォルトの名無しさん (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) [sage] 2023/12/10(日) 18:25:42.40 ID:V/86XK6XM(1) AAS
[1] あ、い、う の三文字を2個並べた組み合わせを
キーに持つとして、3*3=9 個のキーを持つと
すると、B-Tree は、木の根が1つで、
1文字目で3つに枝が分かれ、別れた先
の2文字目でさらに3つに枝が分かれます。
1文字目をa, 2文字目をbとします。
図が書けないので、フォルダのように表すと、
/あ/あ (1)
/あ/い (2)
/あ/う (3)
/い/あ (4)
/い/い (5)
/い/う (6)
/う/あ (7)
/う/い (8)
/う/う (9)
となります。
[2] where a=あ and b=い
とした場合、たった一度の探索で(2)
に辿り着けます。
[3] where a=い
とした場合は、(4),(5),(6)ですが、それらは、「第一関節」の
同じ一本の枝「い」に属すのでとても効率的に探せます。
[4] where b=い
とした場合、(2),(5),(8)の三か所を探索する必要がありますが、
第一関節レベルから異なる枝に属しているので、
第二関節に行った後で第一関節まで「戻る」ような動作が必要になります。
[まとめ]
実際の探索では、「戻る」わけではないんでしょうが、
aだけを指定した場合と、bだけを指定した場合とでは、探索回数が3倍の違いが
出てきますよね？
320(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 9f79-1KRD) [sage] 2023/12/10(日) 21:44:37.10 ID:yZwJDRXW0(1/2) AAS
>>318
B木って部分探索のアルゴリズムじゃないけど
トライ木辺りと勘違いしてないか
323(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 7f01-a+/s) [] 2023/12/10(日) 23:59:24.31 ID:p7J4kGbi0(1) AAS
>>318
B-Treeはそういうのじゃない
ページサイズの一定割合に収まるだけのレコードがルートを含めたインデックスノードにも詰められていく
page 1 [ああ〜いい]
/
いう
\
page 2 [いう〜うう]
>>317317(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 9f4b-7MMK) [sage] 2023/12/10(日) 16:08:39.19 ID:oYKusLHl0(1) AAS
SQLITEやOracleではINDEX SKIP SCANを使うので左端列を指定しなくてもインデックスが採用される
もちろん左端列のみを指定するより性能は劣る
SQLServerあたりだと左端列を指定しないケースではインデックスは使われない
の書いてるINDEX SKIP SCANがDBMSやデータの状況によって採用されるケースなら
インデックスがあったほうが速いということになるが採用されなければテーブルスキャンなのでインデックスなくても同じ
INDEX SKIP SCANは複合インデックスの先頭列の値の種類が少ない場合じゃないと非効率
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.037s