2011-12-05 15 views
1

データベースサーバーはMicrosoft SQL Serverですが、管理者権限はありません。 したがって、どのバージョンがわかりませんか、どのインデックスが存在するのかわかりません。誰でもこのSQL文を最適化できますか?

データベースにアクセスするために、私はADOを使用しています。ここで

は、SQL文は次のとおりです。

-- Get master objid and order_number and activity time 
SELECT A.objid, 
     A.order_number, 
     F.entry_time 
-- From these tables 
FROM dbo.table_master as A, 
     dbo.table_activity as F 
-- link of the tables 
WHERE F.objid = A.objid 
     -- Retrieve code = 1900 only 
     AND F.code = 1900 
     -- Which have info like this: 
     AND F.info LIKE '%to SUPPORT.' 
     -- And entry time between these times: 
     AND F.entry_time >= '2011-10-01 00:00:00' 
     AND F.entry_time <= '2011-12-05 23:59:59' 
-- We want the earliest entry (because there might be multiple code = 900 and info like) 
ORDER by F.entry_time 

が、それは、これを最適化することは可能ですか?

ありがとうございました

+0

特に遅いですか?クエリプランを表示できますか?また、これはSQLのどんな風味ですか(SQL Server、MySQLなど)? – jadarnel27

+0

SSMSからデータベースにアクセスしようとしましたか? –

+0

@ jadarnel27:OPはこれがSQLServerだと言った。 –

答えて

2

ここでは、あなたが違っ何ができるものは以下のとおりです。

  • 使用RIGHT(f.info, 11) = 'to SUPPORT.'代わりにF.info LIKE '%to SUPPORT.'
  • @xQbert代わりの組み合わせの日付範囲の
  • 使用BETWEENを示唆としてINNER JOINを使用および>

私のテストでは、パフォーマンスに差をつけた唯一のものが最初のオプションでした。 3つの項目すべてで同じ実行計画が生成されますが、RIGHT関数は実際の実行時間の点でテストで約10倍速くなりました。私はSTATISTICS TIMEを使ってテストしています。

可能であれば、私はインデックスを見るためにアクセスしようとします。テーブルを適切に索引付けすると、RIGHTファンクションより大きな違いが生じます。

+0

ありがとうございます。他のユーザーから、クエリが最適化するのが難しいということは多くの情報(インデックス)ではなく、あなたのRIGHT()が少し助けてくれると思います。 – ewlung

0

これは同じことを書く別の方法です。結合の性質と間の使用のために、より速い性能の が得られるかもしれません。また、結合基準に制限を設けて、%toの前に評価を強制します。これにより、%to SUPPORTが評価されるときにより小さいサブセットで作業します。

SELECT A.objid, A.order_number, F.entry_time 
FROM dbo.table_master as A 
INNER JOIN dbo.table_activity as F 
    ON F.objid = A.objid 
    AND F.code = 1900 
    AND F.entry_time BETWEEN '2011-10-01 00:00:00' AND '2011-12-05 23:59:59' 
WHERE 
F.info LIKE '%to SUPPORT.' 
ORDER by F.entry_time 

EDITED 1番目のコメントの後。

+2

変更してもパフォーマンスにはまったく影響しません。 –

+0

これはパフォーマンス上も少し改善されています。私はLIKEをRIGHT()を使うように変更しました。ありがとう! – ewlung

1

インデックスがないから、文字列の先頭から一致させるためにのみ機能するので、私の知る限りでは、クエリの最悪の部分とも容易に最適化することができない部分は、

AND F.info LIKE '%to SUPPORT.' 

です終わり。

パフォーマンスを向上させたい場合は、おそらくこれを回避する方法を見つける必要があります。

(。。ああ、ちょうどこの回答はMySQLの100%正しいだろう、それはMySQLのではありません実現が、私はそれが一般的なデータベースエンジンのほとんどのために正しいことを期待する)

+0

すべてのインデックスが該当します。索引を並べ替えることを考えた場合(リストやツリーとしても問題ではありません)、最後の文字はすべての先行する文字が別の項目と一致する場合にのみ重要です。本質的に、この文字列の尾の視点を形成するアイテムの順序は事実上ランダムです。これは、インデックスが役に立たず、テーブル全体がスキャンされることを意味します。 – MatBailie

+0

しかし、私が知っている限り、逆のインデックスを作成して文字列を逆にすることができます。これはまさにこのような場合に使用されます。 – Flo

関連する問題