2
ネストセットモデルで使用するインデックスを理解する際に問題が発生しています。クエリは次のとおりです。ネストセットインデックスとパフォーマンス
SELECT `node`.`id`,(COUNT(parent.id) - 1) AS `depth`,`name` FROM `categories` AS `parent`
INNER JOIN `categories` AS `node` ON (`node`.`lft` BETWEEN parent.lft AND parent.rgt)
INNER JOIN `filebank_categories` ON (`node`.`id` = `filebank_categories`.`category_id` AND `filebank_categories`.`filebank_id` = 136)
INNER JOIN `categories_names` ON (`categories_names`.`category_id` = `node`.`id` AND `categories_names`.`language_id` = 1)
WHERE `node`.`system_id` = parent.system_id
GROUP BY node.id
ORDER BY `node`.`lft` ASC
このクエリはcategories
に~~ 5000行を持つ350msのを取ります。 EXPLAINこの与える:これを改善する方法を
CREATE TABLE `categories` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`system_id` int(11) DEFAULT NULL,
`lft` int(11) DEFAULT NULL,
`rgt` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `lft,category` (`lft`,`id`),
KEY `cat,lft,rgt` (`id`,`lft`,`rgt`),
KEY `system` (`system_id`),
CONSTRAINT `categories_ibfk_1` FOREIGN KEY (`system_id`) REFERENCES `systems` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=11519 DEFAULT CHARSET=utf8;
任意のアイデア:
1 SIMPLE filebank_categories ref fk_filebank_categories_categories1,filebank_id filebank_id 5 const 474 Using where; Using temporary; Using filesort 1 SIMPLE node eq_ref PRIMARY,lft,category,cat,lft,rgt,system,id,lft,system PRIMARY 4 filebank_categories.category_id 1 1 SIMPLE parent ref lft,category,system system 5 node.system_id 50 Using where 1 SIMPLE categories_names eq_ref PRIMARY,fk_categories_names_categories1 PRIMARY 8 node.id,const 1 Using where
テーブル構造を?それも可能ですか?私はデータベース最適化にあまり経験がありませんので、ここでどのインデックスを使用するのか(そしてその理由は何か)は本当に分かりません。
ありがとうございました。
+1、古いKEY '猫、LFT、rgt'を'id'、' lft'、 'rgt')は比較のために役に立たなかった。また、あなたのキーの名前にカンマを使用することを止めたいかもしれません - クエリプランの可能なキーを面白い演習で読むことができます。 – Unreason
ありがとう!これは約100ミリ秒後に実行されます。しかし、私はまだ、 "一時的な使用"、 "filesortを使用する"、 "ファイルバンクのカテゴリ"を取得しています。 –
filesortは問題ありません(filesortの名前はあまり正確ではありません)、一時的な使用はグループ化によって引き起こされます – ajreal