タグ

innodbに関するkamipoのブックマーク (113)

  • MySQL ibdata1が肥大化する理由(記事の意訳) | Ore no homepage

    毎日暑い…。というか蒸し暑い。何年か前にベトナムとカンボジアをバックパッカー旅行したときを思い出す。日の気候が亜熱帯ってか東南アジアっぽくなってきたような…昔はこんな頻繁にゲラリ豪雨とか降らなかったよねー?温暖化ってやつ?日の植生とか変わるんじゃねーのかな…。 えーと、おれがよく見ている技術ブログの一つにPercona社のMySQL Performance Blogがある。そのブログに先日、「Why is the ibdata1 file continuously growing in MySQL?」という記事が投稿された。内容はInnoDBのibdata1の肥大化とその解消方法に関するもの。ibdata1の肥大化を解消する手段は、ダンプをとってDBを作り直してあげないと治らないということは多くのInnoDBユーザが知っていることだと思うけど、おれもInnoDBを触り始めたころは、「気

  • Practical Tips for Using MySQL as a Scalable Key-Value Store

    All of Percona’s open source software products, in one place, to download as much or as little as you need.

    Practical Tips for Using MySQL as a Scalable Key-Value Store
  • QA@IT サービス終了のお知らせ - @IT

    平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識

    QA@IT サービス終了のお知らせ - @IT
    kamipo
    kamipo 2013/04/09
    知らんかった… "Oracle Database、Microsoft SQL Server、PostgreSQLはデフォルトがREAD COMMITTEDです"
  • Handling long texts/blobs in InnoDB - 1 to 1 relationship, covering index

    I have seen that 1 to 1 relationship is sometimes used for MySQL(InnoDB) to avoid significant performance slowdown. To understand the performance difference, it is necessary to understand how InnoDB stores column values to data blocks. Suppose you have the following "diary" table (for storing blog entries).CREATE TABLE diary ( diary_id INT UNSIGNED AUTO_INCREMENT, user_id INT UNSIGNED NOT NULL, po

    Handling long texts/blobs in InnoDB - 1 to 1 relationship, covering index
  • MySQL 5.6のオンラインALTER TABLEを試してたらinnodb_online_alter_log_max_sizeに遭遇した

    MySQL 5.6のオンラインALTER TABLEを試してたらinnodb_online_alter_log_max_sizeに遭遇した 当はpt-online-schema-changeとオンラインALTER TABLEでどう違うかを実験したかったんだけど、 innodb_online_alter_log_max_sizeなんてものの存在を初めて知ったので取り敢えずメモ。 tpcc-mysqlを20WH, 20Connsで流しながらALTER TABLEをする at 5.6.10。 mysql> set foreign_key_checks = 0; ALTER TABLE stock ADD test_col int unsigned not null default 0, ADD KEY (s_ytd); Query OK, 0 rows affected (0.08 sec)

  • MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.11.1 SHOW ENGINE INNODB STATUS と InnoDB モニタ

    Section Navigation      [Toggle] 13.5.11 InnoDB パフォーマンス チューニング ヒント13.5.11.1 SHOW ENGINE INNODB STATUS と InnoDB モニタ InnoDB は InnoDB 内部の状態についての情報をプリントする InnoDB モニタを含んでいます。ご自分の SQL クライアントにスタンダード InnoDB モニタのアウトプットをフェッチする為に、いつでも SHOW ENGINE INNODB STATUS SQL ステートメントを利用する事ができます。 この情報は性能調整をするうえで役立ちます。(もし mysql インタラクティブ SQL クライアントを利用しているなら、\G を通常のセミコロン ステートメント ターミネータと置き換えれば、アウトプットはより読みやすくなります。)InnoDB ロック

  • MySQL InnoDB Deep Talk #1 復習 - SH2の日記

    というわけで、InnoDB Deep Talk #1に参加して発表をしてきました。準備のために今月ちょっと睡眠不足でしたが、かなり刺激になったので参加してよかったです。いちいさんを始め運営のみなさま、雨の降るなか参加されたみなさまどうもありがとうございました。 書籍の紹介 当日木村さんと初めてお会いして、今月発売になった書籍「プロになるための データベース技術入門 〜MySQLforWindows困ったときに役立つ開発・運用ガイド」を献いただきました。どうもありがとうございます! プロになるための データベース技術入門 ?MySQLforWindows困ったときに役立つ開発・運用ガイド 作者: 木村明治出版社/メーカー: 技術評論社発売日: 2012/03/16メディア: 大型購入: 2人 クリック: 101回この商品を含むブログ (4件) を見る先に発売された松信さんの「Webエン

  • MySQL SQLオプティマイザのコスト計算アルゴリズム - SH2の日記

    いちいさんにお誘いいただいて、勉強会で発表をすることになりました。 InnoDB Deep Talk #1 : ATND おそらく初見では内容が難しいと思いますので、先に資料を公開しておきます。 プレゼンテーション資料 (PDF) テストデータ生成スクリプト (JdbcRunnerで利用します。) プレゼンテーション資料からリンクしているウェブサイトの一覧です。 MySQL Bugs: #64567: Last_query_cost is not updated when executing an unique key lookup Understanding and Control of MySQL Query Optimizer: Traditional and Novel Tools and Techniques: MySQL Conference & Expo 2009 - O'R

    MySQL SQLオプティマイザのコスト計算アルゴリズム - SH2の日記
  • InnoDB の圧縮を使うときの運用 - いちいの日記

    .@nippondanji さんにブログにまとめろと言われた気がするのだけど、あんま大したネタではないです。しかも、この作業は失敗する可能性を見越していたのであまり作業ログを取ってなかった...。 ので、ちょっと疑問に思った点を幾つか書いておこうかと思います。 でかい InnoDB なテーブル とあるテーブルが大きくなってしまい、運用がめんどくさくて困ってました。 mysql> show create table hoge\G *************************** 1. row *************************** Table: hoge Create Table: CREATE TABLE `hoge` ( `date` date NOT NULL, `key` int(10) unsigned NOT NULL, `value` double NOT

    InnoDB の圧縮を使うときの運用 - いちいの日記
  • InnoDBの表領域監視 - MySQL Casual Advent Calendar 2011 - まいんだーのはてなブログ

    こんばんはこんばんは!! myfinder です。 MySQL Casual Advent Calendar 2011 始まりました!! 1日目は言い出した自分から書きます。 よく Casualじゃない といわれのないツッコミを受ける MySQL Casual ですが、Casual Advent Calendar という名前の通りライターの皆さん自身が気軽に書けるネタでサクっとupすればOKです。 もちろんですが、綿密な検証に基づいたガチな記事も書ける方がいたら是非お願いします。 きわどいネタは id:kamipo さんや id:do_aki さんがきっとやってくれるので、お二人にお任せしましょう。 はじめに MySQL5.5 からは InnoDB がデフォルトストレージエンジンになりました。 4.xや5.1以前を利用している方も、今となっては InnoDB を使わないのは敢えてそれ以外を

    InnoDBの表領域監視 - MySQL Casual Advent Calendar 2011 - まいんだーのはてなブログ
    kamipo
    kamipo 2011/12/01
    innodb_file_per_tableでゆるふわ運用です…!
  • InnoDBロック競合の確認(MySQL 5.1+InnoDB Plugin, 5.5以降) | キムラデービーブログ

    オープンソースデータベースを加速する「キムラデービー」のブログです。カレー日記を兼ねてます。なお著者は2010-06-01より日オラクルに在籍していますが、サイト(ブログ、またはウェブサイト)において示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。 MySQL 5.1+InnoDB Plugin, 5.5以降でサポートされた以下の三つの情報スキーマテーブルを使うとトランザクションとロックに関わる情報をInnoDBロックモニタよりも簡単でわかりやすく取得することが可能です。 | INNODB_LOCK_WAITS |独自: ロック待ち情報 | INNODB_LOCKS |独自: ロック競合情報 | INNODB_TRX |独自: トランザクション情報 通常一つの接続ではトランザクションのBEGIN; COMMIT;を何度か行います。つまり一つ

    InnoDBロック競合の確認(MySQL 5.1+InnoDB Plugin, 5.5以降) | キムラデービーブログ
  • SystemTapでMySQL 5.5のDisk I/Oを分析する - SH2の日記

    2010年1月の記事SystemTapでMySQLのDisk I/Oを分析するの続きです。以前作成したSystemTapスクリプトは、実はMySQL 5.5のDisk I/Oを分析することができませんでした。というのも、MySQL 5.5からInnoDBが非同期I/Oを行うようになったのですが、以前のスクリプトは非同期I/Oに対応していなかったためです。日はMySQL 5.5におけるInnoDBの非同期I/Oについて、確認していきたいと思います。 非同期I/Oとは 非同期I/Oとは、I/O処理をブロックされることなしに行う方式のことです。通常のI/O処理はそれが完了するまで待たされてしまうのですが、非同期I/Oを用いることでI/O処理の完了を待つことなしに他の処理を進めることができます。以下のウェブサイトでとても詳しく解説されています。 バッファキャッシュとAIO(1) - O'Reil

  • InnoDB行ロック待ちの秒数をセッション単位で指定する[MySQL 5.1, MySQL 5.5の場合] | キムラデービーブログ

    InnoDBの行ロック待ち時間は秒単位でinnodb_lock_wait_timeoutシステム変数に指定した時間待つ仕様になっていました。(デフォルトは50秒) ただMySQLではこの変数はグローバルでしか設定できず、一部のクエリのためだけにグローバル設定を変更するのはインパクトが大きく、特定の接続(セッション)やクエリ単位で設定できないかという機能要求があげられていました。 innodb_lock_wait_timeout is not dynamic, not per session ビルトインのInnoDBでは、この動作は変わりませんが、PluginのInnoDB(MySQL 5.1 + InnoDB Plugin 1.0, もしくはMySQL 5.5(InnoDB Plugin 1.1))では、innodb_lock_wait_timeoutにセッション単位のものが用意され、以下

    InnoDB行ロック待ちの秒数をセッション単位で指定する[MySQL 5.1, MySQL 5.5の場合] | キムラデービーブログ
  • MySQL versions shootout

    As part of work on “High Performance MySQL, 3rd edition”, Baron asked me to compare different MySQL version in some simple benchmark, but on decent hardware. So why not. I took our Cisco UCS C250 and ran simple sysbench oltp read-write all data fits into memory workload. Versions in question: MySQL 4.1 MySQL 5.0 MySQL 5.1 (with built-in InnoDB) MySQL 5.1 with InnoDB-plugin MySQL 5.5 MySQL 5.6 All

    MySQL versions shootout
  • さらなる更新系処理の並列実行性の向上について

    InnoDB性能フリークの皆様(日語圏にいるかどうか解りませんが…)、ご無沙汰しております。MySQL-5.6では我々外野開発者が色々実装してきた改良・機能について人気の高い物・有効な物から順に積極的に取り込まれる様子が見て取れます。これはMySQLの開発コミュニティにとって素晴らしい進歩です。我々の活動が多くのユーザーに支持され、家側からも無視できなくなり、何らかの進歩を阻害する要因が解決されたのではないでしょうか?感無量です。これで私も更に前へ進むことが出来るというものです。というわけで、今回は今まで誰も触れてこなかった問題に触れてみます。 InnoDB の更新系処理のスケーラビリティは、私が過去に数多のRDBMSをベンチマークした経験上、商用RDBMSと比べてまだ明らかに低い印象を受けます。この記事を読むような人は勿論InnoDBのmutex/rw_lockの競合状態の確認はでき

  • MySQLお勉強メモ(InnoDB編) | きぬろぐ

    MySQLお勉強メモ、InnoDB編です。 特徴 データ形式 ibdata files : データ/インデックス領域。UNDO領域/データディクショナリが含まれる。 ib_logfile files : REDOログのようなもの メタデータ : データベースディレクトリに存在(テーブル名.FYM) ibdataはテーブル毎に分割することが可能。テーブルメンテナンスやパーティションで有効。 トランザクション 対応。ACID属性に準拠している。デフォルトはAUTOCOMMIT。 デフォルト分離レベルはrepeatable read。Oracleはread committed。 ロック 行ロック。完全な行レベルロックではなく、インデックスのnext_key_lock。なので、当該レコード以外の部分(中間Node等)でもロックがかかる可能性がある。 ALTER TABLE時にはテーブルロック(RE

  • InnoDB純正の全文検索エンジンInnoDB FTS

    2011-07-28 InnoDB純正の全文検索エンジンInnoDB FTS つい先日、MySQL-5.6.3-labs版がリリースがされました。この中にはInnoDBで動作する全文検索エンジン"InnoDB FTS"が含まれています。これまでは、MySQLとInnoDBの組み合わせで全文検索を行うためにはサードパーティの製品(mroonga 等..)が必要でしたが、これでズバっと選択肢が広がることになります。しかもInnoDBの開発チームが自ら開発した"純正の"エンジンということですから、これは大きな期待が持てます。 いったいどのような製品に仕上がっているのか、ざっくり記事やソースを読んで得た感触を述べてみたいと思います。 written by daijiro.mori どんなエンジンか? エンジンの概要については、 Overview and Getting Started with I

    InnoDB純正の全文検索エンジンInnoDB FTS
  • show innodb status

    CSI Driverを開発し自社プライベートクラウドにより適した安全なKubernetes Secrets管理を実現した話

    show innodb status
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.7.4 ファントム行

    同じクエリーでさまざまな時間にさまざまな行のセットが生成されると、いわゆるファントムの問題がトランザクション内で発生します。 たとえば、SELECT が 2 回実行されたが、1 回目には返されなかった行が 2 回目には返された場合、その行が「ファントム」行です。 child テーブルの id カラム上にインデックスがあり、識別子の値が 100 よりも大きいすべての行をテーブルから読み取り、選択された行の一部のカラムをあとで更新するという意図でロックすると仮定します。 SELECT * FROM child WHERE id > 100 FOR UPDATE; クエリーでは、id が 100 よりも大きい最初のレコードからインデックスがスキャンされます。 このテーブルには id の値が 90 と 102 の行が格納されているものとします。 スキャン範囲内のインデックスレコード上に設定されたロ

  • InnoDBテーブルでインデックスを拡張するとパフォーマンスが落ちるかも from MySQL Performance Blog - stnard.jp

    Extending Index for Innodb tables can hurt performance in a surprising way 多くのキーを使うクエリーのときに、よく最適化するときにインデックスを拡張する。通常は問題なく、インデックスの長さが劇的に増加しない限り、インデックスを使うクエリーは新しいインデックスの先頭を使うことができる。では、そうではない場合を見てみよう。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 CREATE TABLE `idxitest` ( `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT, `a` int(11) NOT NULL, `b` int(11) NOT NULL, PRIMARY KEY (`id`),