- ベストアンサー
時間のかかるqueryの対処法
- 特定のクエリが遅いことが分かりました。テーブルの構成やデータ量を考慮した上で、より高速な結果を得るためにはどのようなqueryを使用すれば良いでしょうか。
- 現在のqueryでは、25万件のデータ全体をチェックしてしまっているため、時間がかかってしまっています。もっと効率的な方法で結果を得るためには、どのような改善策がありますか。
- shoptableとgoodstableの結合queryで、categoryが2のお店の商品を日付順に100コ目以降から10コだけ表示したいのですが、現在のqueryでは結果が表示されるまでに時間がかかってしまいます。よりスムーズな結果を得るためには、どのようなqueryを使用すれば良いでしょうか。
- みんなの回答 (3)
- 専門家の回答
質問者が選んだベストアンサー
ANO.2です。 >ただ、店舗や商品の数が今後も増えていくのですが、その都度、インデックスを張りなおさないといけないのでしょうか。 インデックスは、店舗や商品を増やすたびに更新されます。 要は、インデックスを作ると、テーブルに対する追加・更新・削除のときに、 インデックスも更新されるので、テーブルに対する追加・更新・削除が遅くなる。 (但し、今回みたいに1種類や2種類増やしたところで、人間の目では遅くなったことはわからないでしょう。) そのかわりに検索処理のときにインデックスを使って検索するので非常に早くなる。 ということです。 スロークエリログの件は・・・私はちょっとわからないです。 (スロークエリログを使ったことがないので。) 他の方が回答してくれるかも。。。
その他の回答 (2)
- Siegrune
- ベストアンサー率35% (316/895)
create index ix1_shoptable on shoptable(category,id) と create index ix1_goodstable on goodstable(shopid,id) を作るだけでずいぶん早くなるような気がします。
お礼
たびたび申し訳ありません。 同じクエリにも関わらず、explainで見たときのrowsとスロークエリログに出力されたrows_examinedの値が全然異なっていました。 explainでみると、keyには先程作成したインデックスがちゃんとあり、rowsは2000ぐらいの値でした。 しかしスロークエリログだと # Query_time: 8 Lock_time: 0 Rows_sent: 10 Rows_examined: 327174 このように出力されていました。 この違いは何が原因なのでしょうか。
補足
すごく早くなりました! ありがとうございます。 ただ、店舗や商品の数が今後も増えていくのですが、その都度、インデックスを張りなおさないといけないのでしょうか。 それとも自動でインデックスは増えていくでしょうか。
- yambejp
- ベストアンサー率51% (3827/7415)
explainするときにselect * from・・・をすると 全てのカラムがインデックスされていない限りインデックが有効には ならないでしょう 抽出したいカラムを列記し、適切なインデックスをはってください もしかしたら select * from goodstable as g inner join shoptable as s on g.shopid = s.id and category='2' order by g.date desc LIMIT 100,10; の方が若干効率的かもしれません
補足
ありがとうございます。 教えて頂いたクエリーで試したところ、おっしゃるとおり若干早かったです。 2.22secが1.99secになりました。 できれば1sec以下にしたいのですが、難しそうですね。 抽出したいカラムはshopname,area,goods,dateになります。 インデックスは具体的にどのようにはったらいいのでしょうか。 explainでみたときExtraにusing filesortがあったのですが、これがあるとorder byにインデックスを使用できないと書いてありました。 create index shopname on shoptable(shopname); create index area on shoptable(area); create index goods on goodstable(goods); create index date on goodstable(date); こんな感じでいいのでしょうか?
お礼
インデックスの件、ありがとうございました。 とても分かりやすい説明でありがたかったです。