元ネタ: http://labs.unoh.net/2007/07/mysqltips.html あまり具体的じゃないので、僕の考えとか。 正しいかどうかは各自の状況だとか実際試すべきなんだけど、参考になれば。 MyISAM、InnoDBなどテーブルタイプ 僕は断然InnoDB派です。 ただ仰るとおり、ログるだけのテーブルとかならMyISAMでもいいとは思うけど。 トランザクションやロック処理などが必要ない場合など、MyISAM形式にも良いところはあるので検討してみる価値はあるかもしれません。 これだけの指摘だとちょっと微妙な気がするです。 MyISAMの使いどころってのは、 ピンで他とリレーションが無い単純追記系のテーブル リレーションがあり、同一トランザクション内での更新系クエリが存在する場合は、トランザクションが期待通りに動かないので、基本的にはInnoDBと混在させるべきではない
http://www.mysql-ucj2007.jp/details/j25.html 木下 靖文 氏 NTTコムウェア株式会社 プロジェクト管理統括部技術SE部門 DB技術グループ （「InnoDB」は「いんのでーびー」と言うらしい...今まで「いのでーびー」と言ってました） InnoDBをなぜ使うか トランザクション コミット、ロールバック、セーブポイント 外部キー 行レベルロック オンラインバックアップ クラッシュリカバリ クラッシュリカバリ MyISAMはデータ量の増大とともに時間がかかる InnoDBはデータ量の増大との相関がない InnoDBチューニングの王道的アプローチ クエリを改善して全体的に処理効率を上げる データサイズをできるだけ小さく メモリをできるだけ多く積む コミット性能（同期書き込み） innodb_flush_log_at_trx_commit=1,0,2
集約演算を行うケースでは、行のサイズを小さく保つことはとても重要。アクセス頻度が低いコラムは別テーブルに追い出すとかしたほうがいいくらい。 一方、集約演算を行わないケース (単一行の insert, update 等を含む) の場合は、(クライアントとの通信のための) システムコールがオーバーヘッドになるので、小さなテーブルにたくさんアクセスをするよりも、長い行を持つテーブルに１回アクセスするほうが良い。 たとえば手元の環境での insert on duplicate key update の速度は、 行のサイズ 必要時間 0KB 1 3KB 4 6KB 7 9KB 13 12KB 13 とかそんな感じ (環境やクエリによる変わるので自分で測定してね。9KB の速度低下はページサイズの1/2を超えたからかな)。つまり、行のサイズが1KB程度だと、通信のオーバーヘッドが大きいからあまり問題に
こんにちは、mixi開発部にてアプリケーション開発をしていますyouheiです。 今回は、MySQL-5.0.45のInnoDBで連番を管理するテーブルのパフォーマンス測定をしていたのですが、その際に少し変わったデッドロック問題に遭遇しましたので、そのあたりをネタとして書いてみたいと思います。 まずは、今回使用したデータベースのスキーマは下記のようなものです。 CREATE TABLE num ( id bigint unsigned NOT NULL default '0' ) Engine=InnoDB; AUTO_INCREMENTは使用していません。 そこに1レコードだけ登録します。 INSERT INTO num (id) values (1); そして実際連番を取得する際には、 UPDATE num SET id = LAST_INSERT_ID(id+1); といったクエリを
InnoDB vs MyISAM vs Falcon benchmarks - part 1 を読んだ。興味深かった。 だけだとナンなので、思ったことをメモってみる。 がんばれFalcon まだ生まれたてなのでベンチマークの結果は参考程度に。 InnoDB vs MyISAM The second goal of benchmark was a popular myth that MyISAM is faster than InnoDB in reads, as InnoDB is transactional, supports Foreign Key and has an operational overhead. As you will see it is not always true. の通り、どちかというと(Falconより)InnoDBとMyISAMの性能比較の方が興味深い点が
コンテンツへスキップ ナビゲーションに移動 Engineers' Blog Awards 2025 を開催しました！2025/07/02yutaka.sashimaこんにちは、佐島です。 昨年に引き続き、テックブログ執筆者を称える社内イベント「Engineers' Blog Awards 2025」を開催しましたので、ご紹介します。 （開催背景などは昨年のブログをご覧ください。） […] InfoGREE Engineers’ Bash 2025 を6月17日(火)に開催しました！2025/06/25yutaka.sashima 勉強会 こんにちは、佐島です。 GREE Engineers’ Bash 2025 という社内限定イベントが昨年に引き続き開催されましたので紹介させて頂きます。 （GREE Engineers’ Bash については2018年度 […] Infomysqld が起
ストレージエンジンとしてInnoDBを使うときはMyISAMのときと触るべきポイントが違うので注意。 http://www.mysqlperformanceblog.com/files/presentations/OSCON2004-MySQL-Innodb-Performance-Optimization.pdf を読みながら取ったメモ。状況としてはRedHat AS3.0で動かしたときのDBT2*1のパフォーマンスを改善していくというもの。MySQL デフォルト状態での分析 Handler_read_nextが多い、つまりrange scanかindex scanが多すぎる slow query logで何が悪いかを引っかける 例では2秒以上処理にかかったqeuryを記録するようにしている 結果を分析 update文が遅かったけど、update文そのままではexplainできないので、
拡張され続ける InnoDB のデータファイルのサイズを小さくする方法 2006-07-07-2: [MySQL] MySQL でトランザクションを可能にするストレージエンジンとして InnoDB があります． InnoDB のデータファイルは，MyISAM テーブルと異なって，デフォルトでは ibdata1 というファイルにデータが蓄積されていくとこになります． MySQL の datadir に自動拡張する 10 MB の ibdata1 ファイルが 1 つと、5 MB の ib_logfile ログファイルが 2 つ作成されます - 7.5.3. InnoDB 起動オプション http://dev.mysql.com/doc/refman/4.1/ja/innodb-start.html この ibdata1 は，大量のデータを追加していくと，自動的にサイズを拡張していきます． ただ
ご指定のページが見つかりませんでした URLの変更、もしくはページが削除された可能性があります。 お手数ですが、以下のリンクから目的のページをお探しください。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
