最近は常にInnoDBを利用しているので，MyISAM vs InnoDB にちょっとコメントしてみる． まず「Webアプリならトランザクションはいらないか」について． Webアプリで，トランザクションの重要性が高くないといっても，無いよりはあった方が良いはず． ちょっとしたシステムでも，たとえばユーザのテーブル，プロフィールのテーブル，日記の記事のテーブルなどでわけるわけで，それ...
新しいストレージエンジンではないのですが、HEAPが4.1からMEMORYに名前が変わりました。また、4.1からHASHのほかにBTREEインデックスも使用可能になりました。 Pluggable Storage Engine 具体的なストレージエンジンの実装ではないのですが、5.1からPluggable Storage Engineと呼ばれる機構が導入されました。これはMySQL本体をビルドし直すことなく、稼働中のMySQLに動的にストレージエンジン...
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じ...
1)更新する可能性がある項目は主キーにしない（主キーの更新はコスト高い！） 2)主キーの項目長はなるべく小さく（全部のインデックスページの容量に悪影響！） 3)できる限り主キーでアクセスする（副次インデックスにくらべて倍は速い！） トランザクション系テーブルに主キーとして、AUTO_INCREMENTを使うのは100%ではないが、安全策と言えます。 マスター系のテーブルには自...
開発案件について、MySQLを利用したケースが増えてきている。日本語での情報も充実してきており、実績も増えてきたのが要因だろう。企業内のシステムに導入する場合、必要になるのが運用管理だ。 トップ画面 MySQLの運用管理を行うブラウザツールもあるが、ターミナル上で行うならこちらを使ってみよう。 今回紹介するオープンソース・ソフトウェアはinnotop、MySQLの状態を...
今運用している某システム、MyISAMのある難癖によって非常に辛い目に遭っております。それはもちろんテーブルロック。これはもうMyISAMを選択した時点でどうしても避けては通れない道。そこんところ仕組みをちゃんと理解してないと、MyISAMのほうが速いって言うから選んだのに、なんだよ全然遅いじゃん！っていうか使い物にならないよウワァァァァンみたいなことになりがち...
『 IfyouhavelargeInnodbdatabasesizeMemoryisparamount.16G-32Gisthecostefficientvaluethesedays.FromCPUstandpoint2＊DualCoreCPUsseemstodoverywell,whilewithevenjusttwoQuadCoreCPUsscalabilityissuescanbeobservedonmanyworkloads. 』
稼動中のサービスのDB操作。 これほど嫌なことは無い と思ってしまった。 スタートして1ヶ月ほどの auのとある公式サイトなのですが FOMA版がそろそろスタートするので 統合したシステムにするために少しDBを変更する必要がありました。 カラム追加でalterしたり テーブル追加でcreateしたり データ追加でinsertしたり データ変更でupdateしたり etc… もちろんテスト環境で何度も...
MySQLはWRITE(書き込み)ロックとREAD(読み出し)ロックの2種類をサポートしていますが、テーブル型毎に`ロック'の挙動が異なります。 以降、使用頻度の高いMyISAM型とInnoDB型のロックについて説明します(【表.2-8】参照)。 表.2-8 テーブル型毎のロックの挙動 ========================================================================================================================= テーブル型 | ロックレベル | デッドロ...
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあ...
サーバの起動直後はデータがメモリ上にないためデータベースの応答速度が遅い、というのは良く知られた話かと思います。MySQL の場合、使っているエンジンが MyISAM であれば、各データファイルをあらかじめ cat ... > /dev/null するなりしてバッファキャッシュに載せておけばいいのですが、InnoDB は独自のキャッシュを持っているのでそういうわけにもいかないように思います。 ...
MySQLのモニタするのに便利なmytopなんですが、MySQL 5に対して使うと、クエリの割合表示が全部ゼロになってしまったります。 これは、MySQL 5.0.2でSHOW STATUS文が変更され、GLOBALかSESSIONというオプションを指定できるようになったことに起因します。このオプションを省略した際はSESSIONを指定したときと同じ動作となり、SHOW STATUS文で得られるのは自分自身の接続についての情報のみ...
http://d.hatena.ne.jp/tokuhirom/20061216/1166231736 memcached の開発元でもある Six Apart ですが、Vox/LJ ではセッションを memcached にいれてはいません。理由は簡単で memcached は比較的小さなデータを格納し、アプリケーションサーバ群で共有するのに適した設計になっているからで、memcached のデータがとべばセッションが消えるというのもアプリケーションによっては致命的になりえるから。 memca...
MySQL でトランザクションを可能にするストレージエンジンとして InnoDB があります． InnoDB のデータファイルは，MyISAM テーブルと異なって，デフォルトでは ibdata1 というファイルにデータが蓄積されていくとこになります． MySQL の datadir に自動拡張する 10 MB の ibdata1 ファイルが 1 つと、5 MB の ib_logfile ログファイルが 2 つ作成されます - 7.5.3. InnoDB 起動オプショ...
『 innodbのデータファイルを小さくするツールが気になる。 』
更新があるシステムにはInnoDBを選ぼう。MyISAMを選択するならそれなりの理由が必要。それにInnoDBのパフォーマンスはそんなに悪くないよ。 In Webサイト開発日記, MySQLパフォーマンスチューニング | by kajiwara 基本はＩｎｎｏＤＢです。 MyISAMを選択できるようなケースを考えてみます。 ・完全に検索Onlyの場合（基幹系とかから一定間隔で検索用テーブルを再構築する。それ以外の時間...
フレンド・タイムライン処理の原理と実践 の続きです。 先のエントリでは、プルモデルの速度が当初予測していたよりも遅かった (というより SQL レイヤでのオーバーヘッドが大きそうだった) ので、MySQL Internals メーリングリストで質問したりしながら、C++ で直接 InnoDB にアクセスするようなコードを書いてみました。 タイムライン構築速度 タイムライン/秒 SQL56.7 ストアド...
一方、主キー以外のインデックス（副次インデックス）はリーフページに主キーの値を格納 していて、データにアクセスするためにそれを使用します。 以下の図のようなイメージです。 主キーがクラスターインデックスであることの必然的結果 NO1 副次インデックスでデータにアクセスする場合に、 1)副次インデックスのB-treeより主キーを取得する 2)その主キーからデータ...
ファイルサイズが 1/10 になってアクセス速度も大幅改善か。実データでこれはすごいな *1。 I’ve tried to convert this table using COMPRESSED row format. This time conversion took 1,5 hours and results were really surprising: Only 5Gb data file (from 60Gb) ~5% I/O load according to iostat (from 99%) ~5% CPU load according to top (from 80-100% mostly waiting for I/O) 0.01 sec average lookup time by primary key (from 1-20 sec before the conversion) Real-Life Use Case for ...
Jesse氏の経験によれば、SQL最適化で最も重要なことはSQLやDBの基本をしっかりと理解することであり、60％がこれで解決するという。残り35％はDBやクエリの特殊な性質に対する対処であり、最後の5％で発想の転換などを求められる。Jaslabs氏はここにばかり力を入れており、それはまったくもって時間の無駄だと述べている（Jesse氏は「SQL_SMALL_RESULTなんて、生まれてこの方使った...
