なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ

今月下旬に、J.セルコの『Trees and Hierarchies 2nd Edition』の邦訳が刊行されます。同著者の代表作『プログラマのためのSQL 第4版』のスピンオフの一つで、RDB/SQLで木と階層構造を扱うための方法論にフォーカスしたなかなかマニア度の高い一冊です。主眼となる「入れ子集合モデル」については、私もあちこちの記事や書籍で紹介したことがあるので、ご存じの方もいるかもしれませんが、より包括的かつ理論面までカバーした本格派の内容になっています。 表紙の女性はマリア様でしょうか。本家の方が刊行されたときも「このおっさん誰？」という質問が相次ぎましたが、ガリレオという説が有力なようです。そう言われてみると本家は『星界の報告』のような格調を感じます。本書の方は、長らく定説とされてきたモデルをひっくり返そうという意味では『天体の回転について』みたいな性格もあるのですが、大型本

平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識

前回の記事で少し触れましたが、 go-sql-driver/mysql にドライバ側でのプレースホルダ置換を実装するプルリクエストを出していました。 それがマージされたので、背景のおさらいと利用方法を紹介しておきます。 背景 Go の database/sql の概要については前回の記事で解説しました。 そこで説明したとおり、 DB.Prepare() を使わずに直接 DB.Exec() や DB.Query() を使った場合、 ドライバ側でのプレースホルダ置換に対応していないドライバでは prepare, exec, close で3回のラウンドトリップが発生することになり、パフォーマンスが悪くなります。 基本的には DB.Prepare() を使えばいいのですが、前回の記事で修正したスケーラビリティの問題は Go 1.5 になるまで直りませんし、 IN 句があるSQL文などで事前に P

Golangが一番パフォーマンスが良いかと予想していましたが、全く逆の結果になってしまいました。 Golangが遅い理由 遅い原因をいくつか考えて改善できないか試してみました。詳細は省きますが、以下の点については問題なさそうでした。 goroutineはリクエスト単位で起動している コネクションプールは有効になっている BeegoのORM特有の処理は主原因ではない(標準ライブラリのsql関数と大差なし) DB側のCPU使用率は100%になっているが、CPU使用率とメモリ使用量はPHP環境と同程度の負荷になっている ここまで確認して、プロファイラを使った方が良さそうに思えたので、いったんプロファイラで状況を確認するために、標準で提供されていて手軽に使えそうなpprofを使ってみました。topで確認すると次のような結果がでました。 (pprof) top 20 -cum 920ms of 15

米Facebookは3月27日、米Google、米LinkedIn、米Twitterと「Web Scale SQL」プロジェクトを立ち上げたことを発表した。大規模環境での運用に向けてMySQLの拡張性と性能を強化するというプロジェクトで、「MySQL 5.6」をベースとした初回バージョンも公開した。 Web Scale SQLはFacebook、Google、Twitter、LinkedInのMySQL開発者が立ち上げたプロジェクト。4社はオープンソースのデータベースであるMySQLを使用して大規模なシステム向けの拡張性と性能を実現したいという共通の課題を抱えており、協業に至った模様。中でもFacebookは12億3000万人のユーザーを抱えており、世界最大規模のMySQL環境を運用しているという。オープンソースプロジェクトとすることで、スケール主導のMySQLコミュニティとのコラボレーシ

photo by byte MySQLといえば、巷ではInnoDBばかり注目され、MyISAMの地下アイドル化がにわかに語られる今日この頃、皆様いかがお過ごしでしょうか。 まあカジュアルにストレージエンジンを変換するだけで済むなら、簡単なのです。 -- legacy_my_tableをInnoDBストレージエンジンに変換する ALTER TABLE legacy_my_table ENGINE=InnoDB; よし終わった！さあランチタイムだ！ ・・・と片付けてしてしまうと、悲劇が起こるかもしれません。(>o<;) それでは本日、MyISAMからInnoDBへ移行するなら知っておきたい意外な落とし穴とTipsを紹介します。 AUTO INCREMENTの挙動が違う落とし穴 以下に該当するクエリを利用している場合には、注意が必要です。私はハマりました。 INSERT IGNORE INTO

http://blog.fusic.co.jp/archives/1765 ↑postgresの記事ですが、mysqlでも同様に実行できました。 SELECT * FROM test_table WHERE (col,co2) IN -- 複数のカラムを指定 (SELECT subcol1,subcol2 -- 副問いの戻り値も複数のカラムを指定 FROM subtable WHERE id > 10 ) 知らなかったなんて、お恥ずかしい ※手元にあるmysqlはv.5.1.61ですが、v.4.1から使えるらしい sqlの仕様として、mysqlのdocでは分かりませんでしたが、sql99から利用可らしい http://dev.mysql.com/doc/refman/5.1/ja/comparison-operators.html ↑では、分かりませんでしたが、次のurlよれば、sql99

6. id name pass is_deleted 1 ryu xxx FALSE 2 ken xxx FALSE 3 honda xxx TRUE 8. id name pass is_deleted 1 ryu xxx FALSE 2 ken xxx FALSE 3 honda xxx TRUE 3 honda xxx FALSE

データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

OSC 2011 Hokkaidoの発表で使用したスライド資料です。 弊社が「ブラウザ三国志」や「英雄クエスト」といったゲームを、PHP＋MySQLで構築してきた上で、身につけたノウハウや、注意すべき箇所、指針などをまとめた資料となっています。Read less