[過去ログ]
スレ立てるまでもない質問はここで 165匹目 (1002レス)
スレ立てるまでもない質問はここで 165匹目 http://mevius.5ch.net/test/read.cgi/tech/1687260267/
上
下
前次
1-
新
通常表示
512バイト分割
レス栞
抽出解除
レス栞
このスレッドは過去ログ倉庫に格納されています。
次スレ検索
歴削→次スレ
栞削→次スレ
過去ログメニュー
リロード規制
です。10分ほどで解除するので、
他のブラウザ
へ避難してください。
312: デフォルトの名無しさん (オイコラミネオ MM2b-FJ+M) [sage] 2023/12/10(日) 12:13:10.46 ID:o2TNvwaPM >>1 `where b=値2` の条件だけ書いた場合になぜ高速化されるか について、もう少し詳しくお願いできませんか。 2文字のひらがなの辞書で考えて、 1文字目をa, 2文字目をb として、 ああ あい あう いあ いい いう のようにならびますが、b=いを検索したい 場合、1文字目が あい と、いい の2か所 に分かれて格納されてしまい、B-Treeだと 全く別の場所になってしまいそうですが。 http://mevius.5ch.net/test/read.cgi/tech/1687260267/312
313: デフォルトの名無しさん (オイコラミネオ MM2b-FJ+M) [sage] 2023/12/10(日) 12:18:53.28 ID:o2TNvwaPM >>312 まず、複合カラムでない場合に限定すれば、 N文字のキーが入っている B-Treeの場合、 深さは、大体 O(log(N))になります。 検索する際、どのあたりにキーがあるかは、 一意的に深い方向に探索をすれば済むので、 大体、O(log(N)) 回程度に「進めれば」検索が 終了できます。 しかし、複合カラムの場合、条件にaを指定せずに bだけを指定した場合、 キーは、様々な場所に分散されて格納されます ので、この例のひらがな50音の辞書の場合なら 50か所に分かれてしまうため、 log(N) * 50 回程度の時間がかかってしまうのでは ないでしょうか。 http://mevius.5ch.net/test/read.cgi/tech/1687260267/313
314: デフォルトの名無しさん (ワッチョイ ff84-pmcO) [sage] 2023/12/10(日) 14:06:39.26 ID:Ne0vvx410 >>312 申し訳ありません、誤解が生じました。確かに、私の前回の説明は一般的な場合に当てはまりますが、特に文字列の場合、`where b=値2` のクエリが効率的になるかどうかはデータの具体的な並びに依存します。 文字列の場合、B-Treeの挙動が通常の数値とは異なります。例えば、`ああ`、`あい`、`あう`などが順序通りに格納されることで、`where b='い'` のクエリは特に高速になります。これはB-Treeが文字列においても順序を保ちながらデータを格納するためです。 ただし、文字列の場合でも、全くの一般性があるわけではありません。文字列のソートは、通常の辞書順ではなく、各文字のバイトレベルの比較に基づいていることも考慮する必要があります。 そのため、データの実際の配置や使用しているデータベースシステムによっては、特定のクエリの性能が異なることがあります。文字列データにおいても最適なインデックス戦略は、具体的なデータとクエリによって変わることがあるので、実際のデータや使用状況を元に検討することが重要です。 http://mevius.5ch.net/test/read.cgi/tech/1687260267/314
メモ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.036s