If there are key values longer than a few bytes, it may be more efficient to use a numeric auto-increment column as the primary key of the InnoDB table, and to create a unique secondary index on the column that contains the memcached key values. This is because InnoDB performs best for large-scale insertions if primary key values are added in sorted order (as they are with auto-increment values). Primary key values are included in secondary indexes, which takes up unnecessary space if the primary key is a long string value.

If you store several different classes of information using memcached, consider setting up a separate InnoDB table for each type of data. Define additional table identifiers in the innodb_memcache.containers table, and use the @@table_id.key notation to store and retrieve items from different tables. Physically dividing different types of information allows you tune the characteristics of each table for optimum space utilization, performance, and reliability. For example, you might enable compression for a table that holds blog posts, but not for a table that holds thumbnail images. You might back up one table more frequently than another because it holds critical data. You might create additional secondary indexes on tables that are frequently used to generate reports using SQL.

Preferably, configure a stable set of table definitions for use with the daemon_memcached plugin, and leave the tables in place permanently. Changes to the innodb_memcache.containers table take effect the next time the innodb_memcache.containers table is queried. Entries in the containers table are processed at startup, and are consulted whenever an unrecognized table identifier (as defined by containers.name) is requested using @@ notation. Thus, new entries are visible as soon as you use the associated table identifier, but changes to existing entries require a server restart before they take effect.

When you use the default innodb_only caching policy, calls to add(), set(), incr(), and so on can succeed but still trigger debugging messages such as while expecting 'STORED', got unexpected response 'NOT_STORED. Debug messages occur because new and updated values are sent directly to the InnoDB table without being saved in the memory cache, due to the innodb_only caching policy.