InnoDB の行レベルロックについて解説してみる
自分の浅はかな理解だと、Deadlock が起こる理由が説明できないケースに遭遇したので、InnoDB の行レベルロックについて調べてまとめてみました。 「行レベルロックだと、同じ行を更新する場合にしか Deadlock が起こらないんでしょ」と思っているような人が対象です。 また、主に InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる を参考にさせていただいたので、そちらの内容がすんなり理解できる方には冗長な内容だと思います。 MySQL のバージョンは 5.6.33 です。 サンプルデータ 次の SQL で作成したデータを扱うことにします。 CREATE TABLE `orders` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `product_id` int(10) unsigned NOT NULL, `us
InnoDB の DoubleWrite 技術をみる - Qiita
doublewrite とは？ InnoDB が備わっている「データ二重書き込み」によるデータ保護機能。最初から有効になっている。1 この機能はトランザクションログとは別なので混同しないように。 MySQL Server での説明 https://dev.mysql.com/doc/refman/5.7/en/innodb-doublewrite-buffer.html MariaDB Server での説明 https://mariadb.com/kb/en/library/xtradbinnodb-doublewrite-buffer/ Percona Server での説明 https://www.percona.com/doc/percona-server/5.5/performance/innodb_doublewrite_path.html SSD/HDD 混在環境のために d
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
【MySQL5.6->5.7】 とてもたくさんの列をもったテーブルをつくりたい／Row size too large (> 8126)についてかんがえる - Qiita
【MySQL5.6->5.7】 とてもたくさんの列をもったテーブルをつくりたい／Row size too large (> 8126)についてかんがえるMySQL ■ はじめに 現実を前にして正規化などといった理想を捨て去ったとある人は、 とある日とあるスキーマに全知全能の神を降臨させようと画策した。 すなわちTEXT型の列を大量に備えたテーブルを用意して、 あらゆる情報と状況を何とかしてもらおうと企図したのだった……！！ ■ やってみる MySQL5.6を実行できる環境を用意して、 とりあえず以下のようなCREATE TABLE文を叩いてみる。 mysql> CREATE TABLE zeus ( -> col1 TEXT -> , col2 TEXT -> , col3 TEXT -- 中略 -> , col195 TEXT -> , col196 TEXT -> ) ENGINE=I
第80回 FLUSH構文について：MySQL道普請便り｜gihyo.jp … 技術評論社
MySQLのFLUSH構文は、内部キャッシュのクリア、リロード、ロックの取得、テーブルのフラッシュなど、構文によってさまざまなことを実行します。今回はFLUSH構文について説明していきます。なお、今回の例で使用しているMySQLのバージョンは8.0.11、各テーブルはInnoDBを想定しています。 FLUSH LOGS構文 FLUSH LOGS構文を利用して各ログファイルをスイッチさせるには、FLUSH <log_type> LOGSを実行します。log_typeに入るのは、BINARY, ENGINE, ERROR, GENERAL, RELAY,SLOWです。BINARY、RELAYの場合は、FLUSH <log_type> LOGSを実行すると番号を繰り上げたバイナリログまたはリレーログファイルを生成し、ログスイッチをします。 また、FLUSH RELAY LOGS FOR CHAN
MySQLのInnoDBプライマリーキーのチューニング | Yakst
[MySQL]原文 Tuning InnoDB Primary Keys - Percona Database Performance Blog (English) 原文著者 Yves Trudeau 原文公開日 2018-07-26 翻訳依頼者 翻訳者 kakuka4430 翻訳レビュアー doublemarket 原著者への翻訳報告 2055日前 原文へのコメントで報告済み 編集 良いInnoDBプライマリキーを選ぶことは、パフォーマンスチューニングの方向性にとても重要です。この記事では、あなたのワークロードに応じた最適なプライマリキーを選ぶための方法を紹介したいと思います。 Percona社のプリンシパルアーキテクトとしての私の責務の一つは、顧客のデータベースをチューニングすることです。パフォーマンスチューニングに関連する側面は多く存在し、それがこの仕事を複雑、かつ大変興味深いものに
An Introduction to InnoDB Internals
Learn from our experts, hear from your peers at Percona.connect Learn more
MySQLがメモリー不足の時に何をするか : トラブルシューティングガイド | Yakst
MySQLがメモリー不足で停止してしまった(OOM Killerに停止させられた)時に確認すべき項目を紹介する。特に、MySQLのバグでメモリリークが起きている可能性がある場合に手がかりを得る方法について。 [MySQL]原文 What To Do When MySQL Runs Out of Memory: Troubleshooting Guide - Percona Database Performance Blog (English) 原文著者 Alexander Rubin 原文公開日 2018-06-28 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー kakuka4430 原著者への翻訳報告 1948日前 原文へのコメントで報告済み 編集 クラッシュした時のトラブルシューティングが楽しいタスクであったためしはありませんが、クラッシュの原因をMySQLが教えてくれ
もうRDBとNoSQLを選ぶ必要はない MySQLなら両方できる
2018年4月、MySQL 8.0 GAがリリースされた。早速5月23日には「Oracle MySQL Innovation Day 2018 Tokyo」が開催され、新バージョン詳細が日本のユーザーに紹介された。MySQLは世界有数の大規模Webサイトで使われるRDBでありながら、新バージョンではドキュメントストア機能を多く盛り込みNoSQLとしても使えるデータベースとなっている。当日は気になる新サービス構想についての言及もあった。 MySQL 8.0はRDBとNoSQLのハイブリッドデータモデルへと MySQL 8.0といえば、このツイートが象徴的だ。投稿者はベルギー在住のMySQLエバンジェリストでありMySQLコミュニティマネージャのフレデリック・デカン（Frederic Descamps）氏。米国カリフォルニア州レッドウッドショアー（オラクル本社）でのMySQL 8.0 GA記念
MySQL InnoDBの領域管理 - Qiita
武蔵野Advent Calendar 2017の20日目の記事です。品川から参加しています。 今日はMySQL InnoDBの領域管理について勉強し、いくつか動作例を見ながらInnoDBに対する理解を深めていきたいと思います。アプリケーション開発者やデータベース管理者の方にとって明日からすぐに使えるノウハウとまではいきませんが、いつか何かの役に立てば幸いです。 まとめ InnoDBにはテーブルスペース、セグメント、エクステント、ページというデータの管理単位があるよ エクステント単位で空き領域が管理されているよ。だけどそれを知ったところであまり役には立たないよ 昇順INSERTが得意でランダムINSERTが苦手なのはよく知られているけれど、実は降順INSERTが得意だよ テーブルスペース、セグメント、エクステント、ページ InnoDBのデータが格納されるファイルのことをテーブルスペースと呼び
第59回 Percona XtraBackupを使ってみよう | gihyo.jp
Percona XtraBackup（以降、PXB）とは、Percona社が公開しているオンラインでMySQLのバックアップを取得できるOSSツールです。 一般的にMySQLのバックアップはmysqldumpクライアントを使用するかと思います。mysqldumpは論理バックアップであり、データベース内のデータをテキスト（INSERT文）として保存します。そのため、リストアにはINSERT文を使用しなければならず、遅いのが難点です。 今回紹介するPXBは、物理バックアップであり、実際のデータベースのファイルを物理的にコピーすることでバックアップを取得します。リストアはそのファイルに対して、バックアップの開始時間からの差分データをリカバリしてファイルを配置するだけなので、論理バックアップのリストアよりも高速です。 Percona XtraBackupの動作について PXBは、トランザクションに
第56回 InnoDBテーブルサイズのいろいろな確認方法 | gihyo.jp
日々更新されるテーブルは、想定していたよりも予想外に更新が増え、サイズが肥大化してストレージの問題が発生することがあると思います。今回はそれを未然に防ぐため、InnoDBのテーブルサイズを確認する方法をいくつか紹介します。今回の例ではMySQLのバージョン5.7.19を使用します。 TABLESテーブル はじめに、InnoDBのテーブルとインデックスサイズを確認する方法として、information_schema内のtablesテーブルを見るのが一般的だと思います。ただし、このテーブルは統計情報から取得されるため正確な値ではありません。概算値となります。 mysql> SELECT TABLE_NAME,ENGINE,DATA_LENGTH,INDEX_LENGTH,DATA_FREE FROM information_schema.tables WHERE TABLE_NAME = 't
MySQL InnoDBのネクストキーロック おさらい - SH2の日記
MySQLのInnoDBストレージエンジンは行ロックをサポートしています。しかしOracleと同じ感覚でアプリケーションを作っていると、思わぬところでデッドロックに出くわすことがあります。これはInnoDBのロック範囲がOracleよりも微妙に広いためです。 実際の例で確認してみましょう。 mysql> select * from t; +----+------+ | c1 | c2 | +----+------+ | 10 | a | | 15 | a | | 20 | a | | 25 | a | | 30 | a | | 35 | a | | 40 | a | | 45 | a | | 50 | a | +----+------+c1列は主キーになっています。1つめのセッションで以下のSQLを実行します。 mysql> set tx_isolation = 'repeatable-r
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
Migrating a database from InnoDB to MyRocks
Last year, we introduced MyRocks, our new MySQL database engine, with the goal of improving space and write efficiency beyond what was possible with compressed InnoDB. Our objective was to migrate one of our main databases (UDB) from compressed InnoDB to MyRocks and reduce the amount of storage and number of servers used by half. We carefully planned and implemented the migration from InnoDB to My
フェイスブック松信さんが解説！FacebookはデータベースをInnoDBからMyRocksへ移行中
フェイスブック 松信嘉範さんが登場！ 世界中のユーザーがあらゆる情報を共有しているFacebook。ユーザーの投稿や「いいね！」などのアクティビティはメインデータベースのMySQLに刻々と書き込まれていく。同社はこのMySQLおよびストレージエンジンInnoDBに性能を高めるための独自の改良を加え、日々運用している。 サイトでは常に大量の書き込みが発生しておりデータはペタバイト級、膨大な処理をまかなうために大量のサーバーでシャーディング（分散）をしている。またMySQLデータベースの前にキャッシュを置き、多くの読み込みはキャッシュでヒットしてすぐ応答を返せるようにしている。 メインデータベースのストレージにはフラッシュストレージ（SSD）を使用。SSDは高いIOPS性能を出せるものの、価格はいまだにHDDよりも高い。なにしろ台数が半端ないので、ストレージ使用量（スペース）を少しでも減らすこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://developer.hatenastaff.com/entry/2019/01/15/120431
MySQL :: MySQL 8.4 Reference Manual :: 17.4 InnoDB Architecture
スレッドIDを利用したMySQLのデッドロック解析手法
https://engineering.mercari.com/entry/2017/12/18/deadlock
