Consider these aspects of MySQL and
tables when adapting existing memcached
applications to use the
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
InnoDBtable, and to create a unique secondary index on the column that contains the memcached key values. This is because
InnoDBperforms 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
InnoDBtable for each type of data. Define additional table identifiers in the
innodb_memcache.containerstable, and use the
@@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.containerstable take effect the next time the
innodb_memcache.containerstable 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_onlycaching policy, calls to
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
InnoDBtable without being saved in the memory cache, due to the