2009年10月28日09:33 MySQL MySQLでインデックスを使って高速化するならCovering Indexが使えそう Linux-DB システム構築/運用入門 (DB Magazine SELECTION) 著者：松信 嘉範 販売元：翔泳社 発売日：2009-09-17 おすすめ度： クチコミを見る 最近、この本を読んでいます。非常に面白いし、参考になります〜。中でもインデックスについての記事が特に興味深かったので簡単にまとめてみます。 前提 ・インデックスは検索性能には効果があるが、更新性能は落ちてしまう ・MyISAM と InnoDB ではインデックスの構造が違う ・インデックスは B+Tree インデックスと呼ばれ、ルート、ブランチ、リーフの階層構造になっている ・インデックスはソートされた状態で作成されている まずは MyISAM と InnoDB でのインデックス

MyISAMを使っている時key_buffer_sizeは大きくし過ぎてもいけない 2012-05-02 MyISAMのみを使っているMySQLサーバで、key_buffer_sizeのサイズは大きくても小さくてもダメですよ、という例。 その前にちょっと復習。MySQLの主なストレージエンジンといえばMyISAMとInnoDBだが、データやインデックスのキャッシュの仕組みには、 InnoDB : インデックス、データともMySQLがキャッシュ管理する(innodb_buffer_pool_sizeで設定) MyISAM : インデックスはMySQLがキャッシュ管理する(key_buffer_sizeで大きさを設定)。データはOSのキャッシュ機構におまかせ という違いがある。 ものすごく簡単に言えば、InnoDBの場合はなるべく大きな innodb_buffer_pool_size を設定し

設計 MySQL Workbench は、 DBA、開発者、データアーキテクトがデータベースの設計、作成、管理をビジュアルに行うことができるツールです。データモデラーが複雑な ER モデルの作成、フォワードおよびリバースエンジニアリング作業を行うために必要な機能を含み、難しい変更管理や、通常かなりの時間と労力を必要とするドキュメンテーション作業の為の重要な機能なども含まれています。 詳しくはこちら » 開発 MySQL Workbench は、SQL クエリーの作成、実行、最適化をビジュアルに行えるツールを備えています。SQL エディタは、シンタックスのカラーハイライト、自動補完、SQL ステートメントの再利用、SQL の実行履歴情報を提供します。Database Connections Panel によって MySQL Fabric を含む一般的なデータベース接続の管理が容易になります。

MySQLのインストールが終了した２台がある状態より設定を開始します。 マスターとスレーブの２台がある状態からスタートです。 事前準備 事前に２台のサーバーのデータが同じである必要があります。 mysqldump等でダンプを行い、データベースが完全に同じ状態とします。 マスターの設定 設定ファイルの編集 vi /etc/mysql/my.cnf 以下のように編集 server-id = 1 ↓ server-id = 18 (←ユニークな適当な数字へ変更) また以下を設定ファイル内のどこかに追記(ある場合はそのままでOK) log-bin = mysql-bin アカウントの作成 レプリケーション用のアカウントをマスターに作成する。 このアカウントはREPLICATION SLAVE権限を持っている必要がある 以下はすべての接続を許す’repl’ユーザーを作成する例。(グ

WebHome / ろぐ / Web Web まだ何も載せられていません。 鋭意作成中ですので、今しばらくお待ちください。

このセクションでは、MyISAM テーブル（.MYI および .MYD の拡張子）に対して myisamchk を使用する方法について説明します。ISAM テーブル（.ISM および .ISD の拡張子）に対しては、isamchk を使用してください。 MySQL バージョン 3.23.14 以降、REPAIR TABLE コマンドで MyISAM テーブルを修復できるようになっています。 See 項4.5.5. 「REPAIR TABLE 構文」。 テーブル破損の症状としては、クエリが予期せず中断したり、以下のようなエラーが発生します。 tbl_name.frm is locked against change Can't find file tbl_name.MYI (Errcode: ###) Unexpected end of file Record file is crashed

[root@centos ~]# vi /etc/my.cnf　←　MySQL設定ファイル編集 [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 character-set-server = utf8　←　追加(MySQLサーバーの文字コードをUTF-8にする) [root@centos ~]# /etc/rc.d/init.d/mysqld start　←　MySQL起動 MySQL データベースを初期化中: Installing MySQL system tables... OK Filling he

MySQL の初回起動時には、mysql_install_db コマンドを実行しデータベースを作成し必要な初期設定を行います。Turbolinux 11 Server では、デーモンの実行に必要な mysql というユーザーが自動的に登録されています。 これにより、標準では /var/lib/mysql/ ディレクトリ以下に mysql データベースが作成され、多くのテーブルに権限が設定されます。他にもテスト用の TEST データベースなどが作成されます。また、 mysql_install_db を実行した root ユーザーのみがデータベースユーザーとして登録されており、mysql データベースに対しすべての権限を持ちます。しかし、注意しなければならないのは、初期状態で root に対しパスワードが設定されていない点です。すぐにパスワードを設定します。

[InterDB] [著者HP] [PREVIOUS][UP] Copyright @ 2009, Suzuki Hironobu @ InterDB バージョン 4.0.1から、クエリキャッシュ(Query Cache)機能がサポートされました。 クエリキャッシュとは、実行されたSELECT文の結果をキャッシュ(query_cache)に保存しておき、同じSELECT文が要求された場合は(検索を行わずに)キャッシュに保存されている結果を返す機能です(補足 1)。 なお、キャッシュされたデータに関連するテーブルが変更(UPDATE,INSERT,DELETE)された場合、クエリキャッシュ上の結果は削除されます。よって『テーブルが更新されたのに、古い(キャッシュの)結果が返る』といった心配は*無用*です。 検索結果の保存には、クエリテキスト(SELECT文そのもの)を保存するため

MySQLのquery cacheがうまく利用されていない気がします。 （MySQL 5.0.67-modified-logを利用しています） 疑問点は、query cacheに32MB割り当てましたが、ステータスを見てみるとQcache_free_memoryが17MBあるのに対して、Qcache_free_blocksが1しかありません。 私の認識では、以下の式が成り立つと考えていました。 Qcache_free_memory = Qcache_free_blocks * key cache block size しかしながら実際の数値を代入すると以下となってしまい、認識が間違っていたようです。どこの認識が間違っているか教えていただきたいです。 17865784 = 1 * 1024 mysql> show status like 'QCa%'; +------------------

MySQLサーバには、MySQLクライアントからのクエリとその実行結果をキャッシュし、次回から同じ内容のクエリが要求された場合にキャッシュから応答する、クエリキャッシュという仕組みがあります。キャッシュから応答させることによってデータベースへアクセスする負荷を軽減し、また応答速度自体の向上も狙ったものです。 デフォルト状態ではクエリキャッシュを使用しない設定になっています。以下のように現在の「クエリキャッシュに使用するメモリ量の最大値」であるquery_cache_sizeを確認してください。