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マイスターに学べ！ 即効クエリチューニング
Copyright © 2004-2024 Impress Corporation. An Impress Group Company. All rights reserved.
MySQL AB :: MySQL 4.1 リファレンスマニュアル
概要 これは MySQL リファレンスマニュアルです。 MySQL 8.0 から 8.0.25、および NDB のバージョン 8.0 から 8.0.25-ndb-8.0.25 に基づく NDB Cluster リリースについてそれぞれ説明します。 まだリリースされていない MySQL バージョンの機能のドキュメントが含まれている場合があります。 リリースされたバージョンの詳細は、「MySQL 8.0 リリースノート」を参照してください。 MySQL 8.0 の機能. このマニュアルでは、MySQL 8.0 のエディションによっては含まれていない機能について説明します。このような機能は、ご自身にライセンス付与されている MySQL 8.0 のエディションに含まれていない場合があります。 MySQL 8.0 の使用しているエディションに含まれる機能に関する質問がある場合は、MySQL 8.0
SQL実行計画の疑問解決には「とりあえずEXPLAIN」しよう
EXPLAINステートメントとは EXPLAINは、SQLの実行計画に関する情報を取得するためのステートメントです。実行計画とは「どのインデックスを使って（あるいはインデックスを使わずにテーブルスキャンで）クエリーを処理するか」をMySQLが判断した結果のことです。「インデックスはちゃんと使われているだろうか」「インデックスでどこまでクエリーを効率的に処理できているだろうか」という疑問が湧いた時には、「とりあえずEXPLAINで」となりますよね。 EXPLAINのマニュアルはこちらに、EXPLAIN の出力結果のカラムの意味についてはこちらに記載があります。 EXPLAINの何を見るか たとえば、次のような重いクエリーがあったとしましょう。 mysql> SELECT COUNT(some_column) FROM some_table WHERE some_column = xxx; +
MySQLのリアルタイムモニタリングに「innotop」
innotopとは 「innotop」はMySQLのクエリー実行状況やステータス変数の変化などをtopコマンド風に出力してくれる、Perlで書かれたスクリプトです。中身は非常にシンプル（SHOW GLOBAL STATUSやSHOW ENGINE INNODB STATUSなどをパースして表示するだけ）ですが、 topライクなインターフェイスはリアルタイムモニタリングと相性が良く、非常に直観的でわかりやすい情報を提供してくれます。 筆者はこれを「稼働中のサービスにALTER TABLE（またはpt-online-schema-change）をかける際の負荷モニター」や「MySQLが高負荷状態になっている時の状況確認」などによく利用しています。いかにもtopコマンドと同じような使い方です。 innotopの開発とメンテナンス innotopの立ち位置は少し微妙です。innotopはかつてPe
MySQLおじさんの逆襲
2016/07/02 YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa
MySQL初級者を脱するために勉強してること -INDEX編- - Qiita
欲しいデータを取得するくらいにはSQL書けるし、システム要件を満たすくらいにはテーブル設計は出来る、そんな僕が中級者を脱するために勉強している内容を備忘録的に書き綴ります。 予約語は大文字 その他は小文字で記述しています。 あー、インデックスね、はいはい。作ると参照が速くなるやつでしょ？ そのくらいの知識でしたが、INDEXを適切に運用する上で原理など理解していないと、意味の無いINDEXを作ってしまう事があるので勉強しました。 INDEXとは 今回は多くのRDBMSでサポートされているB-TreeINDEXについて解説します。 B-Treeは以下のような形式でデータを保持しています。 ヘッダブロックでは大まかな値の範囲を保持しており、ブランチブロックではさらに細かい範囲を保持 リーフブロックでは実際の値と行への物理的な位置を保持しています。 INDEXが作成されている事で並び替えが速くな
MySQLパフォーマンスチューニングのためのインデックスの基礎知識 - 久保清隆のブログ
仕事でMySQLのパフォーマンスチューニングをしていて、インデックスについて分かっていないことが多かったので調べたことをメモ。基本的なところから学習しなおした。 MySQLのインデックスは、カラムが特定の値をもつレコードの迅速な検索に使用される。インデックスを使用すれば、数百とか数億ものレコードが入っているテーブルから、一組のレコードを迅速に見つけて取り出すことが可能になる。 しかし、インデックスは速度を改善することもあるが、挿入の邪魔になって遅くなることもある。 インデックスを適切に使うために、まずはインデックスの基本概念をおさえる必要がある。 インデックスの概念 インデックスとは インデックスの仕組みを理解するには、まずMySQLがどのようにクエリに応答するかを知る必要がある。 例えば、 SELECT * FROM phone_book WHERE last_name = 'Hoge'
InnoDBのChange Buffer(MySQL Server Blogより) | Yakst
レコードの挿入時などに発生するセカンダリインデックスの更新は一般的にI/Oコストが高いことで知られる。InnoDBではこれを軽減する為に変更バッファという仕組みがある。MySQL Server Blogから変更バッファ概要の解説記事を紹介する(2015/6/4, Annamalai Gurusami) 免責事項 この記事はMySQL Server Blogの投稿をユーザが翻訳したものであり、Oracle公式の文書ではありません。 THU, 2015/6/4 by Annamalai Gurusami ストレージエンジンを設計するとき、最大の課題となるのは書込み操作の途中のランダムI/Oである。 InnoDBでは、テーブルは1つのクラスタインデックスを持ち、0またはそれ以上のセカンダリインデックスを持つ。インデックスはいずれも、B-treeである。 レコードがテーブルに挿入されるとき、レコー
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の大きなテーブルでのパフォーマンスを改善する10の方法 | Yakst
MySQLコミュニティマネージャのMorgan Tocker氏による、テーブルサイズが大きくなるにつれてINSERTのパフォーマンスが落ちてきてしまうことを防ぐ様々な方法についてのまとめ。 今日は、パフォーマンス問題を引き起こす原因になる、サイズの大きいテーブルのパフォーマンスを改善することについて書いてみようと思う。このアドバイスのうちのいくつかは、たくさんのテーブルをまとめて大きくなっているデータベースにも適用できるが、大抵の場合、独立した大きなテーブルというのは特に問題になりやすいものだ。 一般的に知られていると思われるのは、テーブルを変更する時のスピードは、そのサイズが大きくなるにつれて遅くなることだ。以下の図は、一般的なB+ツリーインデックスのパフォーマンスを時系列で見たものだ。 このグラフは、MySQL@Facebookの記事から拝借したものだ。これは、insert buffe
雑なMySQLパフォーマンスチューニング
26. EXPLAIN mysql> EXPLAIN SELECT * FROM table_1 a JOIN `table_2` s ON a.user_id=s.`user_id` AND s.site_i d=120 WHERE app_id=8250G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: a type: ref possible_keys: PRIMARY,ix_table_1,ix2_table_2,ix3_table_1,idx_table_1_06,idx_table_1_07,idx_t able_1_09 key: idx_table_1_06 key_len: 4 ref: const rows: 13496 Ext
MySQL のチューニング (ボトルネックの検出) - onk.ninja
MySQL のチューニング (ボトルネックの検出) こんにちは！ onk です。 SAPさんが各社とも「ソーシャルアプリは負荷対策が大事」って言っていますね。 弊社でも mixi アプリ(PC)，mixi アプリモバイルをリリースしたときはお祭り状態だったので， ふりかえりも兼ねて MySQL のボトルネックを調べる方法を書いてみました。 (幸い，モバゲーオープンゲームのリリース時はこれらの経験が役に立ったので何ともなかったです) といっても 9 割方 そもそもサーバの設定がおかしい 更新が多いテーブルなのに MyISAM エンジン for 文の中でクエリを発行 INDEX 張ってない データ量がえらいことになってる 辺りなんですけどねー。 基本は下から まず，ボトルネックを調べるときは下の層から上がっていくのが基本です。たぶん。 なので ssh でサーバに入って (LoadAverage
長年の議論に終止符 -- MySQLとMariaDBの違い一覧 - 技術メモ置き場
(2014.12.3追記：このblogの内容は、以下の書籍にも反映させた。) SQLレベルの差異 MariaDB5.5とMySQL5.5ではSQLレベルでの違いはほとんどなかった。autoincrementの最大値の扱いくらい。 ただし、MariaDB10.0でREGEXPがマルチバイト対応になったので、アプリ側は注意。 項目 MySQL MariaDB Autoincrement 最大値に達すると、以降は最大値を繰り返す。Warningのみ。エラーにならない。tinyintなら…,125,126,127,127,127… 最大値-1まで。以降はエラーを返す。tinyintなら…,125,126,ERROR,ERROR,… EXPLAIN文 JSON形式 バージョン5.6から 未対応 Optimizer Trace バージョン5.6から 未対応（ただし、MariaDBのほうがオプティマイザ
MySQLクエリーチューニングことはじめ
はじめに はじめまして、yoku0825といいます。とある企業のDBAです。 この連載を始めるにあたり、簡単に筆者の背景（この連載が、どんな仕事をしている人間によって書かれたか）を説明しておきたいと思います。 筆者は「とある企業でDBA（データベースを専門で面倒を見る人）」として雇用されています。「データベースの面倒を見る」というと、サーバーサイドアプリケーション（データベースの上のレイヤー）を書く人が担当している場合やインフラエンジニア（データベースよりも下のレイヤー）と呼ばれる人たちが担当している場合を多く耳にしますが、筆者はこれを専門的に、仕事をしている時間はほぼデータベースのことを考えていたり検証したりチューニングしたりしています。 このような背景から、筆者はたしなみ程度にしかプログラムが書けません。サーバーサイドアプリケーションはほぼブラックボックスです（見ようと思えば見られると
PDOのサンプルで数値をバインドする際にintにキャストしている理由
先日PHPカンファレンス北海道2016にて「『例えば、PHPを避ける』以降PHPはどれだけ安全になったか」と題して基調講演を担当致しました。その際のスライドはこちら。 そうしたところ、以下のご指摘をいただきました。 @ockeghem スライド拝見しました。39番目のスライドですが、バインドのタイミングでintにキャストするのはちょっと例として良くない気がします。意図的にオーバーフローを起こすことで想定外のレコードの取得を許してしまいそうです。キャストしない方がまだ安全だと思うのですが。 SQLデータベースは、int型よりも大きな桁数を扱える場合があるので、intへのキャストを避けた方がよいという指摘は一般論としてはもっともなものだと考えます。PHPの場合、9223372036854775807を越える数字文字列をint型にキャストすると、9223372036854775807が返ります(
クラウド時代の新常識はこれだ！「MySQL クラウド向け InnoDB チューニング」｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
クラウド時代の新常識はこれだ！「MySQL クラウド向け InnoDB チューニング」 こんにちは。インフラエンジニアの nobuh です。 株式会社インサイトテクノロジー様主催の db tech showcase sapporo 2015 が 9月10日、11日の2日間にわたって開催されました 。 今回、弊社も発表する機会を頂きましたので、インフラエンジニアとして日々 MySQL と格闘して培ったノウハウについてお話させて頂きました。その発表で使ったスライドがこちらです。 クラウド上の仮想サーバーを使って MySQL の管理やチューニングに日々邁進されている方々にご覧いただけると幸いです。 今までにも MySQL に関していくつか記事を掲載していますので、この機会に是非ご覧ください！ → OSC2015北海道で「これだけみれば大丈夫ーCactiによるMySQLパフォーマンス監視のツボ」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL道普請便り 記事一覧 | gihyo.jp