innodb_large_prefixを使ってERROR 1071を回避する | Yakst
大きなサイズのインデックスを生成しようとするとERROR 1071が発生することがあり、そんな時にはinnodb_large_prefixパラメータを利用すると良いことがある。 MySQLのInnoDBストレージエンジンのテーブルの長いvarcharカラムを含むカラムにインデックスを生成しようとしたことがあれば、このエラーを見たことがあるだろう。 ERROR 1071 (42000): Specified key was too long; max key length is 767 bytes 文字数制限は、使っている文字コードに依存する。例えば latin1 であればインデックスを生成できる最大カラムは varchar(767)であるが、 utf8 の場合は varchar(255) までである。 インデックスあたり、3072バイトという別の制限もある。767バイトはカラムごとの制限な
MyRocks: A space- and write-optimized MySQL database
At Facebook we use MySQL to manage many petabytes of data, along with the InnoDB storage engine that serves social activities such as likes, comments, and shares. While InnoDB provides great performance and reliability for a variety of workloads, it has inefficiencies on space and write amplification when used with flash storage. A few years ago, we built RocksDB, an embeddable, persistent key-val
良く分かるMySQL Innodbのギャップロック - Qiita
MySQLのロック ロックとはトランザクションの並列度を上げる為の並列スケジューリング方法の一つ トランザクションをサポートしているデータベースにおいては、トランザクションの並列数を上げる事が性能アップの一つの方法。 他のトランザクションに更新して欲しくないデータだけにロックをかけて、ロックされたデータ以外を更新するトランザクションは並列で実行される。 Innodbは行ロック？ Innodbは更新対象の行だけをロックする。と思っていると、意外な落とし穴にハマる。 その一つがギャップロック。 ギャップロックを実際に起こしてみる サンプルテーブル idとstrがあるだけのシンプルなテーブル。idがPKで1~5までは順番に、その後、10,20と飛んで行が入っている。 通常の行ロック トランザクション１ select for updateでid=2の行を明示的にロック トランザクション２ id=1
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
SELECT ... FOR UPDATEとロックの挙動 - walf443's blog
kamipoさんが補足を書いてくれたので、参照するとよいです。 基礎的だけど、SELECT ... FOR UPDATEをちゃんと理解できてない気がするな、ということで実際にコンソールで打ちながら挙動を確認してみた。 今回確認した環境は、 mysql> show variables like 'tx_isolation'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | tx_isolation | REPEATABLE-READ | +---------------+-----------------+ 1 row in set (0.00 sec) mysql> show variables like 'version'; +-----
Innodb Deep Talk #2 でお話したスライド
Innodb Deep Talk #2 でお話したスライドです。 主旨は後半のチューニングの話かと。Read less
MySQLのロックについて
MySQLのロックについて JPOUG> SET EVENTS 20140907 2014/09/07 平塚 貞夫 1 Revision 2 自己紹介 • DBエンジニアをやっています。専門はOracle DatabaseとMySQL。 • オープンソースソフトウェアの導入支援をしています。 • 仕事の割合はOracle：MySQL：PostgreSQL＝1：2：7くらいです。 • Twitter：@sh2nd • はてな：sh2 • • 写真は実家で飼っているミニチュアダックスのオス、アトムです。 2 本日のお題 3 想定外のデッドロック • MySQLのInnoDBストレージエンジンに対して、2つのトランザクション を以下の順番で実行するとデッドロックが発生します。 • このデッドロックの発生メカニズムを理解するために、InnoDBのロック アーキテクチャについて確認していきます。 4
MySQLのINSERTを高速化するChange bufferingをソースコードから理解する - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
背景 アカツキで提供しているサービスでは、ほぼ全てにおいてAWSのRDS(MySQL5.6, InnoDB)を使用しております。 ソーシャルゲームでは多くのWriteがかかりますが、そのコストが気になったので調べてみました。 調べてみたこと 一言にINSERTといっても、COMMIT時に即テーブルスペースに反映されるような単純な処理ではありません。 例えばINSERTしたテーブルにセカンダリインデックスがある場合、そこに加えられた変更を反映しなければなりません。 ところが、INSERT時バッファプール内に該当するインデックスのページが無い時はこれをディスクから読みだす必要があり、非常にコストが掛かります。 InnoDBにはこれを抑えるための"Change buffering"という機能があり、今回はその解説をしたいと思います。 Change bufferingとは 変更を加えたページがバッ
我々(主語が大きい)は何故MySQLで外部キーを使わないのか
外部キー便利!!! MackerelではPostgreSQLで外部キーあり そのレコードがあることが保証される 各テーブルのidにアプリケーションレベル(Mackerelの場合Scala)で型付けをするとなお便利 MemberID型、MonitorID型 → idで誤ったテーブルを引くとかがない 本日のスキーマ CREATE TABLE `member` ( `id` INTEGER unsigned NOT NULL auto_increment, `earned_item_count` INTEGER unsigned NOT NULL DEFAULT 0, `name` VARCHAR(191) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4; CREATE TABLE `item`
MySQL - InnoDBのロック関連まとめ - Qiita
メモ開放。InnoDBの行ロック関連について、それぞれの項目が必ずしも並列関係にあるわけではないが、以下のようにまとめていく。 排他ロックと共有ロック SELECT ~ FOR UPDATE SELECT ~ LOCK IN SHARE MODE 排他ロックと共有ロック 読み取りを許すかどうかの違い。排他ロックは対象行を全てのクエリからロックするため、UPDATEやDELETEなどの更新クエリはもちろん、SELECTなどの読み取りクエリも通さない。共有ロックは更新クエリを通さないが、読み取りクエリは通す。 （追記：排他ロックは分離レベルによってはSELECTを通すとのこと。 公式 ） 排他ロックは全てのクエリを通さず、共有ロックは排他ロックを伴うクエリを通さない、と言い換えたほうがいいかもしれない。 公式では共有ロックは同トランザクション内のselectを許し、排他ロックは同トランザクショ
MySQLの更新系処理のパフォーマンスを、innodb_flush_log_at_trx_commitのチューニングで上げる - blog.workflow
MySQLの更新系処理のパフォーマンスを、innodb_flush_log_at_trx_commitのチューニングで上げる 経緯 Master（更新系のMySQL Database）が非常に高負荷となっている。 slowquerylogsに、下記のような「commitがボトルネックになっている」旨の出力が大量にでる # User@Host: apps[apps] @ ip-10-163-30-24.ap-northeast-1.compute.internal [10.163.30.24] # Query_time: 9.523171 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0 SET timestamp=1349786490; COMMIT; # User@Host: apps[apps] @ ip-10-132-8-20.ap-
InnoDBのリカバリ機能を検証してみる at nkjmkzk.net
innodbはクラッシュ時のリカバリ機能を実装しており、mysqldがクラッシュした場合やOS自体がクラッシュした場合にもしコミットされたデータがテーブルから失われていても再起動時にib_logfileからコミットされたトランザクションを読み出し、それが実データ（デフォルトだとibdata）に反映されていなければ反映させるという処理が走ります。MySQLはinnodb_flush_log_at_trx_commitの値により、1秒毎、またはコミット毎にトランザクションをログファイルにフラッシュします。 今回は以下２点について検証を行いました。 １．クライアント側から発行したクエリがクラッシュ後にどこまで復旧されているか ２．リカバリにかかる時間の測定（ログのファイルサイズとの因果関係にも言及） １の検証についてはinnodb_flush_log_at_trx_commitの設定を0と1に変
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
doc/innodb.md at master · ichirin2501/doc