MySQL で utf8 と utf8mb4 の混在で起きること - tmtms のメモ
MySQL を UTF-8 で使おうと思ってハマりがちなのは charset utf8 を指定してしまうことです。 MySQL の UTF-8 には歴史的事情により utf8 と utf8mb4 の二つあります。 UTF-8 は1バイト〜4バイトで1文字が構成される文字コードですが、MySQL の utf8 は4バイト文字を扱うことができません。ハマりたくなければ utf8mb4 を使いましょう。 utf8 を使ってしまった場合に4バイト文字がどのように扱われるか、自分でもうろ覚えだったのでメモしておきます。 登録 接続が utf8mb4 でカラムが utf8mb4 あたりまえですが、そのまま登録されます。 mysql> insert into utf8mb4 (c) values ('美味しい🍣と🍺'); mysql> select * from utf8mb4; +--------
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
Docker MySQL公式イメージを使用してDBに初期データを流し込む - Qiita
一時期はalpineに乗っかったMySQLを使おうとしましたがMariaDBだったので断念。 いくら互換だとはいえ、まだ自分には早い。 そんなわけでDocker MySQL公式イメージの5.5を利用してDBを構築。 公式イメージ https://hub.docker.com/_/mysql/ 初期データを投入した状態でgithubにpushしようとしたら、rejectされてしまいました。 調べてみるとGithubのファイルサイズ制限にひっかかった模様 Working with large files https://help.github.com/articles/working-with-large-files/ 1ファイルあたり100MBまでとのこと。 InnoDBのibdata1がサイズ制限を超過していたのでした。かなりデータを厳選したんだけどな〜。 初期データインポートに使用したd
LOCK IN SHARE MODE の使いドコロを間違えてデッドロック - ngyukiの日記
先日、作っていたシステムでデッドロックがわりかし頻繁に発生することが判りました。 RDBMS のデッドロックは必ずしもバグでは無く、無理に対応するよりアプリケーション側でハンドリングしてトランザクションのリトライなどを行った方がいい場合もあると思いますが、このケースでは明らかにバグでした。 デッドロックするクエリ テーブル定義は次の通りで・・・ CREATE TABLE tt ( id INTEGER NOT NULL PRIMARY KEY, no INTEGER NOT NULL ); INSERT INTO tt VALUES (1, 0); 次のようなSQLで更新します。 BEGIN; /* (1) */ SELECT @no := no FROM tt WHERE id = 1 LOCK IN SHARE MODE; /* (2) */ UPDATE tt SET no = @n
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 - ネクストキーロックってどこまでロックされんの？ - Qiita
個人的にMySQL一番の鬼門のネクストキーロック。未だにまともな正解はわからないけれど、法則性らしきものが理解できてきたのでまとめてみる。 そもそもネクストキーロックとは InnoDBの行ロックはネクストキーロックを採用している。検索時はネクストキーロックを用いてインデックス走査を行うので、ギャップロックが起こる場合は常に先のギャップもロックされており、これによってファントムリードを防ぐ。一意のインデックスを持つ固有値検索の場合はギャップロックする必要がないが、値域検索の場合はギャップロックをする。 固有値検索はギャップロックしないはずだが、存在しない行を読み取ろうとした場合は排他・共有ロックではなく、ギャップロックがかかる。同時にネクストキーロックもかかるのでproduct_id = 19にはINSERTできない。 mysql> select * from products where
MySQLのデフォルトのトランザクション分離レベルは SELECT がスナップショットを参照する - ngyukiの日記
MySQL の InnoDB のデフォルトのトランザクション分離レベルは REPEATABLE READ で、ファジーリードしないようにトランザクション中の SELECT はトランザクションを開始してから最初の SELECT の時点のスナップショットから行われます。 そのため、次のやり方だと一意制約エラーが発生する可能性があります。 テーブル定義と初期データ /* なんか関係ないテーブル */ CREATE TABLE t_dummy ( dummy_id INT NOT NULL PRIMARY KEY ); /* カテゴリ */ CREATE TABLE t_category ( category_id INT NOT NULL PRIMARY KEY ); /* カテゴリごとのデータ */ CREATE TABLE t_data ( category_id INT NOT NULL,
tree-tips: MySQLの外部キーとデッドロック | MySQL
外部キーでデッドロックを起こすサンプルコード。 drop table if exists child; create table child (id int, pid int, primary key (id, pid))engine=innodb; drop table if exists parent; create table parent (id int, count int, primary key (id))engine=innodb; insert into parent values (1, 0); alter table child add foreign key (id) references parent (id); トランザクションA ------------------------------------- begin; insert into child val
共有行ロックと排他行ロックの違い - shima111の日記
select ... for update; select ... lock in share mode; の違いがよくわからなかった。 データを更新する時に必要なロックは、for update データを参照する時に必要なロックは、share mode と体感的に理解できるのだが、どちらのロックを取ったときも、他の誰もデータを更新、削除できない。 また、どちらのロックも、(for update していたら、他から参照できないのかと思いきや)他の誰からも参照は可能。 ん？となると、この２つのロック、何がどう違うの？？ その答えは ここ に書いてあった。(リンク先はPostgresだが、MySQLでも同じこと) 共有ロックとは、排他ロック（更新、削除、FOR UPDATE）をブロックする／される一方、共有ロック同士では互いにブロックしないというものです。 なるほど、share mode はセマ
MySQLのINSERT/UPDATE時におこる不整合対策 - LukeSilvia’s diary
先日、作っているアプリケーションにバグが発生しました。バグの内容は次のようなものでした。 同時に存在してはいけないはずのデータが、DB に存在する 整合性のチェックはアプリケーションレベルで行っている 一意制約のような単純なものではないので、アプリケーションレベルで実装 整合性のチェックロジックは正しい これに対し、バグは次のような状況で発生したと仮説を立てました。 ユーザがレコードを一括登録しようとする 登録ボタンを押したがレスポンスが遅い この間、整合性チェックが走っている ユーザはもう一度登録ボタンを押した 2回目の登録の整合性チェックが走り始める 1回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックが完了、INSERTが始まる 2回目の登録の整合性チェックの間、DBにはまだ1回目の登録によるINSERTが実行されていないので、チェックを通過した 結
MySQL InnoDBの行ロック - There's an echo in my head
ロックがわからない。MySQL InnoDBの行レベルロックを読んだけど、イマイチわからない。というわけで、社内の勉強会で知ったことをまとめてみる。 FOR UPDATEかLOCK IN SHARE MODEによって、そのトランザクション中に走る別画面でのクエリの処理のタイミングが異なる。 FOR UPDATEによるロック まずは画面Aで接続が行われ、トランザクションが開始され、SELECT文が発行されたとする。 [画面A] BEGIN; // トランザクションA開始 SELECT * FROM users WHERE id = 1 FOR UPDATE; COMMIT; // トランザクションA終了 そしてトランザクションAの開始後〜終了前に画面B〜Dがクエリを発行したとする。 ちなみにトランザクションを開始しておかないとFOR UPDATEを書いても画面Aでのロックが始まらないので要注
MySQL を使ってトランザクション分離レベルの違いを試す
MySQL を使ってトランザクション分離レベルの違いと、それによって何が起こるかを確認する。 確認用のテーブルを作る。 mysql> create database test; Query OK, 1 row affected (0.00 sec) mysql> create table users( -> id integer primary key, -> name varchar(32) not null -> ); Query OK, 0 rows affected (0.01 sec) mysql> desc users; +-------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+-------------+----
存在しないデータにselect ... for updateしたあと、insertしようとしたら、デッドロックしちゃってつらい。 - パルカワ2
mysql> start transaction; # 存在しないuniq制限ありなデータにfor update mysql> select * from hoge where piyo_id = 1 and fuga_id = 1 for update; mysql> insert into hoge (piyo_id, fuga_id) value (1,1);をAとB交互にしたら、Aでinsertするとき待ちが発生して、BでinsertするとDeadlock found when trying to get lock;と言われてしまい、その代わりAのinsertは成功するっぽい。イヤーンって感じです。 Server version: 5.5.16 MySQL Community Server (GPL)fujiwaraさんに教えてもらった参考URL: http://d.hatena.
MySQLのロックについて - SH2の日記
JPOUG> SET EVENTS 20140907 | Japan Oracle User Group (JPOUG)に参加して発表をしてきました。IIJさまのセミナルームは窓からの眺めがすばらしいですね。JPOUGの運営メンバのみなさま、会場を提供してくださったIIJのみなさま、当日お越しいただいたみなさま、どうもありがとうございました。 私のセッションでは「MySQLのロックについて」と題してネクストキーロックなどの説明をしました。プレゼンテーション資料と、調査のために作成したツールを公開します。 プレゼンテーション資料 (PDF) Lock Inspector 1.0 プレゼンテーション資料からリンクしているウェブサイトの一覧です。 MySQL Lists: mysql: Re: InnoDB's inner workings + checkpoints 過去記事の訂正 @kami
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
MySQL - InnoDBのロック関連まとめ - Qiita
メモ開放。InnoDBの行ロック関連について、それぞれの項目が必ずしも並列関係にあるわけではないが、以下のようにまとめていく。 排他ロックと共有ロック SELECT ~ FOR UPDATE SELECT ~ LOCK IN SHARE MODE 排他ロックと共有ロック 読み取りを許すかどうかの違い。排他ロックは対象行を全てのクエリからロックするため、UPDATEやDELETEなどの更新クエリはもちろん、SELECTなどの読み取りクエリも通さない。共有ロックは更新クエリを通さないが、読み取りクエリは通す。 （追記：排他ロックは分離レベルによってはSELECTを通すとのこと。 公式 ） 排他ロックは全てのクエリを通さず、共有ロックは排他ロックを伴うクエリを通さない、と言い換えたほうがいいかもしれない。 公式では共有ロックは同トランザクション内のselectを許し、排他ロックは同トランザクショ
トランザクション分離レベルについて極力分かりやすく解説してみた[SQL] - 明日になったら本気出せる
こっちに移動 qiita.com
![トランザクション分離レベルについて極力分かりやすく解説してみた[SQL] - 明日になったら本気出せる](https://cdn-ak-scissors.b.st-hatena.com/image/square/865d91d3f7d8bc0ecea2db1b383f8dd9abc67ed5/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12921228815712380847%2F12921228815712778346%2F1508923711)
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の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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://engineering.mercari.com/entry/2017/12/18/deadlock
