数バイトを超えるキー値がある場合は、InnoDB テーブルの primary key として数値自動増分カラムを使用し、memcached キー値を含むカラムに一意の secondary index を作成する方が効率的です。 これは、主キー値が (自動増分値と同様に) ソートされた順序で追加されている場合、InnoDB が大規模な挿入に最適なパフォーマンスを発揮するためです。 主キー値はセカンダリインデックスに含まれ、主キーが長い文字列値の場合は不要な領域を占有します。

memcached を使用して複数の異なるクラスの情報を格納する場合は、データのタイプごとに個別の InnoDB テーブルを設定することを検討してください。 innodb_memcache.containers テーブルに追加のテーブル識別子を定義し、@@table_id.key テーブル記を使用して異なるテーブルのアイテムを格納および取得します。 様々なタイプの情報を物理的に分割することで、最適な領域使用率、パフォーマンスおよび信頼性のために各テーブルの特性をチューニングできます。 たとえば、ブログ投稿を保持するテーブルに対しては compression を有効にできますが、サムネイルイメージを保持するテーブルに対しては有効にできません。 非常に重要なデータが保持されているテーブルは、別のテーブルよりも頻繁にバックアップする場合もあります。 SQL を使用してレポートを生成するために頻繁に使用されるテーブルに追加の secondary indexes を作成できます。

できれば、daemon_memcached プラグインで使用する安定したテーブル定義のセットを構成し、テーブルを永続的に配置したままにします。 innodb_memcache.containers テーブルへの変更は、innodb_memcache.containers テーブルへの次回のクエリー時に有効になります。 コンテナテーブルのエントリは起動時に処理され、認識されないテーブル識別子 (containers.name で定義) が@@テーブル記を使用してリクエストされるたびに参照されます。 したがって、関連するテーブル識別子を使用するとすぐに新しいエントリが表示されますが、既存のエントリへの変更を有効にするには、サーバーの再起動が必要です。

デフォルトの innodb_only キャッシュポリシーを使用すると、add(), set(), incr() のコールは成功しますが、while expecting 'STORED', got unexpected response 'NOT_STORED などのデバッグメッセージはトリガーされます。 デバッグメッセージが発生するのは、新しい値と更新された値が、innodb_only キャッシュポリシーのためにメモリーキャッシュに保存されずに InnoDB テーブルに直接送信されるためです。