とみたです。

At Thu, 11 May 2000 20:07:05 +0900,
moeru@xxxxxxxxxx (moeru) wrote:

> CREATE TABLE items (
> 	itemid int(20) NOT NULL AUTO_INCREMENT,
> 	username VARCHAR(20) NOT NULL,
> 	title tinytext,
> 	date timestamp(14),
> 	description text,
> 	PRIMARY KEY (itemid),
> 	INDEX (title),
> 	INDEX (date),
> 	INDEX (username),  
> ),
	〜〜
> MySQLの場合、以下のようにusersテーブルとitemsテーブルをリレーションして
> usersテーブルの情報（usernameやemail）をもらってきたほうが高速なのでしょうか？

単純に考えたら、join しない方がその分の処理が要らないから、速いような気
はします。

ただ、上の例の items テーブルは、userid INT NOT NULL, INDEX(userid) を追
加しておいて、username じゃなくて userid で検索した方が速いと思います。

# 20バイトの比較と4バイトの比較では、4バイトの方が速いでしょう。きっと。

> 以下では、INDEX (username)は、リレーションしてるから必要ないと思って
> はずしました。。
> 
> CREATE TABLE items (
> 	itemid int(20) NOT NULL AUTO_INCREMENT,
> 	userid INT NOT NULL,
> 	title tinytext,
> 	date timestamp(14),
> 	description text,
> 	PRIMARY KEY (itemid),
> 	INDEX (title),
> 	INDEX (date),
> ),

INDEX (userid) はあった方がいいでしょう。

なお、title に INDEX を張って高速化になるのは、title の先頭から一致する
文字列を検索する場合だけだと思います。

> ＊	itemsテーブルでは、userid INT NOT NULL,
> 　　のAUTO_INCREMENTは必要ないと思って取りました。。これは正解ですか？

正解です。

> 正規化によって、検索を高速化するためには
> それぞれのテーブルにだぶりのフィールドが無い(ＩＤ以外皆無に)すると理解して良いのでしょうか？

正規化したら高速化できるってわけではないと思います。高速化のためにわざと
正規化しないこともありますし。

正規化することで、テーブルの大きさが小さくなって、I/O が速くなるってこと
もあると思います。

> 例え、フィールドが他のテーブルとダブっても、
> 目的によっては、一つのテーブルに必要な情報が入ってる方が高速
> とかいう場合もあるのかどうかも知りたいです。。

join 処理に負荷がかかるんなら一つのテーブルの方が速いこともあるかもしれ
ません。

--
とみたまさひろ <tommy@xxxxxxxxxx>