1

みなさんこんにちは:)パフォーマンスの問題のために、ネストされたクエリをネストしたままにする必要があることをOracleに理解してもらう必要があります。

クエリは次のとおりです。

SELECT * FROM (
  SELECT 
    UTL_MATCH.JARO_WINKLER_SIMILARITY(clients_me.address, clients_them.address) jw,
    clients_them.*,
    clients_me.* 
  FROM clients_them JOIN clients_me ON clients_me.email = clients_them.email
) WHERE jw > 80

パフォーマンスは最後の なしで問題ありませんWHERE jw > 80。私の理解では、Oracle はネストされたクエリ内の結合に JARO_WINKLER_SIMILARITY を追加しようとしています。いくつかの悪い一致をフィルタリングしたいだけです。

よろしくお願いします

4

2 に答える 2

1

NO_QUERY_TRANSFORMATION、または多分NO_PUSH_SUBQまたはなどのヒントを入れてみてくださいNO_MERGE。（私はヒントの専門家ではありません。また、ほとんどの場合、ヒントを避けるのが良いと思います）。

http://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements006.htm#BABCGJDI

しかし、IMHO、最善の方法は、パフォーマンスの悪いクエリの実行計画を取得することです。これにより、期待どおりに何が起こっていないかを知ることができます。

于 2013-03-11T19:35:07.670 に答える
1

Push_pred / no_push_pred: クエリにマージ不可能なビュー (no_merge ヒントが原因である可能性があります) がある場合、他のテーブルからの結合をどのように操作する必要がありますか? 1 つの大きなビュー結果を作成して 1 回結合するか (no_push_pred)、結合述語をビュー定義にプッシュして、別のテーブルからの駆動行ごとにビュー結果セットを再作成するか (push_pred)。

これは、no_merge に対してのみ push_pred が有効であることを意味します。
以下のようにヒントを追加してみてください： 

/*+ no_merge(y) no_push_pred(y) */
于 2013-03-14T05:52:23.083 に答える