SQL文を最適化しましょう！解決方法

SQL文を最適化しましょう！

SQL コード

<!--

Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/

-->
select a.id,b.id as mycompid,b.typeid,b.co_end,a.pro_price,
a.pro_name as realproname,a.discount_rate,a.bigpic,a.temp_url,b.co_name,
c.pro_name,d.city_name,a.begindate,a.modifydate,a.pro_intro 
from product a 
left join company b on(a.userid=b.id) 
left join pro c on(b.proid=c.id) 
left join city d on(b.cityid=d.id) 
left join protype e on(a.typeid=e.id) 
where (a.pro_name like binary '%%' or a.pro_intro like binary '%%' or a.keywords like binary '%%') 
and co_type=112 and b.islock=0  and a.isdel=0 and a.comp_state=1 and b.islock=0 order by b.realtypeid desc,a.modifydate desc limit 0,20

この文を簡単に説明します。検索製品リスト表示ページです。製品製品テーブル レコード 60,000 会社はエンタープライズ テーブル レコード 40,000 プロです。は州情報、市は都市情報、プロトタイプは製品分類情報、

は主に検索結果を企業のレベルで並べ替え、同じレベルの場合はリリースで並べ替えることを望んでいます。製品の開発に時間がかかるため、この SQL ステートメントを作成しましたが、実行には推定 6 秒かかります。

主な理由は、b.realtypeid desc による順序です。 .modifydate desc

しかし、この並べ替えは必ず行う必要があります。どうすればよいかアドバイスをお願いします。 ～

-----解決策----------------------------
通りすがりながら学び、専門家からの指導を求めます
------解決策---------
見てみましょう
------解決策---------
データ量が比較的多い場合は、バッチに分割することをお勧めします。データを取得してください

これが速いか試してください
mycompid、b.typeid、b.co_end、a.pro_price、a として a.id、b.id を選択してください製品 a、会社 b、プロタイプ e の realproname、a .discount_rate、a.bigpic、a.temp_url、b.co_name、c.pro_name、d.city_name、a.begindate、a.modifydate、a.pro_intro としての .pro_name
left join pro c on(b.proid=c.id)
left join city d on(b.cityid=d.id)
where a.userid=b.id and a.typeid=e .id および (a. pro_name のようなバイナリ '%%' または a.pro_intro のようなバイナリ '%%' または a.keywords のようなバイナリ '%%') および co_type=112 および b.islock=0 および a.isdel=0および a.comp_state=1 および b.islock=0 b.realtypeid desc,a.modifydate desc 制限 0,20

で並べる
------解決策---------
2 つの b.realtypeid,a.modifydate 列を指定します。インデックス作成..
-----解決策---------
ビューの使用をお勧めします。
------解決策----------------------
データが大きすぎる場合は、段階的に解決してくださいステップを実行してPHPを使用する処理は悪くありません、それを説明してください。
------解決策----------------------
セグメント化されたインデックスのソートは非常に遅いです。
------解決策----------------------
あなたの問題は左結合によって引き起こされます
それこのような大量のデータ テーブルに対して連続左結合を実行するには大きすぎます。 。 。
------解決策----------------------
条件インデックスで一般的に使用されるフィールドを追加してみてください
------解決策---------
(a.pro_name like バイナリ '%%' またはa.pro_intro のようなバイナリ '%%' または a.keywords のようなバイナリ '%%')

これは何を意味しますか? ?