最近、InnoDBのデータ領域(テーブルスペース)が成長してしまって元に戻すことが出来ない場合の対処についてよく質問されるので、今日はテーブルスペースが成長することへの対策について説明しよう。(ここのところMySQLネタが続いているが、Planet MySQL日本語版を意識しているわけではないのであしからず!!<<ホントかよ?!>俺) InnoDBのテーブルスペースが成長してしまうのは、ズバリ自動拡張しているからである。テーブルスペースに対して何もオプションを指定しないと、デフォルトでは次のような設定と同じテーブルスペースが作成される。 [mysqld] innodb_data_file_path=ibdata1:10M:autoextend サイズは10MBしかないが、自動拡張するのである。自動拡張してしまうと何が問題なのかというと、データが増えた場合にファイルシステムの空き領域を使い切
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
MySQLのバックアップってどうやってますか?単純なバックアップであれば、mysqldumpでもデータディレクトリを丸ごとコピーでも好きな方法でやればいいと思いますが、じゃあそれが止めることが許されないサービスだったら?というところを突き詰めて「サービス無停止バックアップ」について考えてみたいと思います。 ここで説明する想定の条件は以下の通りとします。 ・MySQLのサーバ数は、20台で、20台それぞれが異なるスキーマである ・MySQLのテーブルはInnoDBテーブルのみ ・MySQLサーバーを止めずにバックアップする ・4重のバックアップ手法をとり、どんなことがあろうと障害復旧時点までリカバリできる構成を作ること ここでは、有償の製品の話は割愛しますね。MySQLでinnodbのバックアップ方法は2通りあり、一つは、前述の通りなのですが、MySQLサービスを停止して、ディレクトリごと、
松信さんが作った Replication Booster for MySQL をデータサイズが大きいデータベースに対して使ってみました。 Yoshinori Matsunobu’s blog: Making slave pre-fetching work better with SSD github - yoshinorim/replication-booster-for-mysql Replication Booster for MySQL をものすごく簡単に説明すると、以下のようになるでしょうか。 MySQL でレプリケーションを設定した場合、マスターのバイナリログをIOスレッドが読み取り、relay-logへ記録します。そしてSQLスレッドがrelay-logから読み取ってテーブルを更新して行きます。Replication Booster を実行するとrelay-logを読み取り、更
かじゅある! (挨拶) 本記事は、 MySQL Casual Advent Calendar 2011 (http://mysql-casual.org/2011/11/mysql-casual-advent-calendar-2011.html) 14日目です。 そして同時に do_aki Advent Calendar 2011 (http://atnd.org/events/22834) の 14日目でもあります ;-p PHP と聞いただけで逃げ出す方も居られますでしょうが、 やはり私、PHP を使っておりまして、それ以外のネタがなかなか見つからないので、 かじゅあるに PHP ネタを投入することにしました。 MySQL を利用する手段 PHP アプリケーションから MySQL を利用する方法は結構様々です。 Doctrine (http://www.doctrine-projec
第 1 にすべてのクエリに影響を及ぼすことが 1 つあります。アクセス権システムのセットアップの複雑性が増すほど、オーバヘッドも増加します。 GRANTステートメントを発行する際に単純なアクセス権を使用することで、クライアントがステートメントを事項する際のMySQLにアクセス権確認オーバーヘッドを減らすことができます。例えば、テーブルレベルやカラムレベルの特権を許可したくない場合、サーバはtables_privとcolumns_privテーブルの内容を確認する必要はまったくありません。同じように、どのアカウントにもリソース制限を設けない場合、サーバは性能リソースカカウンティングを行う必要がありません。大量の処理が必要なときは、GRANT を使用しないことで時間を節約できる場合もあります。 明示的な MySQL 関数に関わる問題がある場合は、常に mysqlクライアントでBENCHMARK(
このセクションでは、MySQL が ORDER BY 句を満たすためにインデックスを使用できるタイミング、インデックスを使用できない場合に使用される filesort 操作、および ORDER BY に関するオプティマイザから使用可能な実行計画情報について説明します。 セクション8.2.1.19「LIMIT クエリーの最適化」 で説明されているように、LIMIT を使用する場合と使用しない場合で ORDER BY が異なる順序で行を返すことがあります。 場合によっては、MySQL でインデックスを使用して ORDER BY 句を満たし、filesort 操作の実行に伴う余分なソートを回避できます。 インデックスのすべての未使用部分と追加の ORDER BY カラムが WHERE 句の定数であるかぎり、ORDER BY がインデックスと完全に一致しない場合でもインデックスを使用できます。 ク
実践ハイパフォーマンスMySQL 第2版とLinux-DBシステム構築運用入門を読んで、 MySQL のインデックスについて勉強しなおしている。理解が曖昧だった部分の知識を深められたり、自分の間違いに気づけたりして、とても収穫が多い。 フルテーブルスキャンとフルインデックススキャン Linux-DBシステム構築運用入門 P185 に書いてあるケース。インデックスを利用してても対象レコード数が多いとランダムI/Oが大量に発生して遅くなる。読むべきレコード数が多いのならばフルテーブルスキャンのほうがI/O一回で多くのブロックを読み込めるので速い。 IGNORE INDEX ヒントを与えてパフォーマンスを改善するという例があった。 マルチカラムインデックスと範囲検索 SELECT * FROM users WHERE a = ? AND b >= ? and (c IS NULL OR c >=
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ
こちらと同じような比較を自分でもやってみました。 私はMySQLに関してあまり深い知識を持っていないため、検証の方法や設定値の問題などがあるかもしれませんが、ざっくりとした傾向は分かるかと思います。 まず、今回使用しているテスト用環境のバージョン等です。 OS Fedora Core 7 MySQL 5.0.45 PHP 5.2.6 # やや古い・・・。 また、テストで使用するテーブルは以下のような簡単なものです。 ┌────┬───────┬───┐ │ 名前 │ 型 │サイズ│ ├────┼───────┼───┤ │id │int │ │主キー ├────┼───────┼───┤ │name│varchar│ 64│ └────┴───────┴───┘ まず今回テストした6つの方法を簡単に説明します。 (1) RAND()列を追加してソート 以下のようなSQL
mysqlでは、collate = utf8_unicode_ciを指定すると、大文字-小文字だけでなく、全角-半角を同一視できるそうですが、実際にどの文字が同一視されるのかを試してみました。 collateとは http://tetlist.info/2009/01/mysql ↑このエントリでも分かりやすく紹介されていますが、collate(照合順序)とは、文字を比較(一致/不一致や表示順)する際のルールです。 utf8_unicode_ciで大文字-小文字だけでなく、全角-半角を同一視 mysqlのデフォルトcollateであるutf8_general_ciでは、大文字-小文字を同一視しますが、utf8_unicode_ciでは、さらに半角-全角も同一視します。 ※ci とは Case Insensitive の略称のようです tableやcolumn自体にcollateを設定する
MySQLのInnoDBストレージエンジンは行ロックをサポートしています。しかしOracleと同じ感覚でアプリケーションを作っていると、思わぬところでデッドロックに出くわすことがあります。これはInnoDBのロック範囲がOracleよりも微妙に広いためです。 実際の例で確認してみましょう。 mysql> select * from t; +----+------+ | c1 | c2 | +----+------+ | 10 | a | | 15 | a | | 20 | a | | 25 | a | | 30 | a | | 35 | a | | 40 | a | | 45 | a | | 50 | a | +----+------+c1列は主キーになっています。1つめのセッションで以下のSQLを実行します。 mysql> set tx_isolation = 'repeatable-r
From: zen kishimoto <zen kishimoto <zen@xxxxxxxxxx>> Date: Sat, 03 Sep 2005 09:24:15 -0700 Subject: [mysql 12071] 階層化されたデータをMySQLで扱う (Managing Hierarchical Data in MySQL) http://dev.mysql.com/tech-resources/articles/hierarchical-data.html (図はこのサイトを参照のこと) Mike Hillyer著 初めに 多くのユーザーは一回くらいはSQLデータベース内で、階層化したデータを 扱ったことがあると思います。そのときはリレーショナル データベースは階層化したデータ用に開発されなかったと考えたと思います。 リレーショナルデータベースのテーブルは階層化されておらず
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く