MySQLの小さなルックアップテーブルに最適なエンジン
次の質問があります。数十の小さなルックアップテーブルを使用してWebアプリケーションを設計しています。これらのテーブルには通常、3つの列（ID、名前、説明）と2つの行（ほとんどが50未満、最大は約450）が含まれています。
これらのルックアップテーブルはめったに変更されないと予想され（数年に1回変更される標準からのもの）、次の目的にのみ使用されます。
- hTML選択にオプションを入力
- レポートの他のレコードに結合される
これらのテーブルには99％の頻度でSELECTステートメントのみが存在しますが、かなり多く存在します。
どのデータベースエンジンを使用するのが最も効率的でしょうか。
ここに私の考慮事項があります：
メモリー
- プロ：非常に速い
- con：サーバーがクラッシュした場合、すべてのデータが失われ、再作成する必要があります
- con：外部キーをサポートしていません
圧縮されたMyISAM
- プロ：速い
- con：外部キーをサポートしていません
InnoDB
- pro：外部キーのサポート
私が聞きたいのは、InnoDBとは異なるものを使用することで大きな利点があるかどうかです
ありがとう、Zbynek
私は2011年8月に同様の質問に回答しました： どのDBMSが超高速読み取りと単純なデータ構造に適していますか？
MySQLとどのストレージエンジンについて質問しているため。正直に言うと、MyISAMがSELECTに関してInnoDBよりも優れたパフォーマンスを発揮できることがまれにあるため、言うのは困難です。
これは、この論争に関する私の過去の投稿の一部です
Sep 20, 2011： MyISAMとInnoDBのベストMay 03, 2012： InnoDBまたはMyISAMのどちらが高速ですか？Jul 05, 2012： 多くのインデックスを持つInnoDBとMyISAMSep 26, 2012： これらのプロジェクト要件のためにInnoDBよりMyISAMを選択し、長期的なオプション
あなたは今尋ねるかもしれません：なぜ私はInnoDBよりMyISAMを好むのですか？
この図を見てください（Percona CTO、Vadim Tkachenkoが作成）
MyISAMはインデックスをキャッシュし、テーブルには2つのインデックス（IDのプライマリキーと名前のインデックス）があります。一方、InnoDBには、特にInnoDBバッファープールが定期的に16Kページをロードして閉じる必要がある場合に対応するには、可動部分が多すぎます。
公平を期すには、実験を行う必要があります。
- 私の投稿に行く InnoDBとMyISAMの主な違いは何ですか？ 。注意深く読んでください。
- MyISAMを使用してサーバーをセットアップし、
ROW_FORMAT=Fixedを使用してすべてのテーブルを設定します（私の投稿を参照 固定サイズのフィールドでCHARとVARCHARを使用した場合のパフォーマンスへの影響は何ですか？ ）。 key_buffer_size 。 - InnoDBと大きな innodb_buffer_pool_size を使用して別のサーバーをセットアップします。
- 両方のサーバーにデータを追加し、狂ったようにそれらをクエリします。
これにより、データセットに対するストレージエンジンの選択に最適な評価が得られます。
試してみる ！！！
- 「圧縮MyISAM」-それは何ですか？多分「アーカイブ」？
- 圧縮は必要ありません。テーブルが小さすぎるため、すぐに完全にキャッシュされます。
FOREIGN KEYS- なぜ？コードをデバッグしましたね。チェックするぶら下がり物はありません。MEMORYは不合理ではありませんifサーバーを起動するたびに実行される「リロード」コードを記述し、テーブルの更新はMEMORYテーブルと永続的バックアップの両方に書き込まれます。MyISAMROW_FORMAT=FIXED-それは古い妻の話です。DYNAMICおよびVARCHARsを使用します。- InnoDBの「クラスター化」
PRIMARY KEYは、目的に応じて、検索をMyISAMよりも少し速くします。 - 知っているルックアップテーブルが顕著なスローダウンを引き起こしていることを知っていますか？私はそれらがそうであることを真剣に疑っています。
- 実行not「連続」値には、
FLOATsやDATEsなどのルックアップテーブルを使用します。
FKなしでInnoDBに投票します。