2012-04-05 4 views
6

このクエリに問題があり、完了するまでに数秒かかります。私はすでに多くの最適化を試みましたが、この時点で空白を撮影しています。このクエリでRIGHT JOINを使用するとJOINが非常に遅くなります

表は、以下の(と完全に特にトラックテーブル絶対に正規化されていない)されて

CREATE TABLE `tracks` (
`id` int(14) unsigned NOT NULL AUTO_INCREMENT, 
`artist` varchar(200) NOT NULL, 
`track` varchar(200) NOT NULL, 
`album` varchar(200) NOT NULL, 
`path` text NOT NULL, 
`tags` text NOT NULL, 
`priority` int(10) NOT NULL DEFAULT '0', 
`lastplayed` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00', 
`lastrequested` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00', 
`usable` int(1) NOT NULL DEFAULT '0', 
`accepter` varchar(200) NOT NULL DEFAULT '', 
`lasteditor` varchar(200) NOT NULL DEFAULT '', 
`hash` varchar(40) DEFAULT NULL, 
PRIMARY KEY (`id`), 
UNIQUE KEY `hash` (`hash`), 
FULLTEXT KEY `searchindex` (`tags`,`artist`,`track`,`album`), 
FULLTEXT KEY `artist` (`artist`,`track`,`album`,`tags`) 
) ENGINE=MyISAM AUTO_INCREMENT=3336 DEFAULT CHARSET=utf8 

CREATE TABLE `esong` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
`hash` varchar(40) COLLATE utf8_bin NOT NULL, 
`len` int(10) unsigned NOT NULL, 
`meta` text COLLATE utf8_bin NOT NULL, 
PRIMARY KEY (`id`), 
UNIQUE KEY `hash` (`hash`) 
) ENGINE=InnoDB AUTO_INCREMENT=16032 DEFAULT CHARSET=utf8 COLLATE=utf8_bin 

CREATE TABLE `efave` (
`id` int(10) unsigned NOT NULL DEFAULT '0', 
`inick` int(10) unsigned NOT NULL, 
`isong` int(10) unsigned NOT NULL, 
UNIQUE KEY `inick` (`inick`,`isong`), 
KEY `isong` (`isong`), 
CONSTRAINT `inick` FOREIGN KEY (`inick`) REFERENCES `enick` (`id`) ON DELETE CASCADE ON UPDATE CASCADE, 
CONSTRAINT `isong` FOREIGN KEY (`isong`) REFERENCES `esong` (`id`) ON DELETE CASCADE ON UPDATE CASCADE 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 

CREATE TABLE `enick` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT 
`nick` varchar(30) COLLATE utf8_bin NOT NULL, 
`dta` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 
`dtb` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00', 
PRIMARY KEY (`id`), 
KEY `nick` (`nick`) 
) ENGINE=InnoDB AUTO_INCREMENT=488 DEFAULT CHARSET=utf8 COLLATE=utf8_bin 

と、私は通常の速度で実行しようとしているクエリは、次の

SELECT esong.meta, tracks.id FROM tracks RIGHT JOIN esong ON tracks.hash = esong.hash JOIN efave ON efave.isong = esong.id JOIN enick ON efave.inick = enick.id WHERE enick.nick = lower('nickname'); 
です

ここで正しいジョインを削除してJOINに変更すると、それは速いです

EXPLAINは私にこの結果を与えます、それはefaveに小さな問題があるようですどのようにそれを得るのか分かりません。

+----+-------------+--------+--------+---------------+---------+---------+-----------------------+------+----------+--------------------------+ 
| id | select_type | table | type | possible_keys | key  | key_len | ref     | rows | filtered | Extra     | 
+----+-------------+--------+--------+---------------+---------+---------+-----------------------+------+----------+--------------------------+ 
| 1 | SIMPLE  | enick | ref | PRIMARY,nick | nick | 92  | const     | 1 | 100.00 | Using where; Using index | 
| 1 | SIMPLE  | efave | ref | inick,isong | inick | 4  | radiosite.enick.id | 12 | 100.00 | Using index    | 
| 1 | SIMPLE  | esong | eq_ref | PRIMARY  | PRIMARY | 4  | radiosite.efave.isong | 1 | 100.00 |       | 
| 1 | SIMPLE  | tracks | ALL | hash   | NULL | NULL | NULL     || 100.00 |       | 
+----+-------------+--------+--------+---------------+---------+---------+-----------------------+------+----------+--------------------------+ 
+1

'tracks'テーブルの' COLLATE'値は何ですか? –

答えて

5

あなたの私には際立っている唯一のことは、esong表は utf8_bin のCOLLATEを使用しているという事実である、きれいに見える、と説明トラックテーブルに照合順序が指定されていないため、おそらく別の照合タイプが使用されている可能性があります。照合順序を調整し、結合の実行方法を確認してください。

+0

これは本当に問題でした。トラックテーブルの照合はutf8_general_ciでしたが、他の3つはutf8_binでした。絶対に素晴らしい。 – Wessie

+0

それはうれしいです。私はutf8_binのコレートをトラックテーブルに追加したとしますか? –

+2

私は最初にトラックにutf8_binを追加しましたが、これにより全文索引で大文字と小文字が区別されました。だから私はそれらをすべてutf8_general_ciに変更しました。 – Wessie

0

実行計画を確認しましたか?そうでない場合は、クエリを実行してクエリを含めます。あなたの右の結合は、インデックスシークの代わりにインデックススキャンを実行している可能性があります。または、インデックスが不足している可能性があります。いずれにしても、クエリを最適化できるように実行計画を確認する必要があります。本当の問題が何であるかを知るまでは、右結合(または結合)を使用してそれをより速くする方法を誰もあなたに教えることはできません。ここではいくつかのリンク.. MySQLの です:http://dev.mysql.com/doc/refman/5.5/en/execution-plan-information.htmlのSQLServerの場合 :http://www.sql-server-performance.com/2006/query-execution-plan-analysis/

+1

質問には実行計画があります - 最後の説明出力です。 – piotrm

+0

申し訳ありませんが、私はそれが実行計画の結果であることを認識していませんでした。私もチェックしていない - 私はあなたのクエリ自体の結果だと思った。私にチェックさせてください。 –

関連する問題