MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
第10回 yum, rpmインストールにおけるMySQL 5.6とMySQL 5.7の違い | gihyo.jp
MySQL道普請便り 第10回yum, rpmインストールにおけるMySQL 5.6とMySQL 5.7の違い 第8回 MySQLのバージョン体系を知るの中で、yumでインストールしたMySQL 5.6をMySQL 5.7にアップグレードしました。今回はアップグレードではなく、MySQL 5.7を新規にyumでインストールする場合のMySQL 5.6との違いを説明したいと思います。 MySQLのインストール方法はいくつかありますが、yumリポジトリーを利用したインストールが好んで選ばれるケースは、おそらくChefのレシピやDockerfileに利用する際ではないでしょうか。筆者はサンドボックス環境にはDockerをよく利用していますが、イメージを作成する際には原則MySQL公式のyumリポジトリーを使うようにしています。 yumリポジトリーを使用したインストール MySQL開発元のOrac
InnoDBのREPEATABLE READにおけるLocking Readについての注意点
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
InnoDBで行ロック/テーブルロックになる条件を調べた #mysqlcasual Advent Calendar 2013 - あおうさ＠日記
はじめに この記事は、MySQL Casual Advent Calendar 2013 7日目の記事です。 〜 Casual に記事を書けばええんやでヽ(´ー｀)ノ 〜 私がMySQLで えっ？！ っと思った下記エントリーの挙動が何故そうなってしまうのかを書きたいと思います。 InnoDBで行ロック/テーブルロックになる条件 MyISAM はテーブルロック、InnoDB は行ロックが掛かるというのは有名な話じゃないかと。 ただ、最近知ったのですが、InnoDB だとしても必ずしも行ロックになるわけではなく、テーブルロックになる場合もあるようですね。 ... InnoDB であってもユニーク制約 or インデックスが張られているカラムで検索した場合以外はテーブルロックになってしまうようです。これは注意しないと思わぬところでテーブルロックになってしまって大変なことになりそう！ http://
MySQLがおかしい！あなたならどうしますか？ – MySQL Casual Advent Calendar 2011 - As a Futurist...
しわっす！DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい＞＜ MySQL がおかしい！ 03:14 hidek: なんかエラー出まくってるんだけど！ 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね？ね？ね？こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう？既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
誰も教えてくれなかったMySQLの障害解析方法 - Qiita
それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです＞＜ 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
Rails - ActiveRecordでカラム毎にcharsetとcollationを指定する - Qiita [キータ]
MySQLではカラム毎にcharsetとcollationを指定できるので、こういうMigrationファイルがあったときに class CreateUsers < ActiveRecord::Migration def change create_table :users do |t| t.string :email, charset: 'ascii', collation: 'ascii_bin', null: false t.string :password_digest, charset: 'ascii', collation: 'ascii_bin' t.timestamps end add_index :users, :email, name: "idx_email", unique: true end end CREATE TABLE `users` ( `id` int(1
![Rails - ActiveRecordでカラム毎にcharsetとcollationを指定する - Qiita [キータ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/a6db86a589d66354aeb5151a5bf9923335b0d069/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9QWN0aXZlUmVjb3JkJUUzJTgxJUE3JUUzJTgyJUFCJUUzJTgzJUE5JUUzJTgzJUEwJUU2JUFGJThFJUUzJTgxJUFCY2hhcnNldCVFMyU4MSVBOGNvbGxhdGlvbiVFMyU4MiU5MiVFNiU4QyU4NyVFNSVBRSU5QSVFMyU4MSU5OSVFMyU4MiU4QiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9YjdmNDcwYmVjN2FlZTg5ZWI3NDk4MDdhYTcwNTBhMmU%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBrYW1pcG8mdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTQzOWU1N2I4MjBiNDZjYThiMGMzODhmZmQ0OTcwMzlm%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D13ddfb5e722aa5b59aee79caed40f1ae)
MyNA(日本MySQLユーザ会) 2015年4月 に行ってきた #mysql_jp - weblog of key_amb
最近ブログが勉強会参加レポートばかりになっている感がありますが、今日(4/22)は MyNA (日本MySQLユーザ会) に行ってきました。 ここのところ話題になっていた '🍣' = '🍺' 問題や、パフォーマンス・チューニング Tips, MySQL 5.7 の性能 / 新機能と、盛り沢山の話が聞けて、大変勉強になりました。 当日の Tweet が togetter にまとめられています。 発表内容と照らし合わせて見ると、参考になる情報もあるかもしれません。 以下、発表内容のノートになります。 資料はまだネット上に上がっていないものもあるようですが、捕捉したらこちらの記事も更新します。 (愚直にメモを取っていたので、かなりの分量になりました ^^; ) 🍣=🍺 とみたまさひろさん = from Masahiro Tomita 自己紹介 日本MySQLユーザ会代表 MySQL的
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
MySQLでお手軽デッドロック - jfluteの日記
-- MEMBER_SEA は MEMBER の 1:n の子テーブル delete from MEMBER_SEA where MEMBER_ID = 3 insert into MEMBER_SEA ...(MEMBER_ID は 3) ん？ 最初のdeleteが互いに「0件削除」だとデッドロック。別トランザクションのMEMBER_IDが別ID(例えば4)でもデッドロック。(とにかく両方のトランザクションでdeleteが0件であれば) これは... ネクストキーロックって？ MySQLのInnoDBには「ネクストキーロック」という機構があります。 詳しくは、ぐぐってくれればOKですが、ひとまず参考になるオフィシャルサイトのページを。 => ネクスト キー ロック:ファントムの問題を防ぐ 難しいこと書いてありますねぇ。 「ギャップ」って何!? ここでいうインデックスレコードって!? とに
InnoDBのネクストキーロックによるデッドロックの例 - iakioの日記
あまりMySQLのことは自信ないですが。 一見問題なさそうに見える操作でデッドロックしてしまうケースがあったので動画にしてみました。 SELECTしてみて「有ればUPDEATE、無ければINSERT」や、あるいは「有れば何もせず、無ければINSERT」を行ないたい場合に、SELECT FOR UPDATEして無ければINSERTとしてしまうと、動画の最初の例のようにデッドロックしちゃいます。存在しない行に対してSELECT FOR UPDATEするとちょっと広めに行ロックがかかってしまう感じでしょうか。 「有ればUPDATE、無ければINSERT」であれば、INSERT ... ON DUPLICATE KEY UPDATEを使うのが良さそう。「有れば何もせず、無ければINSERT」なら、いきなりINSERTしてみて一意制約違反ではじいてもらうのがいいのかな。 動画の2つめの例は、i =
MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.10.8 InnoDB 内で各種 SQL ステートメントによって設定されるロック
一般に、ロック読み取り、UPDATE、または DELETE では、SQL ステートメントの処理時にスキャンされるすべてのインデックスレコード上に、レコードロックが設定されます。 行を除外する WHERE 条件がステートメント内に存在するかどうかは、関係ありません。 InnoDB には正確な WHERE 条件が記憶されませんが、スキャンされたインデックスの範囲は認識されます。 通常、ロックはレコードの直前にある「ギャップ」への挿入もブロックするネクストキーロックです。 ただし、ギャップロックは明示的に無効にすることができます。これにより、ネクストキーロックが使用されなくなります。 詳細は、セクション15.7.1「InnoDB ロック」を参照してください。 トランザクション分離レベルによって、どのロックが設定されるのかも影響を受けます。セクション15.7.2.1「トランザクション分離レベル」を
FacebookにおけるMySQLを用いた大規模システムアーキテクチャの現実～MySQL Connect 2013
米オラクルが主催するMySQLのイベント「MySQL Connect」が9月21日から23日まで、サンフランシスコで開催されました。Oracle OpenWorld、JavaOneとの同時開催でした。 基調講演の1つには、MySQLのヘビーユーザーであるFacebookのHarrison Fisk氏が登壇。FacebookにおけるMySQLの役割、大規模運用の背景などを紹介しています。その内容をダイジェストで紹介しましょう。 MySQL@Facebook Lots and lots of small data Harrison Fisk氏。 Facebookでデータパフォーマンスチームのマネージャをしている。社内ではMySQLはもちろん、HBase Hadoopなどにも関わっている。 まずは、どんな種類のデータをMySQLで扱っているのかについて。 Facebookとは基本的にグラフだ。グ
MySQL 5.6で作成したシーケンステーブルの更新性能のベンチを取ってみた
ベンチマークを取るテーブルと、発行するクエリーテーブルは下記の通りです。 CREATE TABLE `seq_myisam` ( `id` bigint(20) unsigned NOT NULL) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4; INSERT INTO seq_myisam values (1000000); CREATE TABLE `seq_innodb` ( `id` bigint(20) unsigned NOT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; INSERT INTO seq_innodb values (1000000); my.cnfは下記の通り [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock
❤️ Best adult photos at mysql-casual.org
free nudes, naked, photos,
Art of MySQL Replication.
1. Art Of MySQL Replicaton 〜 10 年の歴史を誇るレプリケーションの妙技〜 奥野 幹也 @nippondanji mikiya (dot) okuno (at) gmail (dot) com 2. 免責事項 ● 本プレゼンテーションにおいて示されている見解は、 私自身の見解であって、オラクル・コーポレーション の見解を必ずしも反映したものではありません。ご了 承ください。 3. 自己紹介 ● 今日は個人として来ています。 – http://nippondanji.blogspot.com/ – Twitter: @nippondanji ● 現職は MySQL サポートエンジニア。 – 2000 年にサン・マイクロシステムズ入社 – 2007 年に MySQL KK へ転職 – 気付くとまたサン・マイクロシステムズに・・・ – 現在は日本オラクルに在席。 ●
Test::mysqld + perl -d を使うと SQLがそのまま叩けて便利 - k12uのアレ
id:zigorou 先生に教えてもらった技をメモ。 (あとで調べてみたら http://perl-users.jp/articles/advent-calendar/2010/hacker/1 ですでに言及されていましたが、SQL叩けるというところだけ強調して再掲) まずテストを用意します。 [kawamoto.m@mm1:~]$ cat 01.t use Test::More; use Test::mysqld; my $mysqld = Test::mysqld->new( my_cnf => { 'skip-networking' => '', # no TCP socket } ) or plan skip_all => $Test::mysqld::errstr; ok(1); done_testing;perl -d でtestを走らせます。 [kawamoto.m@mm1:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Table locks in SHOW INNODB STATUS
ActiveRecordをutf8mb4で動かす - Qiita
