『MySQL初心者に贈るインデックスチューニングのポイントまとめ2014』
サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ＆コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。（何でもそうですけど）インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。
ストアドプロシージャの作成
今回から数回にわたり、ストアドプロシージャの作成に挑戦します。ストアドプロシージャの利用については、前回の「システム・ストアドプロシージャを用いたロールの詳細設定」の中で取り上げました。今度は、Transact-SQLを使用して、ユーザー定義のストアドプロシージャを作成します。 では早速、例題を実行しながら、SQLの確認をしていきましょう。 SELECTを実行するストアドプロシージャ 最初に、非常に簡単なストアドプロシージャを作成してみましょう。作成するのは、Customerテーブルから「顧客ID（CustomerID）」「会社名（CompanyName）」「担当者名（ContactName）」「電話番号（Phone）」を抽出するストアドプロシージャです。クエリアナライザから下記のSQLを実行してみましょう。
ストアドプロシージャの基本的ななにか - Qiita
あんまり知識ないけどがんばる SQLにも存在する様だけど, MySQLでしか経験がないからMySQLで書くよ 対象 以下に該当する方が対象です。 ある程度, SQLクエリが読める ある程度, DBの知識がある 背景 資料を探せど探せど, (個人的に)良いドキュメントが見つからなかったので 『じゃあ書いちゃおう』と思いました。 ※悪い資料だらけってわけじゃないけど, 物足りないとか惜しい記事ばかりだったので。 ストアドプロシージャって？ DB上での一連処理に, 名前をつけて関数のように, 呼び出して使用できるもの。 DB上で動作を完結させちゃうから, 開発言語に依存しないよ！ Ruby とか PHP だとか Perl でも Python だろうと CALL できれば結果は同じになるはずだよ！ 権限まわり 作成
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
CakePHP3にも採用されているマイグレーションツール「Phinx」を使ってみた | 東北ギーク
こんにちは。リスペクトの木村です。 以前に書いた記事、「Vagrant環境で実現するお手軽DBマイグレーション」の中で、「Flyway」というJavaで動作するマイグレーションツールをご紹介しました。 Flywayは言語やアプリケーションを問わず使えたり、生のSQLクエリで記述するので汎用性が高い点が良かったのですが、別途Javaが必要であるとか、up(マイグレーション)はできてもdown(ロールバック)が出来ないという難点がありました。 サイトのリニューアルにあたりマイグレーション周りを整備する必要があったため、難点が解消できるツールを探した所、「Phinx」というマイグレーションツールがありました。 使ってみた所非常に良い感じでしたので、今回はそちらをご紹介します。 今回の環境 CentOS 7 PHP 5.6.14 MySQL 5.7.9 Phinx 0.4.6 What’s Phi
マイグレーション(migration) | Railsドキュメント
class CreateProducts < ActiveRecord::Migration[7.0] def change create_table :products do |t| t.string :name t.text :description t.timestamps end end end class CreateProducts < ActiveRecord::Migration[7.0] def up create_table :products do |t| t.string :name t.text :description t.timestamps end end def down drop_table :products end end カラムをバージョンアップ 説明 データベースのカラムをバージョンアップ upメソッドはロールバックできない処理をする際に主に使用
更新系SQLを手で打つときに気をつけていること
WHERE条件をつけまくる UPDATE user SET age = 35 WHERE id = 1 AND name = 'Songmu' AND age = 34 idだけで絞れるけど name も付けてレビュワーフレンドリー 変更前の値も条件に含める 34 -> 35になることがわかる 間違えていた時も戻せる ユーザー操作とのコンフリクトを検知 万が一履歴から誤爆しても更新されない(可能性が高い) SETとWHEREを一行にまとめてるのは変なところで小指が滑るのが怖いため WHERE条件応用編 UPDATE user SET weapon_id = (SELECT id FROM weapon WHERE id = 100 AND name = '村正') WHERE id = 1 AND name = 'Songmu' AND weapon_id = (SELECT id FRO
【SQL入門】group by,distinctどちらが性能がよいのか - 新卒から文系エンジニア→人材業界に転職した人のブログ
【今回の内容】 前回は基本的なＳＱＬを備忘録で簡単にまとめていたけど、 【SQL入門】基本的なSQLを目的別にまとめてみた - ＦＯＲ ＳＥ その中に気になることがあったので調べたものをメモとして紹介します。 今の自分の現場では、重複行を絞り込む時に、「distinct」と「group by」を使う人それぞれいました。 distinctとgroup byは同じように重複行を消すという意味では どちらでもいいのかなーと思っていたけど、 疑問に思ったので少し調べてみました。 【疑問】distinctとgroup by は重複行を消す目的ならどちらを使ってもよいのか？ 【結論】 結果としてはどちらも重複行を消すという意味では同じらしい。 だが、一般的にgroup byは集合関数（sumとかcountとか）と一緒に使うので、 そもそもの目的用途が違うのではという話があった。 また、どちらが性能が良
論理削除 Casual Talks #1 で「論理削除しない」という話をしました - moroのブログ
互いの前職での先輩後輩である @kenchan と企画した論理削除 Casual Talks #1で、「論理削除しない」という話をしてきました。 話す内容が各話者で面白いほどかぶっていたのでなかなか大変でしたが、普段から言っている「論理削除するな」「削除じゃないからちゃんと機能を設計しましょう」という内容を話してきました。 他の方の話も、かぶっているようで新しい視点もあって、いち参加者としてもたいへん勉強になりました。
5章 EAV (エンティティ・アトリビュート・バリュー) - Qiita
このようなクエリには、2つの前提条件が必要 値が同じ列に格納されていること 例: Bugs.date_reported GROUP BY で正確に日付をグループ化するために、値が比較できること Bugs.date_reported のフォーマットが揃っている必要がある EAV (エンティティ・アトリビュート・バリュー) と呼ばれるアンチパターンを用いていると、上記の前提条件が成立しない問題に遭遇する 日付が行によって違う列に格納されている 例: date_reported, report_date 日付のフォーマットが異なり、簡単には比較できない 5.1 目的: 可変属性をサポートする バグデータベースの例 Issue (問題) を基底型として、Bug と FeatureRequest (機能要望) のオブジェクトを管理する Issue 基底型 - 共通の属性 Date_reported:
PDOの真の力を開放する - PHPでデータベースを扱う(3)
ちょっと遅れましたが、シリーズの第３回です。前回までに論じた内容をふまえて、簡単な実装を示します。↓前回までの内容はこちら。 DAOの悪夢 - PHPでデータベースを扱う(1) - 泥のように ドメイン駆動設計という救世主 - PHPでデータベースを扱う(2) - 泥のように 題材 「記事にタグを設定できるブログ」みたいなシステムを考えてみます。ブログ記事を示すEntryテーブル、タグを表すTagテーブルの二つを用意しました。MySQL WorkbenchによるER図(鳥足記法)は以下になります。 1つのEntryに対して複数のTagがある、１対多の関係です。同じTagが複数のEntryに関連するため、多対多の関係と見なすこともできそうですが、タグ程度だとあまり意味がないので、これ以上のテーブル分割はやめておきます。 Entryテーブルの主キーがentryIdと冗長な名前をしているのは、自
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Readings in Database Systems, 5th Edition
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
リレーショナル・データベースの世界