なぜあなたは SHOW ENGINE INNODB STATUS を読まないのか - そーだいなるらくがき帳
この記事は、MySQL Casual Advent Calendar 2017の20日目の記事です。 煽り気味のタイトルですがみなさん SHOW ENGINE INNODB STATUS 読んでますか？ SHOW ENGINE INNODB STATUS \G 見づらいのなんとかならんのか。— そーだい@初代ALF (@soudai1025) 2016年12月20日 わかる。でもMySQLの振る舞いを知る中でSHOW ENGINE INNODB STATUSを読まざる得ない場面はそこそこあります。 どんな時に必要になるのでしょうか？ そこでSHOW ENGINE INNODB STATUSにまつわる話を書きます。 SHOW ENGINE INNODB STATUS をまず読みやすくする まず末尾に \G を付けましょう。 これで3倍読みやすくなります。 次に pager less -S を
InnoDB Deep Talk #2 (仮) に引っ張りだされました。
先日、「InnoDB Deep Talk #2 (仮)」というイベントでお話ししてきました。 「事前情報は講演者の名前のみ(内容未定)」という、振り返ってみると異常な状況にも関わらずお集まりいただきありがとうございました。 今回は、前回とは違って少しだけ公開を意識して作ったあったので公開してみます。 これで手持ちのネタは出し尽くしたので、また暫くブログの更新は無いかもしれませんがご容赦を。。。
たった3秒でInnoDBのデータローディングが快適になるライフハック
MySQLに限った話ではないが、データベース管理システムに大量のデータを投入するのは時間が掛かり大変苦痛を伴う作業である。劇的に効能があるわけではないが、MySQLを利用しているとき、特にInnoDBを使っている場合にはデータの投入を高速化するためにいくつかテクニックがあるので紹介しよう。皆さんの作業時間が短縮され、少しでも早く帰路に着いたりサービスインさせたりという形でお役に立てれば幸いである。ちなみに、タイトルはネタであるのだが、もし本当に3秒で以下の全ての設定を行えた人が居たら教えて頂きたい！ ログファイルサイズの調整データ投入時に限った話ではないが、ログファイルサイズを調整するのは更新性能にとって非常に重要なファクターである。バッファプールのサイズが重要なことに代わりはないが、同じぐらいログファイルのサイズも重要である。InnoDBはログファイルを使い切ってしまうと、バッファプール
innodb_flush_log_at_trx_commit 変えたらIOめっちゃ減った - yet another pudding
Mysql で、innodb_flush_log_at_trx_commit の初期値は 1 となっています。COMMIT時 にログファイルに書き込まれ、同時にログファイルがディスクにフラッシュされます。ディスク上のログファイルに確実に書き込まれてるので、突然クラッシュしてもログから復元できますよ、安全ですよ、という設定です。 これが 0 だと、ログバッファからログファイルへの書き込みは COMMIT頻度にかかわらず毎秒一回、ログファイルのディスクへのフラッシュも毎秒一回です。 これが 2 だと、ログバッファからログファイルへの書き込みは COMMIT時に発生して、ログファイルのディスクへのフラッシュは毎秒一回です。 なので、もし障害などで突然サーバが停止したら、最後の1秒分はディスクにフラッシュされていないので消失してしまいます。 ちょっとでも消えたら困るっていう用途は非常に多いと思うの
MySQLを5.1から5.6.10に上げたらなんか壊れた話 | いちよんこーど
いちよんこーど Notion/Jira/Confluence/GitHub/OneLogin/AWS/GCPなど開発管理ツールを試して運用していくブログ おそらく MySQL5.1 から 5.6 へ上げた影響だと思われるが、 ユーザの権限を設定することができなくなっていた。 mysql> grant all privileges on testdb.* to testuser@localhost identified by 'testpass'; ERROR 2013 (HY000): Lost connection to MySQL server during query エラーログには以下のような文言がでていた。 バージョン違いの SQL をぶち込んだため、5.6 で必要なテーブルがなくなったのかな。 InnoDB: Error: Table "mysql"."innodb_table
my.cnfでinnodb関連の設定後、MySQLが起動しなくなった
MySQLのインストールを行う際、 インストール後一度サーバが起動するか確認したあとに、 MySQLのパラメータ設定を行う人が多いかと思います。 innodbを使用する場合、my.cnfの innodb_data_file_path の設定を 行う方が多いと思いますが 設定後、MySQLが起動エラーになってしまった場合の対処法をお知らせします。 まず、innodb_data_file_pathのパラメータの意味について簡単に説明します。 innodbでは ib_dataやib_log で始まる名前のファイルにデータやログが書き込まれます。 記述法は以下のようになります。 innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend この設定では、ibdata1 というファイルを2GB確保し、 足りなくなった場合は ibdata2
クエリキャッシュを切ったほうがいイカ？ ベンチマークしてみた - 酒日記 はてな支店
カジュアル！(挨拶) このエントリは MySQL Casual Advent Calendar 2011 の18日目の記事です。 昔、専ら PostgreSQL を使っていた頃、MySQL のクエリキャッシュって簡単に性能上がるしみたいだし羨ましいなあ、と思っていました。そのため、1年ほど前から業務で MySQL を使うようになっても、クエリキャッシュは当然のごとく有効にしておりました。 ところが先日 DSAS開発者の部屋:クエリキャッシュは切ったほうがいいんじゃなイカ？ というエントリを読みまして、クエリキャッシュはグローバルロックを獲得するとのこと。これはちょっと検証してみなければなるまい、ということでベンチマークをしてみました。 ベンチマーク結果 結果は別ページにまとめました benchmark script と my.cnf ざっくりと説明しますと、 平均 260 byte/行、1
MySQLのメモリ関係のシステム変数 - 祈れ、そして働け ～ Ora et labora
概要 MySQLのメモリ関係のシステム変数について、まとめてみました。 構成 MySQL Ver 14.14 Distrib 5.5.14, for Linux (x86_64) using EditLine wrapper メモリサイズの見積もり はじめに、MySQLのプロセスが必要とするメモリサイズの見積もり方法を確認します。 必要なメモリサイズ ＝ グローバルバッファのサイズ ＋（スレッドバッファのサイズ × 最大同時接続数）グローバルバッファのサイズは以下の方法で計算します。 max_heap_table_sizeは必ずしも割り当てられる訳ではありませんが、安全側に倒すため、計算に含めています。 グローバルバッファのサイズ ＝ key_buffer_size ＋ innodb_buffer_pool_size ＋ innodb_additional_mem_pool_size ＋
MySQL(InnoDB) で "Index column size too large. The maximum column size is 767 bytes." いわれるときの対策 - かみぽわーる
tl;dr: MySQL 5.5.14以降だとinnodb_large_prefixオプションで3072バイトまでインデックス張れる MySQL(InnoDB)では、ひとつのカラムのキープレフィックスの最大値が767バイトという制限があるので、ついうっかりして Index column size too large. The maximum column size is 767 bytes. とか Specified key was too long; max key length is 767 bytes といったエラーを見たことある人は多いのではないかと思います。 よくあるケースだと、varchar(256)以上のutf8なカラムにインデックスを張ろうとするとこのエラーとご対面できます。 CREATE TABLE t (c varchar(256), index (c)); ERROR
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
MySQLでインデックスを使って高速化するならCovering Indexが使えそう - (ﾟ∀ﾟ)o彡 sasata299's blog
2009年10月28日09:33 MySQL MySQLでインデックスを使って高速化するならCovering Indexが使えそう Linux-DB システム構築/運用入門 (DB Magazine SELECTION) 著者：松信 嘉範 販売元：翔泳社 発売日：2009-09-17 おすすめ度： クチコミを見る 最近、この本を読んでいます。非常に面白いし、参考になります〜。中でもインデックスについての記事が特に興味深かったので簡単にまとめてみます。 前提 ・インデックスは検索性能には効果があるが、更新性能は落ちてしまう ・MyISAM と InnoDB ではインデックスの構造が違う ・インデックスは B+Tree インデックスと呼ばれ、ルート、ブランチ、リーフの階層構造になっている ・インデックスはソートされた状態で作成されている まずは MyISAM と InnoDB でのインデックス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Loading...
基本に戻ってInnoDBの話をします
http://www.mysqlpracticewiki.com/index.php/My.cnf%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB