タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

sqlに関するseikoudoku2000のブックマーク (2)

  • SQLを実行する時、SQLに実行場所を追記する - パルカワ2

    ISUCONのPerlアプリでよく使用されているDBIx::Sunnyですが、便利な機能として、SQLがどこで実行されたかを実行されるSQLにコメントする機能があります。 こういう感じでスローログに表示されるので、どこでSQLが発行されているか探す必要がなくて便利です。 SELECT * FROM users /* lib/MyApp/Web.pm line 56 */ アプリケーションログではなく、SQL自体にコメントで入っている事が重要で、SQLを改善したい時に見るのは、アプリケーションログではなくスローログを見ます。スローログを見た時点で、どこで発行されたSQLなのかはっきりしていると無駄にそのSQLがどこで発行されたのか、探す必要がなくなり、実際に集中すべきSQLの改善に集中出来ます。というのを、Railsでもやりたかったので、ActiveRecordで作ってみました。github

    SQLを実行する時、SQLに実行場所を追記する - パルカワ2
    seikoudoku2000
    seikoudoku2000 2015/07/14
    これはナイスなideaだ。
  • RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita

    "Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に

    RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
  • 1