タグ

mysqlに関するk-holyのブックマーク (191)

  • MySQLのメモリ設定を追求してみよう – OpenGroove

    (2015年1月追記:これは現時点で約5年前に書いた記事です。各種パラメータは名称や仕様が変更されている可能性があるため、最新の情報を参考にしてください) MySQLのメモリの話を考えていたら何が何だか分からなくなってきたので、my.cnfでの設定に絡めてまとめてみようと思う。そもそも、MySQLサーバにおいてMySQLのプロセスがトータルで使用するメモリは、どれくらいに見積もっておけばいいだろうか。参考書やネット上では以下のような計算式が紹介されている。 max_connections x [スレッド領域用メモリ合計値] に、以下をプラス。 [グローバル領域用メモリ合計値] DB専用サーバの場合だとこの値をマシン搭載メモリの8〜9割くらいにする、と想定するのがひとつの指針となるようだ。しかし32bitLinux OSの場合は2〜3GBまでの制限があるため、搭載メモリがそれ以上あったとし

    k-holy
    k-holy 2012/07/06
    MySQLのメモリ構成図
  • http://blog.flatlabs.net/20100727_212649/

    k-holy
    k-holy 2012/07/06
    innodb_log_file_size変更時の注意
  • InnoDBのファイルサイズ管理

    最近、InnoDBのデータ領域(テーブルスペース)が成長してしまって元に戻すことが出来ない場合の対処についてよく質問されるので、今日はテーブルスペースが成長することへの対策について説明しよう。(ここのところMySQLネタが続いているが、Planet MySQL語版を意識しているわけではないのであしからず!!<<ホントかよ?!>俺) InnoDBのテーブルスペースが成長してしまうのは、ズバリ自動拡張しているからである。テーブルスペースに対して何もオプションを指定しないと、デフォルトでは次のような設定と同じテーブルスペースが作成される。 [mysqld] innodb_data_file_path=ibdata1:10M:autoextend サイズは10MBしかないが、自動拡張するのである。自動拡張してしまうと何が問題なのかというと、データが増えた場合にファイルシステムの空き領域を使い切

    InnoDBのファイルサイズ管理
    k-holy
    k-holy 2012/07/06
    innodb_file_per_tableとinnodb_data_file_path
  • DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!

    MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in

    DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!
  • AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ

  • http://www.2ch-search.net/blog/3

  • http://blog.monoweb.info/article/2011033122.html

  • レプリケーションを利用したMySQLのサービス無停止バックアップ | QK

    MySQLのバックアップってどうやってますか?単純なバックアップであれば、mysqldumpでもデータディレクトリを丸ごとコピーでも好きな方法でやればいいと思いますが、じゃあそれが止めることが許されないサービスだったら?というところを突き詰めて「サービス無停止バックアップ」について考えてみたいと思います。 ここで説明する想定の条件は以下の通りとします。 ・MySQLのサーバ数は、20台で、20台それぞれが異なるスキーマである ・MySQLのテーブルはInnoDBテーブルのみ ・MySQLサーバーを止めずにバックアップする ・4重のバックアップ手法をとり、どんなことがあろうと障害復旧時点までリカバリできる構成を作ること ここでは、有償の製品の話は割愛しますね。MySQLでinnodbのバックアップ方法は2通りあり、一つは、前述の通りなのですが、MySQLサービスを停止して、ディレクトリごと、

    k-holy
    k-holy 2012/03/27
    1台の集中バックアップサーバで複数レプリケーションしてmysqldump
  • Replication Booster for MySQL を試す - blog.nomadscafe.jp

    松信さんが作った 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を読み取り、更

    k-holy
    k-holy 2012/03/23
    Replication Booster レプリケーションのMaster更新時に対象データをメモリに乗せて時間短縮
  • Advent Calendar 14日目 MySQL と PHP の間を詳しく見てみる - do_aki's 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

    Advent Calendar 14日目 MySQL と PHP の間を詳しく見てみる - do_aki's log
  • http://www.mysqlpracticewiki.com/index.php/Extra_field

  • MySQL :: MySQL 5.1 リファレンスマニュアル :: 6.2 SELECTステートメントおよびその他のクエリの最適化

    第 1 にすべてのクエリに影響を及ぼすことが 1 つあります。アクセス権システムのセットアップの複雑性が増すほど、オーバヘッドも増加します。 GRANTステートメントを発行する際に単純なアクセス権を使用することで、クライアントがステートメントを事項する際のMySQLにアクセス権確認オーバーヘッドを減らすことができます。例えば、テーブルレベルやカラムレベルの特権を許可したくない場合、サーバはtables_privとcolumns_privテーブルの内容を確認する必要はまったくありません。同じように、どのアカウントにもリソース制限を設けない場合、サーバは性能リソースカカウンティングを行う必要がありません。大量の処理が必要なときは、GRANT を使用しないことで時間を節約できる場合もあります。 明示的な MySQL 関数に関わる問題がある場合は、常に mysqlクライアントでBENCHMARK(

    k-holy
    k-holy 2012/03/09
  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.2.1.16 ORDER BY の最適化

    このセクションでは、MySQL が ORDER BY 句を満たすためにインデックスを使用できるタイミング、インデックスを使用できない場合に使用される filesort 操作、および ORDER BY に関するオプティマイザから使用可能な実行計画情報について説明します。 セクション8.2.1.19「LIMIT クエリーの最適化」 で説明されているように、LIMIT を使用する場合と使用しない場合で ORDER BY が異なる順序で行を返すことがあります。 場合によっては、MySQL でインデックスを使用して ORDER BY 句を満たし、filesort 操作の実行に伴う余分なソートを回避できます。 インデックスのすべての未使用部分と追加の ORDER BY カラムが WHERE 句の定数であるかぎり、ORDER BY がインデックスと完全に一致しない場合でもインデックスを使用できます。 ク

    k-holy
    k-holy 2012/03/09
    ORDER BYのインデックス利用条件
  • untitled: [MySQL]日付時刻型の列から「毎日○○時」指定で選択する

    k-holy
    k-holy 2012/03/08
    様々な日付指定でのEXPLAIN
  • MySQLのインデックスを学ぶ (1) - 刺身☆ブーメランのはてなダイアリー

    実践ハイパフォーマンス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のインデックスを学ぶ (1) - 刺身☆ブーメランのはてなダイアリー
  • MySQLのEXPLAINを徹底解説!!

    以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ

    MySQLのEXPLAINを徹底解説!!
    k-holy
    k-holy 2012/03/08
    EXPLAINの読み方
  • MySQLでランダムにN件取得する方法のパフォーマンス比較 - しんふぉにゃん

    こちらと同じような比較を自分でもやってみました。 私はMySQLに関してあまり深い知識を持っていないため、検証の方法や設定値の問題などがあるかもしれませんが、ざっくりとした傾向は分かるかと思います。 まず、今回使用しているテスト用環境のバージョン等です。 OS Fedora Core 7 MySQL 5.0.45 PHP 5.2.6 # やや古い・・・。 また、テストで使用するテーブルは以下のような簡単なものです。 ┌────┬───────┬───┐ │ 名前 │   型   │サイズ│ ├────┼───────┼───┤ │id  │int    │   │主キー ├────┼───────┼───┤ │name│varchar│ 64│ └────┴───────┴───┘ まず今回テストした6つの方法を簡単に説明します。 (1) RAND()列を追加してソート 以下のようなSQL

    k-holy
    k-holy 2012/02/23
    MySQLでランダムにn件取得する方法いろいろ。件数次第だけど最初はとりあえず(3)かな…本当のランダムが必要なのか、それっぽく見えればいいのかも検討
  • mysqlのcollateを使って大文字-小文字や全角-半角を無視した検索 - end0tknr's kipple - web写経開発

    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のcollateを使って大文字-小文字や全角-半角を無視した検索 - end0tknr's kipple - web写経開発
    k-holy
    k-holy 2012/01/25
    collate = utf8_unicode_ciの動作
  • MySQL InnoDBのネクストキーロック おさらい - SH2の日記

    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

    MySQL InnoDBのネクストキーロック おさらい - SH2の日記
    k-holy
    k-holy 2012/01/17
    InnoDBのネクストキーロック
  • KLab

    ご指定のページが見つかりませんでした URLの変更、もしくはページが削除された可能性があります。 お手数ですが、以下のリンクから目的のページをお探しください。

    KLab