関連: DatabaseManagementSystem
----
リファレンス
-MySQL AB :: MySQL Documentation
--http://dev.mysql.com/doc/
-MySQL :: MySQL 5.1 リファレンスマニュアル
--http://dev.mysql.com/doc/refman/5.1/ja/
-MySQL
--http://www.cgis.biz/mysql/mysql.htm
---簡易リファレンス
-Amazon.co.jp： MySQL全機能バイブル ~現場で役立つAtoZ~: 鈴木 啓修: 本
--http://www.amazon.co.jp/exec/obidos/ASIN/4774139750/nilabwiki-22/ref=nosim
----
カラム型
-MySQL :: MySQL 5.1 リファレンスマニュアル :: 10 データタイプ
--http://dev.mysql.com/doc/refman/5.1/ja/data-types.html
----
インデックス
-MySQL AB :: MySQL 4.1 リファレンスマニュアル :: 6.5.3 CREATE TABLE 構文:
--http://dev.mysql.com/doc/refman/4.1/ja/create-table.html
---> KEY は、通常 INDEX のシノニム。 バージョン 4.1 以降、キー属性 PRIMARY KEY は単に KEY として指定することもできる。この機能は他のデータベースとの互換性を考慮して実装された。
-text型にインデックス設定するときは末尾がインデクス長に空白で埋められるのでUNIQUE制約違反に注意。
-MySQL:インデックスまとめメモ
--http://www.res-system.com/item/550
---MySQLは1つのクエリーで1つのテーブルに対し、1つのインデックスしか機能しない
-インデックスの基礎知識
--http://www.hi-ho.ne.jp/tsumiki/doc_1.html
-MySQL :: MySQL 5.1 リファレンスマニュアル :: 12.1.7 CREATE INDEX 構文
--http://dev.mysql.com/doc/refman/5.1/ja/create-index.html
---MySQL 5.1のTEXT型に設定できるインデックスのプリフィックス長は1000バイトまで
---CREATE INDEX で指定する数値は文字数(例えば1文字2バイトのエンコーディングなら500文字までしか指定できない)
-MySQL AB :: MySQL 4.1 リファレンスマニュアル :: 5.2.1 EXPLAIN 構文（SELECT に関する情報の取得）
--http://dev.mysql.com/doc/refman/4.1/ja/explain.html
--->キーワード EXPLAIN を SELECT ステートメントの前に置いた場合、MySQL によってテーブルの結合状況と順序に関する情報が提供され、テーブルの SELECT の処理方法が説明されます。
--->EXPLAIN を利用すると、より速くレコードを検索する SELECT を得るために、どの時テーブルにインデックスを追加しなければならないかを確認できます。
--->最適化方法の選択に影響を及ぼすキーの、カーディナリティなどのテーブル統計を更新するために、ANALYZE TABLE を定期的に実行する必要があります。 See 項4.6.2. 「ANALYZE TABLE 構文」。
-テーブルにデータを入れてから FULLTEXT インデクスを貼りましょう…… orz
--MySQL 4.1 リファレンスマニュアル :: 6.8 MySQL 全文検索: http://dev.mysql.com/doc/refman/4.1/ja/fulltext-search.html
--->FULLTEXT インデックスは MyISAM テーブルにのみ使用され、CHAR 型、VARCHAR 型、TEXT 型のいずれかのカラムから作成することができます。この作成は CREATE TABLE 時に行えますが、ALTER TABLE か CREATE INDEX を使用して後から追加することも可能です。データセットのサイズが大きい場合は、FULLTEXT インデックスを持たないテーブルにデータをロードしてから、ALTER TABLE（または CREATE INDEX）を使用してインデックスを作成する方が処理がはるかに迅速です。すでに FULLTEXT インデックスを持っているテーブルにデータをロードすると、処理がかなり遅くなることがあります。
----
チューニング
-mysql を高速化したいときに読むメモ (TechKnowledge)
--http://tech.media-index.jp/2006/11/mysql_1.html
-MySQLのチューニング - ［データベース］All About
--http://allabout.co.jp/internet/database/closeup/CU20040722A/
-MySQL AB :: MySQL 4.1 リファレンスマニュアル :: 5.5.2 サーバパラメータのチューニング
--http://dev.mysql.com/doc/refman/4.1/ja/server-parameters.html
--->MySQL サーバをチューニングする際に使用される最も重要な変数は key_buffer_size と table_cache の 2 つです。他の変数の変更を行う前にこの変数をあらかじめ適切に設定しておくことで自信がつきます。
-MySQL AB :: MySQL 4.1 リファレンスマニュアル :: 4.6.8.4 SHOW VARIABLES
--http://dev.mysql.com/doc/refman/4.1/ja/show-variables.html
--->ft_min_word_len FULLTEXT インデックス内の単語の最短長。 注意: この変数を変更後、FULLTEXT インデックスを再ビルドする必要がある。このオプションは MySQL 4.0 で導入された。
--->ft_max_word_len FULLTEXT インデックス内の単語の最大長。 注意: この変数を変更後、FULLTEXT インデックスを再ビルドする必要がある。このオプションは MySQL 4.0 で導入された。
--->key_buffer_size インデックスブロックはバッファされ、すべてのスレッドによって共有される。key_buffer_size は、インデックスブロック用に使用されるバッファのサイズである。
--->インデックス処理（すべての読み取りと複数書き込み）のパフォーマンスを向上させるため、この値は可能な限り大きくする。主に MySQL を実行する 256M マシンでは、64M が一般的である。ただし、これを大きくしすぎると（たとえば、メモリ合計の 50% 以上など）、システムがページングを開始し、処理速度が非常に遅くなる可能性がある。MySQL ではデータ読み取りをキャッシュしないため、OS ファイルシステムのキャッシュ用に領域を確保しておくことが必要である。
--->キーバッファのパフォーマンスを確認するには、SHOW STATUS を実行し、Key_read_requests、Key_reads、Key_write_requests、Key_writes の各変数を調べる。Key_reads/Key_read_request の比率は通常、0.01 より小さい。Key_write/Key_write_requests の比率は、操作がほとんど更新と削除だけの場合、通常は約 1 になる。しかし、同時に多くの影響がある更新を頻繁に行う場合や、DELAY_KEY_WRITE を使用する場合はかなり小さくなることもある。 See 項4.6.8. 「SHOW 構文」。
--->max_allowed_packet 1 パケットの最大サイズ。メッセージバッファは net_buffer_length バイトに初期化されるが、必要に応じて max_allowed_packet バイトまで大きくできる。このデフォルト値は、大きな（おそらく不正）パケットを受けるには小さすぎる。大きな BLOB カラムを使用している場合には、この値を大きくする必要がある。使用する最大の BLOB と同じ大きさにすべきである。max_allowed_packet のプロトコル制限は MySQL 3.23 で 16MB、MySQL 4.0 で 1GB である。
--->net_read_timeout 読み取りを停止する前に、接続からのデータを待機する秒数。注意: 接続からのデータが期待されない場合、タイムアウトは write_timeout によって定義される。slave_net_timeout も参照のこと。
--->read_buffer_size（以前は record_buffer） 順次スキャンを実行する各スレッドは、スキャンする各テーブルにこのサイズのバッファを割り当てる。多くの順次スキャンを実行する場合には、この値を大きくすることが必要である。
--->query_alloc_block_size クエリの解析および実行時に作成されるオブジェクトに割り当てられるメモリ割り当てブロックのサイズ。メモリの断片化に問題がある場合、これを少し大きくすると改善する可能性がある。
--->query_cache_limit これより大きい結果はキャッシュしない（デフォルトは 1M）。
--->query_cache_size 古いクエリの結果を保存するために割り当てられたメモリ。この値を 0 にすると、クエリキャッシュは無効になる（デフォルト）。
--->query_cache_type 次のいずれかの値（数値のみ）を設定できる。
--->skip_networking ローカル（ソケット）接続のみを認める場合は ON。
-MySQL AB :: MySQL 4.1 リファレンスマニュアル :: 4.6.8.3 SHOW STATUS
--http://dev.mysql.com/doc/refman/4.1/ja/show-status.html
--->Handler_read_first 最初のエントリがインデックスから読み取られた回数。 この値が大きい場合、サーバが何回もフルインデックススキャンを実行していると考えられる。たとえば、SELECT col1 FROM foo を実行したときに col1 がインデックスになっているとそうなる。
--->Handler_read_key キーに基づくレコード読み取り要求の回数。この値が大きい場合、クエリおよびテーブルが適切にインデックス化されていると考えられる
--->Handler_read_rnd_next データファイルでの次のレコードの読み取り要求の回数。 テーブルスキャンが多く実行されると、この値が大きくなる。この場合、一般的に、テーブルが適切にインデックス化されていないか、クエリがインデックスを有効に利用していないかを意味する。
--->Key_read_requests キャッシュからのキーブロック読み取り要求回数。
--->Key_reads ディスクからのキーブロックの物理的読み取り回数。
--->Opened_tables 値が大きい場合、table_cache 変数が小さすぎると考えられる。
--->Key_reads 値が大きい場合、key_buffer_size 変数が小さすぎると考えられる。キャッシュミスレートは、Key_reads/Key_read_requests で計算される。
--->Created_tmp_disk_tables 値が大きい場合、tmp_table_size 変数を大きくして、ディスクベースではなくメモリベースでテンポラリテーブルを取得できるようにする。
-MySQLのチューニング
--http://tsuttayo.sytes.net/mysql/setting/
---># インデックスブロックを使用する際のバッファの大きさを指定。
---># キーを多様するときはこれを大きくするとスピードUPとなります。
--->key_buffer = 16M
----
バックアップ
-テーブル定義の出力
--mysqldump --default-character-set utf8 -u hogeuser -p -d hogedatabase hoge_table > ./hoge_table_definition_file.txt
-テーブルのバックアップ
--$ mysqldump --default-character-set utf8 -u hogeuser -p hogedatabase hoge_table > ./hoge_table_backup_file.txt
-テーブルのリストア
--$ mysql -O default-character-set utf8 -u hogeuser -p hogedatabase < ./hoge_table_backup_file.txt
-mysqlhotcopy で MySQL データベースをオンラインバックアップする
--http://www.nilab.info/z3/20070702_zlashdot_000659.html
-mysqldumpではblobをバックアップできない
-- --hex-blob オプションを使う or select into dumpfileを使う
-MySQL :: MySQL 5.1 リファレンスマニュアル :: 7.12 mysqldump ― データベースバックアッププログラム
--http://dev.mysql.com/doc/refman/5.1/ja/mysqldump.html
----
-MySQL AB :: MySQL 4.1 リファレンスマニュアル :: 4.6.2 ANALYZE TABLE 構文
--http://dev.mysql.com/doc/refman/4.1/ja/analyze-table.html
--->これは、テーブルに対して myisamchk -a を実行するのと同じです。
---統計情報解析？
-FFTT : MySQL4.0系→MySQL5.0系
--http://tech.feedforce.jp/mysql_40_to_50.html
-一日目午後：MySQLの最適化 - Oliver の日記
--http://slashdot.jp/journal.pl?op=display&uid=4&id=26710
-MySQLノウハウ
--http://txqz.net/blog/2006/12/13/0943
-ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」：ITpro
--http://itpro.nikkeibp.co.jp/article/NEWS/20060330/233820/
---データの書き込みが多いのでレプリケーションせず。
---テーブルの種類でDB分割。
---ユーザ別にDB分割。振り分けは「マネージャ・ベース」と「アルゴリズム・ベース」
---書き込みタイム・スタンプで分割。
---memcachedでキャッシュ。
-naoyaのはてなダイアリー - Inside Hatena Bookmark's Backend の資料
--http://d.hatena.ne.jp/naoya/20060404/1144121846
---MySQLのレプリケーションは簡単。
---slave server は tmpfs でオンメモリーファイルシステム。slave が複数あるのでクラッシュしても安心。master はちゃんとHDDだと思う(たぶん)。
-MySQL Conference & Expo 2007 - April 23, 2007 - April 26, 2007 - Santa Clara, California
--http://conferences.oreillynet.com/pub/w/54/presentations.html
---プレゼン資料がたくさん。
-とあるはてな社員の日記 - MySQL Conference & Expo 2007
--http://d.hatena.ne.jp/stanaka/20070427/1177651323
-ウノウラボ Unoh Labs: MySQL オペミスでデータが破損してしまった場合の復旧方法
--http://labs.unoh.net/2007/08/mysqlbinlog.html
--->1) データベースが更新されない状態にします(メンテナンス画面など)
--->2) オペミスをしてしまった binlog のバッックアップをとり、オペミスのsqlのblog上での位置を調べます
--->mysqlのバイナリログを残す設定にしておくと、mysqlは更新クエリーが発生すると、バイナリログに書き込みます mysqlbinlog という mysqlに付属しているツールを使用すると、バイナリログの中身を閲覧することができます
--->sudo -u mysql mysqlbinlog /var/log/mysqld/blog.000001 --start-datetime 2007-07-20 11:25:00 --end-datetime 2007-07-20 11:30:00
--->3) 一番最近のバックアップ状態に戻します
--->4) バックアップを取ったオペミスしてしまったバイナリログから、バックアップ復元時のスタート位置と オペミス直前までの位置を指定してSQLをすべて流し込みます。
--->sudo -u mysql mysqlbinlog /var/log/mysqld/blog.000001_bak --start-possion 461764451 --end-possion 561758345 | mysql -u ユーザ名 -p DB名
-mtop - MySQL Monitoring Tool
--http://mtop.sourceforge.net/
-mytop - a top clone for MySQL
--http://jeremy.zawodny.com/mysql/mytop/
-Front Page at innotop
--http://innotop.sourceforge.net/
-MySQL システム管理用コマンド。状態を調べたりボトルネックを調べたり
--show processlist
--show status
--show table status
-MySQLメモ
--http://www.nilab.info/resource/bbslog/megabbs/1067840998.html
-MySQL を使った全文検索 (Full-Text Search)
--http://www.nilab.info/z3/20060724_zlashdot_000319.html
-Debian GNU/Linux Sarge に MySQL 4.1 をインストールする
--http://www.nilab.info/z3/20060603_zlashdot_000290.html
-MySQL の root パスワード忘れた！
--http://www.nilab.info/z3/20060706_zlashdot_000310.html
-KLab技術者ブログ:番外編 MySQL最新動向など
--http://tech.blog.klab.org/archives/50322153.html
-mtop - MySQL Monitoring Tool
--http://mtop.sourceforge.net/
---コマンドラインからtopコマンドのようにサクサク使える(^_^)
-mytop - a top clone for MySQL
--http://jeremy.zawodny.com/mysql/mytop/
---コマンドラインからtopコマンドのようにサクサク使える(^_^)
-MySQL のパラメータはバージョン毎にけっこう違うので、注意。