[過去ﾛｸﾞ] スレ立てるまでもない質問はここで 165匹目 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
314: デフォルトの名無しさん (ﾜｯﾁｮｲ ff84-pmcO) [sage] 2023/12/10(日) 14:06:39.26 ID:Ne0vvx410(1/2) AAS
>>312312(2): デフォルトの名無しさん (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) [sage] 2023/12/10(日) 12:13:10.46 ID:o2TNvwaPM(2/3) AAS
>>1
`where b=値2`
の条件だけ書いた場合になぜ高速化されるか
について、もう少し詳しくお願いできませんか。
2文字のひらがなの辞書で考えて、
1文字目をa, ２文字目をb として、
ああ
あい
あう
いあ
いい
いう
のようにならびますが、b=いを検索したい
場合、1文字目が あい と、いい の２か所
に分かれて格納されてしまい、B-Treeだと
全く別の場所になってしまいそうですが。
申し訳ありません、誤解が生じました。確かに、私の前回の説明は一般的な場合に当てはまりますが、特に文字列の場合、`where b=値2` のクエリが効率的になるかどうかはデータの具体的な並びに依存します。
文字列の場合、B-Treeの挙動が通常の数値とは異なります。例えば、`ああ`、`あい`、`あう`などが順序通りに格納されることで、`where b='い'` のクエリは特に高速になります。これはB-Treeが文字列においても順序を保ちながらデータを格納するためです。
ただし、文字列の場合でも、全くの一般性があるわけではありません。文字列のソートは、通常の辞書順ではなく、各文字のバイトレベルの比較に基づいていることも考慮する必要があります。
そのため、データの実際の配置や使用しているデータベースシステムによっては、特定のクエリの性能が異なることがあります。文字列データにおいても最適なインデックス戦略は、具体的なデータとクエリによって変わることがあるので、実際のデータや使用状況を元に検討することが重要です。
315: デフォルトの名無しさん (ﾜｯﾁｮｲ ff84-pmcO) [sage] 2023/12/10(日) 14:08:36.12 ID:Ne0vvx410(2/2) AAS
>>313313(1): デフォルトの名無しさん (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) [sage] 2023/12/10(日) 12:18:53.28 ID:o2TNvwaPM(3/3) AAS
>>312
まず、複合カラムでない場合に限定すれば、
N文字のキーが入っている B-Treeの場合、
深さは、大体 O(log(N))になります。
検索する際、どのあたりにキーがあるかは、
一意的に深い方向に探索をすれば済むので、
大体、O(log(N)) 回程度に「進めれば」検索が
終了できます。
しかし、複合カラムの場合、条件にaを指定せずに
bだけを指定した場合、
キーは、様々な場所に分散されて格納されます
ので、この例のひらがな50音の辞書の場合なら
50か所に分かれてしまうため、
log(N) * 50 回程度の時間がかかってしまうのでは
ないでしょうか。
おっしゃる通り、複合カラムの場合、特に「条件にaを指定せずにbだけを指定した場合」、B-Treeの探索が効率的でない場合があります。
複合カラム `(a, b)` のB-Treeでは、`a` でソートされ、同じ `a` の中で `b` がソートされている状態です。そのため、`where b=値2` のようなクエリが効率的になるのは、同じ `a` 内において `b` の値が連続的に格納されている場合に限られます。
しかし、もし `a` の値が異なる場合、`b` の値も異なる箇所に格納され、深さが増加し、効率が損なわれる可能性があります。したがって、複合インデックスの効果はデータの分布に強く依存します。
一般的に、複合インデックスが効果的なのは、クエリで指定された条件が複合インデックスの順序に合致する場合です。もし `a` を指定せずに `b` だけを指定するケースでデータが分散して格納される場合、B-Treeの探索が非効率的になる可能性があります。その際は、単独の `b` に対する単一カラムインデックスを検討することが適している場合があります。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s