更新があるシステムにはInnoDBを選ぼう。MyISAMを選択するならそれなりの理由が必要。それにInnoDBのパフォーマンスはそんなに悪くないよ。 | 株式会社ビーグッド・テクノロジー／システム�
基本はＩｎｎｏＤＢです。 MyISAMを選択できるようなケースを考えてみます。 ・完全に検索Onlyの場合（基幹系とかから一定間隔で検索用テーブルを再構築する。それ以外の時間は検索のみのようなケース。） ・ログ系のテーブルを出力のみする場合（insertは3～15倍程度MyISAMが高速） 正直、これくらいなのかなと思います。 パフォーマンスについては（5.0.37以上を選択すれば）InnoDBはMyISAMと比べてほとんど同じです。 以下は計測結果です。 InnoDB vs MyISAM パフォーマンス比較 PrimaryKEY、UniqueIndex、非UniqueIndex InnoDB vs MyISAM パフォーマンス比較 取得件数が多い場合 InnoDB vs MyISAM パフォーマンス比較 SELECT ・・・ LIMIT N InnoDB vs MyISAM
http://www.interdb.jp/techinfo/mysql/m-2-10.html
[InterDB] [著者HP] [PREVIOUS][UP][NEXT] ■■■■ [ロック] ■2-10■ ロック ■■■■ MySQLはWRITE(書き込み)ロックとREAD(読み出し)ロックの2種類をサポートしていますが、テーブル型毎に`ロック'の挙動が異なります。 以降、使用頻度の高いMyISAM型とInnoDB型のロックについて説明します(【表.2-8】参照)。 表.2-8 テーブル型毎のロックの挙動 ========================================================================================================================= テーブル型 | ロックレベル | デッドロック状態への対処 | 備考 | ===========+================
MySQL各種Tips
ここでは、MySQLに関する事を書いていきます。 新しく書いたものが上になるように並べてあります。 新しくユーザ（権限）を追加する MySQLではOracleなどとデータベース・スキーマ・ユーザの考え方が違います。 ユーザ情報は、mysqlデータベースという特別なデータベースにより管理されています。 ここには host, user などいくつかの権限に関するテーブルが用意されていて ここにレコードを作成したりすることで、各種権限管理を行います。 MySQL4以降では、このテーブルを直接いじることなくユーザ管理を行うコマンドが用意されました。 それが GRANT / REVOKE 構文です。他のデータベースではおなじみですね。 MySQLではユーザを追加するときに、以下の情報を入力する必要があります。 追加したいユーザ名 接続可能なホスト名 接続可能なデータベースおよびテーブル名 接続すると
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.11.1 内部ロック方法
このセクションでは、内部ロック、つまり複数のセッションによるテーブル内容の競合を管理するために、MySQL サーバー自体の内部で実行されるロックについて説明します。 この種類のロックは、完全にサーバーによって実行され、ほかのプログラムは関与しないため、内部です。 ほかのプログラムによって MySQL ファイルに対して実行されるロックについては、セクション8.11.5「外部ロック」を参照してください。 MySQL は InnoDB テーブルに行レベルロックを使用して、複数のセッションによる同時書き込みアクセスをサポートし、それらを複数ユーザー、高度な並列性、および OLTP アプリケーションに適したものにします。 単一の InnoDB テーブルに対して複数の同時書込み操作を実行する場合に deadlocks を回避するには、データ変更ステートメントがトランザクションの後半にある場合でも、変更
naoyaのはてなダイアリー - MyISAM vs InnoDB
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I
MySQL:auto_incrementが最大値まで達したとき – 仙人の心得
auto_incrementにしたカラムの型がintなら2147483647、bigintなら9223372036854775807がautoincrementの最大になる。 実際に最大値までauto_incrementを進めてみる。 ALTER TABLE table1 AUTO_INCREMENT= 2147483647; auto_incrementが最大値に達するともうそのテーブルには行を追加することはできなくなります。 oracleのシーケンスならCYCLEオプションがあるけどmysqlのauto_incrementにはそのような機能は無いらしい。 ではauto_incrementが最大値に達したとき、どうすればよいのか？ 単純に ALTER TABLE table1 AUTO_INCREMENT= 1; としても、table1に1より大きいキーが存在する限りauto_incre
[ThinkIT] 第2回：MyISAMとInnoDB (1/3)
今回は、MySQLのストレージエンジンの中でも特に有名な「MyISAM」と「InnoDB」の2つを取り上げます。MyISAMはMySQLのデフォルトストレージエンジンで、ストレージエンジンを指定せずにテーブルを作成するとMyISAMが選択されます。もう一方のInnoDBエンジンは、MySQLに豊富なトランザクション機能を提供するストレージエンジンとして有名です。 まずはそれぞれのテーブルファイルの構造について解説し、最後にInnoDBのトランザクションについて解説します。 各ストレージエンジンのファイル構造を説明する前に、前知識としてMySQLのディレクトリ構造について説明します。 MySQLのデータベースディレクトリには、バイナリログと呼ぶデータベースの更新情報を格納するファイルと、2つのサブディレクトリが存在します（図1）。 「mysql」ディレクトリには権限テーブルと呼ばれるMySQ
MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.2.7 LOAD DATA ステートメント
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
Monty が MySQL ユーザに支援要請 - sakaikの日々雑感～(T)編
オラクルのサン買収に関し、MySQLのオリジナル開発者の Monty こと Michael Widenius 氏が、MySQLユーザに向け、支援を要請するメッセージを出しました。 http://monty-says.blogspot.com/2009/12/help-saving-mysql.html （１）これまでに起こったこと(要約) （２）オラクルが約束「しなかったもの」は何か （３）これまでのオラクルの、オープンソースへのふるまい （４）この情報を広めて欲しい （５）EUへの email のサンプル が書かれています。 オラクルによるサン買収が発表された後、これまでにも何度となくメッセージを発信してきた Monty ですが、今回のメッセージはこれまでになく強いメッセージであるという印象を受けました。 以下簡単ですがまとめてみます。あくまで参考程度にしていただくことにして、正確なこと
MyISAMでテーブルが巨大すぎるとDELETEできなくなる件（MERGEテーブル解説） - 昼メシ物語
MySQL4.1でMyISAMを使っていて、ふと気づいたら1つのテーブルに4千万件のレコードを挿入してしまいました。 MyISAMで4千万行のテーブルを作るとどうなるかというと、 INSERT -> やや重いけどいける UPDATE -> やや重いけどいける TRUNCATE/DROP -> 一瞬 DELETE -> 破滅 という感じになることが分かりました。 このテーブルには、挿入日を示すカラムがあって、挿入から時間の経った古いレコードを削除したかったんです。 DELETE FROM large_table WHERE created_at > :expire_date この large_table が4千万行あるのですが、このDELETE文を実行したら7日間くらい返ってきませんでしたし、その間ずっと disk busy になったりしてサーバの調子が悪くなりました。 created_at
Heartbeatの特徴とユニークな機能
はじめに 今回から数回にわたって、オープンソースのHA（高可用性）クラスタ構築ソフトウェア「Heartbeat」を題材にして、「クラスタリングとは何か？」というところから、Heartbeat自体の解説、Heartbeatを用いてのHAクラスタの構築、モニタリングなどについて解説していきたいと思います。皆さんお付き合いのほど、よろしくお願いいたします。 クラスタリングって何だろう？ まず、「クラスタリングとは何か」というところから始めてみましょう。この質問に簡単に答えてしまうと「あるミッションに対し、複数のコンピュータ（群＝クラスタ）をもって対処する構成」だといえます。ですが、状況に応じてさまざまなミッションのタイプがありますから、それに対するクラスタリング（構成）も自然と変わってきます。 なお、Linuxでのクラスタリングの歴史は意外と古くまでさかのぼることができます。約十年前の雑誌ですで
最近頻繁に使用するMySQL関数など
こんばんは。笹亀です。 先週あたりからめっぽう寒くなってきました。 どうやら大寒波のおかげで心配されていた今年のスキー場の雪の心配はなさそうです。 さて、今回は頻繁に使うことを自分へのメモの意味でも記事にまとめさせていただきました。 みなさんの参考になれば幸いです。 ーーーMySQLシリーズーーー ■mysqldumpのオプション「--skip-extended-insert」 データベースのデータ(INSERT)を1行のINSERT文にするのではなく、複数行のINSERT文として出力する 自分が使った用途：ダンプを取ったデータを特定のキーワードでgrepするため 用途は限られますが、便利です。このオプションを見つけるのに少し苦労しました＾＾； ■REPLACE関数 MySQLの文字列置換する関数 自分が使った用途：データベース内の文字を一括で置換するため UPDATE hoge_t SE
MySQLのクライアントエンコーディング
森川です。 前回はマルチバイト関連でしたが、今回もマルチバイトです。前回ソースを解析するなどと言ってしまいましたが、中々難しくまだ途中です。決してあきらめたわけではないので、もう少しすればここに書けるようになると思います。 さて、今回はMySQLの文字コードについてです。4.1から文字コードの設定が色々と増えたので、設定をきちんとしていなくて問題が起きることも多かったのではないでしょうか。まずは簡単におさらいです。 CentOS4.4のパッケージを使用している場合はデフォルトの文字コードは以下のようになります。 mysql> show variables like 'character%'; +--------------------------+----------------------------+ | Variable_name | Value
MySQLに纏わる10の都市伝説
誰の口から飛び出したのかは定かではないが、巷ではMySQLにまつわる様々な「都市伝説」がまことしやかに囁かれているようだ。恐らくMySQLに対する理解が低い人や、MySQLがあまり好きではない面々によってFUDっぽく言われているのだと思うが、世の中にはそのような「都市伝説」を真に受けてしまう人が居るのもまた事実であである。MySQLにおける昨今の開発スピードには目覚ましいものがあり、MySQLは性能・安定性・使い易さ共に進化し続けている。（特に先日リリースされたMySQL 5.5は性能・安定性・使い易さを両立している優れたバージョンだ！！）しかし「都市伝説」で語られることは総じて「MySQLはダメな子ちゃん」であるという烙印を押すものばかりであり、MySQLerとしてはそのような言われ無き汚名を全身全霊をもって晴らさなければならない使命を背負っている。そこで、今日はMySQLについて語られ
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
ウノウラボ Unoh Labs: MySQL オペミスでデータが破損してしまった場合の復旧方法
こんにちは satoです。 オペミスで update に where句を付け忘れたり、プログラムのバグでデータが破損してしまったりした場合でも、バイナリログには更新SQLがすべて書き込まれるので、バックアップデータからオペミスが起こるまでの全てのSQLを流し込めれば、元の状態に戻すことは可能です。 •バイナリログを取っている •オンラインバックアップをとっている(mysqldumpやMySQLを止めた状態でのcpによるバックアップとバイナリログ) •バックアップ時点でのバイナリログの書き込み位置を保存している 以上のような状態でデータが壊れた時の復旧手順をまとめてみました。シナリオとして •ある1カラム email をupdateしようとしたら、間違ってwhere 句を付け忘れ 全レコードをupdateしてしまった •気がついたのが半日後 というオペミスが発生したとします 1) データベー
MySQL :: MySQL 8.0 リファレンスマニュアル :: 16.8.2 FEDERATED テーブルの作成方法
リモートサーバーにテーブルを作成します。 または、SHOW CREATE TABLE ステートメントを使用するなどして、既存テーブルのテーブル定義のメモを取ります。 同一のテーブル定義でローカルサーバーにデーブルを作成しますが、ローカルテーブルをリモートテーブルにリンクする接続情報を追加してください。 たとえば、リモートサーバーに次のテーブルを作成できます。 CREATE TABLE test_table ( id INT(20) NOT NULL AUTO_INCREMENT, name VARCHAR(32) NOT NULL DEFAULT '', other INT(20) NOT NULL DEFAULT '0', PRIMARY KEY (id), INDEX name (name), INDEX other_key (other) ) ENGINE=MyISAM DEFAUL
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.7.2.4 読取りのロック
データのクエリーを実行してから、同じトランザクション内で関連データを挿入または更新する場合は、通常の SELECT ステートメントで十分な保護が提供されません。 ほかのトランザクションは、クエリーが実行されたばかりの同じ行を更新または削除できます。 InnoDB では、追加の安全性が提供される 2 つのタイプのロック読み取りがサポートされています。 SELECT ... FOR SHARE 読み取られる行に共有モードロックを設定します。 ほかのセッションもその行を読み取ることができますが、トランザクションがコミットするまで変更することはできません。 これらの行のいずれかがコミットされていない別のトランザクションによって変更された場合、クエリーはそのトランザクションが終了するまで待機してから、最新の値を使用します。 SELECT ... FOR SHARE は SELECT ... LOCK
[ThinkIT] 第5回：Federatedエンジン (1/3)
今回は「Federated」ストレージエンジンを取り上げます。Federatedエンジンは、MySQL 5.0から提供された非常に新しいエンジンです。今回は、Federatedエンジンの特長や動作について解説します。 英単語の「Federated」を直訳すると「連合した」といった意味になります。この意味の通りFederatedエンジンは、このエンジンを動作させるMySQLサーバ単独で動作するものではなく、他のMySQLサーバと連携して動作するエンジンです。 Federatedエンジンは、テーブルデータをFederatedエンジン自身が動作するMySQLサーバ（Federatedではこれをローカルサーバと呼ぶ）のデータベース内に格納せず、ネットワークに接続された他のMySQLサーバ（リモートサーバ）上のデータベース内に格納します。よって、Federatedエンジンが動作するローカルサーバ上に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.res-system.com/weblog/item/620