タグ

innodbに関するymm1xのブックマーク (10)

  • InnoDB はどうやってファイルにデータを保持するのか

    Extended outer memory module for my poor native memory. Posts: 2022/02/13 クラビスの CTO になりました 2020/09/28 gendoc という YAML からドキュメントを生成するコマンドを作った 2020/09/13 ISUCON10 の予選を 7 位で通過した 2019/12/01 Puma の内部構造やアーキテクチャを追う 2019/05/27 Golang の正規表現ライブラリの処理の流れをざっくり掴む 2019/04/29 InnoDB の B+Tree Index について 2019/04/29 InnoDB における index page のデータ構造 2019/04/28 InnoDB はどうやってファイルにデータを保持するのか 2019/01/06 Designing Data-Intens

  • innodb_buffer_pool_sizeのチューニング:どれくらい割り当てる?

    結論としてはinnodbテーブルの全データ量だそうです。 ここ最近はデータベースサーバのリプレースの案件の担当をしているのですが、サーバのサイジングをしていてふと、「どれくらいメモリあれば足りるんだろう」と疑問に思いました。 よく「サーバの全メモリの50%から70%くらい」とか「80%」くらいとか言われますが、それはどちらかというとスワップしないための限界値を示すものであって、理想値ではないですよね。それでいろいろ調べてみたところ、なかなか日語で良いまとめがなかったので、まとめてみようと思います。 目次 そもそもinnodb_buffer_poolとは? 使用状況を確認する(SHOW ENGINE INNODB STATUSでの計測) 適切なinnodb_buffer_pool_sizeは?(チューニング方法) そもそもinnodb_buffer_poolとは? InnoDB maint

  • MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ

    こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの?」みたいな経験はありませんか?不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、

    MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
  • 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のREPEATABLE READにおけるLocking Readについての注意点
    ymm1x
    ymm1x 2017/03/10
    LostUpdate
  • MySQLでINSERTのデッドロックに嵌る人を1人でも減らすために - ichirin2501's diary

    この記事ははてなデベロッパーアドベントカレンダー2015の12月24日の記事です。 昨日は id:stefafafan さんのエンジニア英語でした。 こんにちは、こんばんは。 クリスマス・イヴですね、皆さんはどのような一日を過ごされる(た)のでしょうか。 僕は一人です。 改めまして、先日初めての合コンを経験/失敗して二度と行かないと誓った はてなの id:ichirin2501 です。今回は小ネタとしてMySQL(InnoDB)のBULK INSERTにおけるデッドロックの話をしようと思います。ただ、外部キー制約が絡むと複雑になるので今回は触れません。それについてはこちらを参照ください。 あ、タイトルはオマージュです*1。 Topic 検証環境 INSERTのデッドロック 避けられないケース もしくはロックする リトライ処理に注意 初期データ Duplicateの場合 Deadlockの

    MySQLでINSERTのデッドロックに嵌る人を1人でも減らすために - ichirin2501's diary
  • Nix::WebLab : MySQL(innodb)の再起動 で AUTO_INCREMENTカラム の値がリセット?!

    2011年10月14日18:36 カテゴリMySQLMySQL5.1系 MySQL(innodb)の再起動 で AUTO_INCREMENTカラム の値がリセット?! こちらも以前から気にはしていたのですが、実際に問題が発生したので記録を残しておきます。 InnoDB と MyISAM の AUTO_INCREMENT の違い InnoDBとMYISAMのAUTO_INCREMENT検証 MYSQL.InnoDBでAUTO_INCREMENT値はメモリにだけ保存する。 AUTO_INCREMENTの挙動まとめ(InnoDB) これを知っておかないと、MySQLサーバの再起動でDBデータの不整合が発生するかもしれません! いずれも同じ問題に触れていますが、公式ドキュメントでは以下のように記載されています。 AUTO_INCREMENT カラムが InnoDB 内でどのように機能するか Inn

  • MySQL 5.6のインストール後にチューニングすべき項目 | Yakst

    MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -

    MySQL 5.6のインストール後にチューニングすべき項目 | Yakst
  • MySQL 5.7の新機能完全リスト | Yakst

    MySQL 5.7には150を超える新機能がある。 MySQLのマニュアルはとてもいいものだが、少し長すぎる。これは、新機能の箇条書きリストだ。それぞれの機能について1つずつまとめるように頑張ってある。なので、 InnoDBのネイティブパーティショニング については、InnoDBの項かパーティショニングの項のどちらかにだけ載っている。 MySQL 5.7.8 RC2はここからダウンロードできる それか、yumかaptのリポジトリーからもインストール可能だ。 レプリケーション関連 マルチソースレプリケーション(訳注: 1スレーブに複数マスターを設定可能になった) [ 1 ] オンラインでのGTIDの有効化 [ 1 2 3 ] 準同期レプリケーションの性能向上 [ 1 2 ] ロスレス準同期レプリケーション [ 1 2 ] 準同期レプリケーションでいくつのスレーブからACKが返ってくるまで待つ

    MySQL 5.7の新機能完全リスト | Yakst
  • 挿入と参照ロックに疲れ果てた俺たちは - ichirin2501's diary

    なかったらINSERTしたいし、あるならロック取りたいやん? from ichirin2501 www.slideshare.net 出来事 @ichirin2501 とりあえず何も考えずこの前のロックの話をSlideshareにあげてくれ!!— 柴崎優季 (@shiba_yu36) 2015, 8月 22 はじめに これは先日の社内勉強会で発表したもので、MySQLで特定の問題を解決したいときのノウハウ話です。特定の問題とは、アプリを書いてると「データがなかったINSERTしたい、あるなら排他ロックしつつ取得したい」という要望があったりします。例えば、あるユーザーアクションで初期値もパラメーターで渡されるケースで、データがないならそのままINSERT、既にデータがあるなら取得して状態に依存して更新処理を行いたい場合などです。見かけのロジックは単純に見えますが、MySQLでこれを実現しよう

    挿入と参照ロックに疲れ果てた俺たちは - ichirin2501's diary
  • 我々(主語が大きい)は何故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`

  • 1