2010-12-06 19 views
3

我々は、SYSMANはの世話をする
(例えば、MAC登録、メールの活性化、などなど)内部要求
ためのシンプルなチケットシステムを持っています。
基本的な構造は以下です:MySQLの複雑当社で

テーブルチケット

  • UID(整数)
  • issued_by(列)
  • issued_on(日時)
  • ticket_type(列)

の表は

  • UID(整数)
  • ticket_uid(整数でなく、外部キー)
  • パラメータ(列)
  • parameter_content(列)

チケットとをticket_params目的の観点から、異なるパラメータを有することができる。
MACアドレスの要求には、"mac_1", "mac_2", "expiry", "model" and "comment"パラメータがあります。

このすべてのデータを提供するクエリが必要でした。 「!あなたがより良い行うことができますどのように困難なので、単純な作業のために、このクエリを見て?」私に言った、その後、いくつかの研究と過ごした時間で

select tickets.uid, tickets.issued_by,tickets.issued_on, 
(select parameter_content from ticket_parameters where parameter="Model" and 
ticket_uid=tickets.uid) "model", 
(select parameter_content from ticket_parameters where parameter="Comments" 
and ticket_uid=tickets.uid) "comments", 
(select parameter_content from ticket_parameters where parameter="mac_1" and 
ticket_uid=tickets.uid) "mac1", 
(select parameter_content from ticket_parameters where parameter="mac_2" and 
ticket_uid=tickets.uid) "mac2", 
(select parameter_content from ticket_parameters where parameter="Expiry" 
and ticket_uid=tickets.uid) "Expiry" from tickets; 

:私の同僚は、このいずれかを思い付きます上(

select 
    tickets.uid, 
    tickets.issued_by, 
    tickets.issued_on, 
    f.parameter_content as Model, 
    e.parameter_content as Comments, 
    b.parameter_content as mac_1, 
    d.parameter_content as mac_2, 
    c.parameter_content as Expiry 
from 
    tickets, 
    ticket_parameters as b, 
    ticket_parameters as c, 
    ticket_parameters as d, 
    ticket_parameters as e, 
    ticket_parameters as f 
where 
    tickets.uid=b.ticket_uid AND b.parameter='mac_1' 
    AND 
    c.ticket_uid=tickets.uid AND c.parameter='Expiry' 
    AND 
    d.ticket_uid=tickets.uid AND d.parameter='mac_2' 
    AND 
    e.ticket_uid=tickets.uid AND e.parameter = 'Comments' 
    AND 
    f.ticket_uid=tickets.uid AND f.parameter = 'Model' 
    ; 

結果が両方とも正しく表示されますが、鉱山の実行には2秒かかった:

私は挑戦を取り、私の心に来る最初の、より簡単なことを書き始め、これが結果です1000のチケット入力テーブル)、私の同僚のものは47秒かかりました。最初の視点では私の違いはそれほど明白ではなかったが、私はなぜこの巨大な違いがあるのか​​を知ることができなかった。

あなたの意見は?そして、その横に、この種の問題についてのドキュメントはどこにありますか?

+4

@Enrico Carlesso - ダムのルール - 'EXPLAIN EXTENDED YOUR_SLOW_QUERY; ' – ajreal

+1

あなたはticket_uid、tickets.uidの列にインデックスを付けましたか?これらの列にインデックスを付けない場合は、時間を再度測定します。あなたは驚きを感じるかもしれません。しかし、クエリがあなたのインデックスを使用している場合、 'explain'を実行してください。 – cristian

+0

ありがとうございます。 EXPLAINステートメントについて本当に知りませんでした...非常に便利です!しかし、それは私に非常によく分かりません。と@Octopus、私はテストしようとするかもしれませんが、それは従来のデータベースなので、私はそれが生産で行われるかわからない!とにかく良いヒント。 –

答えて

2

EXPLAIN EXTENDED ...は、クエリが生成したデータアクセスパスの違いを表示します。 mysqlは彼らとのより良い仕事をしていませんが、

この場合、理由はそれがために使用、サブクエリが、サブクエリは多くの面でのMySQLの異なるている(とMySQLはそれらを扱う方法についていくつかの矛盾があります)。

EDIT

ここ5用restrictionsのリストです。0

+0

+1を使用したJOINは、ほとんど常にサブクエリよりも高速です。 – Konerak

+0

@Konerak、はい、ほとんど逆です。しかし、プランナーの不完全性のせいでまだ起こる可能性があります。 – Unreason

+0

私は言われたので、私は "ほとんど常に"を追加しました。それでも、私に例を示すことができれば、私は感謝しています:) – Konerak