はじめてのMySQL。意外と知らない3つのTips - ぐるなびをちょっと良くするエンジニアブログ
はじめまして。インフラストラクチャサービスグループの吉田と申します。普段はデータベース管理者の業務を担当しています。 今回は、初めてMySQLを触る方々に、私がデータベース管理者（DBA）という仕事をする中で培った意外に知られていないナレッジを紹介したいと思います。 リレーショナルデータベース管理システム（RDBMS）といっても、有名なものだけでOracleやPostgreSQL、MySQLなどいろいろなプロダクトがあります。どれもSQL言語で、トランザクションも制御できる同じようなものだと思ってしまうことが多いのではないでしょうか。 しかし、実際に使ってみたら、当然できるものだと思っていた事ができず、最初から知っていれば良かったのに、と後悔することも。かくいう私もRDBMSにOracleから入り、違いに面食らった一人です。そこで、よく使うけど案外知らないMySQLのTipsを3つ紹介した
デッドロック調査用の情報採取
■初めに デッドロックについては以前ポストしましたが、やはり多くのお客様が悩まれる問題であると認識しています。SQL Server の Books Online でも下記のような情報を公開しており、以前に比べると必要な情報を確認いただける状態にはなっていると考えています。 デッドロックの検出と終了 SQL Server Profiler を使用したデッドロックの分析 しかしながら、実際に我々サポート部門にお問い合わせを頂戴し、デッドロック調査用の情報採取手順を回答差し上げることも多いのは事実です。そこで、このポストではお問い合わせいただいた際に採取情報として回答している内容を、一般化してまとめたものを紹介したいと思います。このポストが、お客様でのデッドロックの調査の一助となれば幸いです。 なお、ここで提示した情報を用いた方法のみが調査手法ではありませんので、あくまで1つの方法論としてお読み
InnoDBでは特に、VARCHARなどの文字列は数値よりも比較にかかる計算コストが高いので、PKにはint型を用いましょう - Web系エンジニアbcoのメモ帳
“InnoDBはクラスタインデックスを用いてデータが格納されている。そのため、PRIMARY KEYを用いた検索はとっても高速であるが、セカンダリインデックスを利用した検索はそれほど速くない。また、セカンダリインデックスのリーフノードにはPRIMARY KEYの値が格納される。そのため、サイズが大きなカラム（VARCHARなど）をPRIMARY KEYにしてしまうと、無駄なディスク領域を消費してしまうので注意が必要だ。VARCHARなどの文字列は数値よりも比較にかかる計算コストが高いので、文字列をPRIMARY KEYにするのは避けるべきである。 また、明示的にPRIMARY KEYを作成しない場合には、内部的に6バイトのROWIDがPRIMARY KEYとして作成されるが、これは無駄な領域であるので極力PRIMARY KEYを明示的につけるようにしよう。” — 漢(オトコ)のコンピュータ
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
Mysqlでinsert、delete、updateが遅い場合の対策 - Qiita
遅い原因 insertする際に、対象テーブルのインデックスブロックを読み込んで、 更新かけるので、インデックスサイズが大きいと、パフォーマンスが落ちる。 なので、テーブルのデータ増加が原因で、I/Oが発生し、徐々に遅くなっていく。 インメモリで処理できなくなると、突如としてパフォーマンスに影響が出やすい テーブルサイズをできるだけ小さく(レコード長を小さく) インデックスサイズを小さくすること(無闇にインデックス貼らない) パーティショニング(DB間のテーブル移動) 不要データ削除 16KB毎(たぶん)のブロック単位でデータを保持しているので、 断片化されたデータを削除しても効果が薄いです。 Auto Incrementの場合は、ID1〜10000等をまとめて削除する等であれば、効果が期待できます。 ただし、ただし次のインサート以降、空いたブロックを活用するので積極的にデータ削除。 インデ
MySQL5.0/5.1でスロークエリログを記録 - よんちゅBlog
MySQLでスロークエリログを記録する方法は、バージョンによって設定方法が異なったり、オプション名が変更されていたりと、意外と分かりづらいことが多いのでここでまとめておこうと思います。 いずれのバージョンでも、コンフィグファイル(Linuxでは my.cnf、Windowsでは my.ini)の mysqld セクションに設定を記述することになります。 MySQL5.0の場合 MySQL5.0の設定方法は簡単で、「log-slow-queries」にログを出力するファイル名を設定するだけです。 絶対パスによる指定も可能ですが、相対パスで指定した場合はデータディレクトリからの相対パスになります。 また、スロークエリとして記録されるクエリのしきい値、つまり何秒以上のクエリをスロークエリとしてログに記録するかはデフォルトで10秒以上となっています。 この値は「long_query_time」によ
MySQL Keyインデックス（主キー、ユニークキー、インデックス、フルテキスト） | doli blog
MySQLでは、主キー（プライマリーインデックス）、ユニークキー、インデックス、フルテキストが設定できます。 主キー テーブルの中のデータを識別する（重複する値のない）１つまたは複数のフィールド（１つのみ設定、Nullは … 続きを読む »
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
ALTER TABLEを上手に使いこなそう。
テーブル定義を変更したい。インデックスが壊れてしまったので再作成したい。そんな場合はALTER TABLEを使う。ALTER TABLEはテーブル定義を変更するお馴染みのコマンドであるが、その挙動は意外と知られていない。（エキスパートとおぼしき方々からも度々質問を受ける。）そんなわけで、今日はALTER TABLEについて解説しようと思う。 まず結論から言うと、なんとMySQLのALTER TABLEはテーブルのデータを全てコピーし直すのである。なんて無駄なことを！？と思うかも知れないが、テーブル定義（スキーマ）の変更を動的に行うには、ストレージエンジンによるサポートが必要であり、動的なスキーマ変更をサポートしているストレージエンジンはまだ少ないのである。（動的スキーマ変更をサポートしているのはMySQL Clusterぐらいだ。しかも追加だけ。）デフォルトで利用出来るMyISAMはInn
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLはインデックスされた文字列型カラムに数値型カラムをインデックスを使って結合できない - Qiita
Apacheチューニング,MySQLチューニングなどWebサイト高速化(tuning) Tips| インターオフィス
テーブルを削除する(DROP TABLE文)