[過去ﾛｸﾞ]
スレ立てるまでもない質問はここで 165匹目 (1002ﾚｽ)
スレ立てるまでもない質問はここで 165匹目 http://mevius.5ch.net/test/read.cgi/tech/1687260267/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
ﾚｽ栞
あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
309: デフォルトの名無しさん (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) [sage] 2023/12/10(日) 10:57:51.63 ID:o2TNvwaPM SQLITEなどのDBMSで、2つ以上のカラムに まとめてindex (B-Tree)を用意するところの 「Multicolumn indexes(Composite indexes)」 を用いる場合、select の where 節で 2つのカラムa, b に対して、 where a=値1 and b=値2 とした場合、高速化されるそうです。 しかし、b については条件を指定せずに where a=値1 とだけ書いた場合や、 a については条件を指定せずに where b=値2 とだけ書いた場合の速度も高速化されますか？ http://mevius.5ch.net/test/read.cgi/tech/1687260267/309
312: デフォルトの名無しさん (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) [sage] 2023/12/10(日) 12:13:10.46 ID:o2TNvwaPM >>1 `where b=値2` の条件だけ書いた場合になぜ高速化されるか について、もう少し詳しくお願いできませんか。 2文字のひらがなの辞書で考えて、 1文字目をa, ２文字目をb として、 ああ あい あう いあ いい いう のようにならびますが、b=いを検索したい 場合、1文字目が あい と、いい の２か所 に分かれて格納されてしまい、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
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.131s*