0

注文をプルする目的で、スキャン/入力された注文番号に基づいて注文情報をプルするPHPアプリケーションがあります。Pervasive SQLを使用していますが、構文はMSSQLと同じです。

キットアイテムを必要に応じて呼び出されるコンポーネントアイテムに分解するために使用される小さなクエリがいくつかありますが、それらはシンプルで実行が高速です。私の問題は、最も必要な情報が詰め込まれているメインクエリです。比較的小さい（1〜15アイテム程度）ため、ほとんどの注文で高速です。私の問題は、100以上のアイテムになる可能性のある大量注文（卸売など）にあります。

必要な情報が多ければ多いほど、クエリの実行に時間がかかることはわかっていますが、クエリにさらに最適化する余地があることを望んでいます。

次のクエリで、大量注文の処理を高速化するために最適化できるものを見つけた人はいますか？

SELECT 
    oeordh.orduniq, 
    oeordh.customer, 
    oeordh.ordnumber, 
    oeordh.orddate, 
    oeordh.salesper1, 
    oeordd.orduniq, 
    oeordd.item, 
    oeordd.pickseq, 
    oeordd.location, 
    oeordd.origqty, 
    arcus.idcust, 
    arcus.idgrp 

FROM oeordh 
    INNER JOIN oeordd ON oeordh.orduniq = oeordd.orduniq
    INNER JOIN arcus ON oeordh.customer = arcus.idcust

WHERE 
    oeordh.ordnumber = '".$_POST['barcode']."' 

ORDER BY oeordd.pickseq`
4

2 に答える 2

1

それ以上のことはできません。検索するすべての値（結合を含む）にインデックスがあり、すべてのアイテムに対してクエリを実行しないことを確認し、すべてのアイテム（に関連する）をリクエストするようにしてください。現在のページ）を同時に実行し、クライアント側で処理します。

基本的に、これはクエリの問題ではなく、クエリ結果またはデータベース設計（またはネットワーク）を使用するコードのいずれかですが、ほとんどの場合、制御できません。

そのコード行の明白なセキュリティホールについても言及する必要があると思いますが、それはたくさんあると思います。

編集：私は実際に何かを考えました。それらのフィールドがそうでない場合は、すべての列の最後に数千、数千（またはそれ以上）のスペースを送信するのではなく、サーバー側に配置するvarchar必要があります。rtrim()

于 2012-02-29T15:29:45.553 に答える
1

あなたはおそらくそれより良くなることはできません。データベースコースの私の教授はかつて「賢くなろうとしないでください。RDMSは最適化に優れています」と言っていました。1つを除いて、RDMSは自動的にインデックスを設定しません。したがって、ソート、結合、および選択（「where」句のように選択）するフィールドにインデックスがあることを確認してください。

于 2012-02-29T16:37:11.060 に答える