SQLの達人への道: MySQLでの高速・効率的クエリ作成術 - Qiita
データベースとテーブルの作成 テスト用のデータベースtestdbを作成し、パフォーマンスチューニングを検証するためのcompanyおよびpersonテーブルを定義します。 CREATE DATABASE testdb; USE testdb; CREATE TABLE company ( company_id INT AUTO_INCREMENT PRIMARY KEY, company_name VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE person ( person_id INT AUTO_INCREMENT PRIMARY KEY, company_id INT, person_name VARCHAR(255) NOT NULL, email VARCH
MySQLでUUIDv4をプライマリキーにするとパフォーマンス問題が起きるのはなぜ？（N回目）
はじめに こんにちは、令和トラベルでバックエンドエンジニアをしている飯沼です。 MySQLでは、UUID (v4)などのランダム性の高いIDをプライマリキーに設定すると、パフォーマンスが低下すると言われています。私自身もこの問題については認識しておりアンチパターンとして避けて来ましたが、イマイチ理由を理解できず何度も調べていたので自分の理解を整理しました。 ※ この記事は令和トラベルのTech LT会で共有した内容を記事にしたものです。社外の方にもご参加いただけるTech LT会は connpass にて告知しています。 UUIDをプライマリキーにするユースケース そもそもUUIDをプライマリキーにするユースケースはどのようなものがあるのでしょうか？ いくつかの観点から考えてみます。 パフォーマンス観点 大量の同時書き込みが発生するような状況でauto incrementを利用してIDを発
MySQLで階層構造を扱うための再帰的なクエリの実装方法と実用例
１．はじめに RDBでの階層構造の関係を持つデータを扱う上で、 効率的なデータの持ち方や抽出方法について検証を行っています。 結論から先に 階層構造を扱う方法として下記の種類があります。 隣接リスト 経路列挙 入れ子集合 閉包テーブル 再帰クエリ（WITH RECURSIVE）を使うと階層データを扱う上でのパフォーマンスが得られます。 検索性、更新量、データ量など加味すると隣接リストで再帰クエリを用いるのがよさそう。 ２．階層構造を持つデータの概要 階層構造を持つデータとは 複数の要素（データ）が親子関係で結びついている構造を持つデータ 1つの要素が複数の要素の親になることができ、 また、1つの要素が複数の子要素を持つこともあります。 ある要素を親として、細分化された子要素であったり、 類似する要素を抽象化したものを親要素とするようなデータ。 階層構造を持つデータの例 組織における事業部、
閉包テーブル (Closure Table) に順序を持たせソートした結果を取得する - Qiita
はじめに 対象となる読者 ツリー構造のデータを RDB で扱うために閉包テーブル (Closure Table) を検討している人 閉包テーブルで順序を保持する方法を探している人 この記事を読んだ後できるようになること 閉包テーブルで順序を保持する方法がわかります 閉包テーブルから深さ優先探索 (前順・先行順・前置順・行きがけ順) でソートした結果を取得できます この方法を採用する場合に注意すべき点がわかります この記事を書いたときの環境 DB: PostgreSQL 9.6.1 なぜ閉包テーブル (Closure Table) を採用しようと思ったか 今まではツリー構造のデータを扱うときに入れ子集合 (Nested Set) を採用することが多かったのですが、このモデルの問題はノードを挿入するために隙間を開ける必要があり、挿入するノードの right より大きい left or/and
#6「Shardingマジ怖い」tech.kayac.com Advent Calendar 2012 - KAYAC engineers' blog
最近子供が産まれたaraga(@ken39arg)です｡ このエントリはtech.kayac.com Advent Calendar 2012 6日目の記事です。 テーマは「私の中のマイイノベーション 2012」 2日目の記事を見て、条件反射的に僕もおっぱいについての記事を書こうと思いましたが、 産まれた子供が「お父さんはいつもおっぱいのことばっかり考えていて気持ち悪い」と思ってしまったらと思うと、こんな危険な橋を渡るわけには行かず、 実際いつもおっぱいのことばかり考えているんですけど、おっぱいのことなんて全然興味ないです。 息子よ、父さんはいつだってまじめに働いているよ！ というわけで今年作った"まじめな"ツールのMySQL::Sharding::Clientを自画自賛したいと思います。 MySQL::Sharding::Client MySQL::Sharding::Clientは一言
複数列indexの順序と選択性 - Qiita
複数列indexの順序を決める時にどういう順番で並べますかっていうと 選択性の高い列から並べるのが原則 それじゃ、最近のDBでセオリー通りのindexとそうじゃない順序のindexでどれくらい差が出るもんなの、というのを単純なケースで試してみる DB:MariaDB 10.0.11 OS:Ubuntu 14.04 マシン:thinkpad t440p(ssd) テーブルとindex テーブルとテストは前回も使用したのを流用する http://qiita.com/k_o_gj/items/a663692c3389ec7cc29d CREATE TABLE event_test( id BIGINT AUTO_INCREMENT, event_id INT NOT NULL DEFAULT 0, user_id INT NOT NULL DEFAULT 0, status INT NOT NU
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
MySQLでGROUP BYとORDER BYを同時に使用する場合に気をつけたいこと | 日記の間 | あかつきのお宿
今さらな話ではあるんですが、前にも一度同じ過ちを犯したことがあるので、ここでちゃんと自分を懲らしめておきたいと思います。 前提条件 例えば、データベースにこんなデータが入っているとする。 +----+-----------+--------+------+---------------------+ | id | author_id | title | text | created | +----+-----------+--------+----------------------------+ | 1 | 1 | title1 | text | 2012-10-01 12:00:00 | | 2 | 2 | title2 | text | 2012-10-02 12:00:00 | | 3 | 1 | title3 | text | 2012-10-03 12:00:00 | | 4
MroongaでGroongaの機能を使いこなす高度なテーブル設計をする方法 - CreateField Blog
はじめに MySQL/MariaDBで高速に全文検索するためのオープンソースのストレージエンジンMroongaは、以下のように、Engine=Mroonga、FULLTEXT INDEX (${source_column})と書くだけで非常に簡単に全文検索を使い始めることができます。 CREATE TABLE memos ( id INT NOT NULL PRIMARY KEY, content TEXT NOT NULL, FULLTEXT INDEX (content) ) Engine=Mroonga DEFAULT CHARSET=utf8; 検索するときも以下のようにMATCH ... AGAINSTを使うだけです。 mysql> INSERT INTO memos VALUES (1, "1日の消費㌍は約2000㌔㌍"); Query OK, 1 row affected (
MySQL (InnoDB) における行のサイズと速度の関係について - kazuhoのメモ置き場
集約演算を行うケースでは、行のサイズを小さく保つことはとても重要。アクセス頻度が低いコラムは別テーブルに追い出すとかしたほうがいいくらい。 一方、集約演算を行わないケース (単一行の insert, update 等を含む) の場合は、(クライアントとの通信のための) システムコールがオーバーヘッドになるので、小さなテーブルにたくさんアクセスをするよりも、長い行を持つテーブルに１回アクセスするほうが良い。 たとえば手元の環境での insert on duplicate key update の速度は、 行のサイズ 必要時間 0KB 1 3KB 4 6KB 7 9KB 13 12KB 13 とかそんな感じ (環境やクエリによる変わるので自分で測定してね。9KB の速度低下はページサイズの1/2を超えたからかな)。つまり、行のサイズが1KB程度だと、通信のオーバーヘッドが大きいからあまり問題に
ソーシャルゲームのためのMySQL入門その２ | BLOG - DeNA Engineering
こんにちはこんにちは。11インチMacBook Airが欲しくてたまらないiwanagaです。 前回の記事 が幸いにもご好評を頂けた様で非常にうれしいです。嬉しくなって、ついがんばって第２弾を書いてしまいました。引き続き、ソーシャルゲームでよく使われるテーブルタイプ毎にちょっとしたテクニックを紹介していきます。 今回はちょっとライトな感じ＆読み物になってしまっていますが「ユーザID単位で1つだけ持つデータ」と「パラメータなどのマスターデータ」についてご説明したいと思います。ちなみに次回はInnoDBのデータ構造の簡単な説明と複合プライマリーキーのデータについて、その次で紹介し損ねたちょっとマニアックなテクニックや性能管理のための手法を紹介することを予定しています。 その前に。。。 先日行われた JAPAN INNOVATION LEADERS SUMMIT で弊社松信が「ソーシャルゲームの
sqlのwhere in って、複数条件(カラム)を指定できるんですね - end0tknr's kipple - web写経開発
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
MySQLで複数行を一括でUPDATEする - Qiita
FrogApps 技術ブログ始めました！ RailsやiOS、HTML5の情報を発信中!! → http://qiita.com/teams/frogapps データベースを運用していると、一気にデータを投入したり、更新する必要が出てきます。 MySQLではINSERT文では複数行同時に更新できますが、UPDATEでは用意されていません。 そこで、UPDATEとJOINを組み合わせて、既存のテーブルを一気に更新してみます。 例) original_dataテーブルのbodyの値を複数行一気に更新する まずは元データを作ります。 CREATE TABLE tbl1(id INTEGER PRIMARY KEY, body VARCHAR(255)); INSERT INTO tbl1(id, body) VALUES(1, '001'); INSERT INTO tbl1(id, body)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Laravel | Closure Tableで階層の深さが動的なカテゴリ構造を扱う - わくわくBank
レガシーなウェブアプリを Rails で拡張するときに DB の扱いで気をつけること #rubyhiroba - 彼女からは、おいちゃんと呼ばれています