1

がなくても以下のクエリorder byは非常に遅く、その理由がわかりません。だと思いwhere date_affidavit_fileますが、どうすればそれを速くすることができorder byますか？おそらく、where に一致する job_id のサブレクトで、それを残りのコードに渡しますが、サーバーごとにこのようにサーバー名を注文する必要があります。助言がありますか？

explain select sql_no_cache court_county, job.id as jid, job_status,
    DATE_FORMAT(job.datetime_served, '%m/%d/%Y') as dserved , 
    CONCAT(server.namefirst, ' ', server.namelast) as servername, client_name,
    DATE_FORMAT(job.datetime_received, '%m/%d/%Y') as dtrec ,
    DATE_FORMAT(job.datetime_give2server, '%m/%d/%Y') as dtg2s, 
    DATE_FORMAT(date_kase_filed, '%m/%d/%Y') as dkf, 
    DATE_FORMAT(job.date_sent_to_court, '%m/%d/%Y') as dtstc ,
    TO_DAYS(datetime_served )-TO_DAYS(date_kase_filed) as totaldays from job
    left join kase on kase.id=job.kase_id 
    left join server on job.server_id=server.id
    left join client on kase.client_id=client.id
    left join LUcourt on LUcourt.id=kase.court_id 
    where date_affidavit_filed  is not null and date_affidavit_filed  !='' order by servername;

+----+-------------+---------+--------+----------- -----------+---------+---------+------------------ ---+--------------------+----------------------------------- -----------+
| | ID | select_type | テーブル | タイプ | 可能な_キー | キー | key_len | 参照 | 行 | 行 エクストラ |
+----+-------------+---------+--------+----------- -----------+---------+---------+------------------ ---+--------------------+----------------------------------- -----------+
| | 1 | シンプル | 仕事 | 仕事 | すべて | date_affidavit_filed | ヌル | ヌル | ヌル | 365212 | where を使用します。一時的な使用; ファイルソートの使用 |
| | 1 | シンプル | 加瀬 | eq_ref | プライマリ | プライマリ | 4 | pserve.job.kase_id | 1 | | |
| | 1 | シンプル | サーバー | eq_ref | プライマリ | プライマリ | 4 | pserve.job.server_id | 1 | | |
| | 1 | シンプル | クライアント | eq_ref | プライマリ | プライマリ | 4 | pserve.kase.client_id | 1 | | |
| | 1 | シンプル | ルクール | eq_ref | プライマリ | プライマリ | 4 | pserve.kase.court_id | 1 | | |
+----+-------------+---------+--------+----------- -----------+---------+---------+------------------ ---+--------------------+----------------------------------- -----------+
4

4 に答える 4

1

これにより、次の方法で注文を高速化できます。

CREATE INDEX namefull ON server (namefirst,namelast);

ORDER BY (server.namefirst, server.namelast)の代わりに行うORDER BY servernameと、同じ出力が生成されます。

結合したままのフィールドの各テーブルにインデックスを作成することもできます。これにより、クエリのパフォーマンスも向上します。

于 2012-09-13T15:02:54.860 に答える
1

次の列にインデックスがあることを確認してください。job.kase_idまたjob.server_id

また、最適ではない計算フィールドで注文しています。おそらく、インデックス付きのフィールドで並べ替えます。

その正確な並べ替えを保持する必要がある場合は、その値のフィールドを DB に追加することをお勧めします。そして、適切な値を入力するか、DB にトリガーを設定して自動的に入力します。

于 2012-09-13T14:48:40.307 に答える
0

あなたが書くとき、

where date_affidavit_filed  is not null and date_affidavit_filed  !=''

実際にはほとんどの行を選択しています。または、少なくともインデックス作成を実行する価値がないほど多くの場合。クエリ プランナーは、 を含むインデックスがあるdate_affidavit_filedことを確認しますが、それを使用しないことに決定し、 のみを含む WHERE 句を使用しますdate_affidavit_filed。これは重要な問題ではなく、カーディナリティの問題であることがわかっています。

|  1 | SIMPLE      | job     | ALL    | date_affidavit_filed | NULL    | NULL    | NULL                  | 365212 | Using where; Using temporary; Using filesort |

インデックスを作成することで、これを最適化することができます

date_affidavit_filed, kase_id, server_id

その順序で。クエリによって返される行数は?

于 2012-09-13T14:50:31.620 に答える
0

空ではないものをすべて選択しています。それは本当にすべてを意味します。何行のデータがあるかわかりませんが、処理するのは大変です。

クエリを日付範囲または特定のクライアントに絞り込んでみてください。

本当にすべてが必要な場合は、一度に 1 行ずつ出力するのではなく、すべてのフォーマットで出力するために使用するソフトウェアで大きな文字列を作成し、結果のループを終了して、出力したいデータをまとめて出力できます。

ページングを使用することもできます。limit 0,301 ページ目、 2 ページ目などに追加するだけlimit 30,30で、エンド ユーザーにページを見てもらうことができます。

于 2012-09-13T15:02:05.100 に答える