[過去ログ] スレ立てるまでもない質問はここで 165匹目 (1002レス)
前次1-
抽出解除 レス栞

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
リロード規制です。10分ほどで解除するので、他のブラウザへ避難してください。
312
(2): (オイコラミネオ MM2b-FJ+M) 2023/12/10(日)12:13 ID:o2TNvwaPM(2/3) AAS
>>1
`where b=値2`
の条件だけ書いた場合になぜ高速化されるか
について、もう少し詳しくお願いできませんか。
2文字のひらがなの辞書で考えて、
1文字目をa, 2文字目をb として、
ああ
あい
あう
いあ
省6
313
(1): (オイコラミネオ MM2b-FJ+M) 2023/12/10(日)12:18 ID:o2TNvwaPM(3/3) AAS
>>312
まず、複合カラムでない場合に限定すれば、
N文字のキーが入っている B-Treeの場合、
深さは、大体 O(log(N))になります。
検索する際、どのあたりにキーがあるかは、
一意的に深い方向に探索をすれば済むので、
大体、O(log(N)) 回程度に「進めれば」検索が
終了できます。
しかし、複合カラムの場合、条件にaを指定せずに
bだけを指定した場合、
省5
314: (ワッチョイ ff84-pmcO) 2023/12/10(日)14:06 ID:Ne0vvx410(1/2) AAS
>>312
申し訳ありません、誤解が生じました。確かに、私の前回の説明は一般的な場合に当てはまりますが、特に文字列の場合、`where b=値2` のクエリが効率的になるかどうかはデータの具体的な並びに依存します。

文字列の場合、B-Treeの挙動が通常の数値とは異なります。例えば、`ああ`、`あい`、`あう`などが順序通りに格納されることで、`where b='い'` のクエリは特に高速になります。これはB-Treeが文字列においても順序を保ちながらデータを格納するためです。

ただし、文字列の場合でも、全くの一般性があるわけではありません。文字列のソートは、通常の辞書順ではなく、各文字のバイトレベルの比較に基づいていることも考慮する必要があります。

そのため、データの実際の配置や使用しているデータベースシステムによっては、特定のクエリの性能が異なることがあります。文字列データにおいても最適なインデックス戦略は、具体的なデータとクエリによって変わることがあるので、実際のデータや使用状況を元に検討することが重要です。
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.038s