MySQL 5.7 Reference Manual Including MySQL NDB Cluster 7.5 and NDB Cluster 7.6
Consider these aspects of MySQL and InnoDB
tables when adapting existing memcached
applications to use the daemon_memcached
plugin:
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
@@
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.
table_id
.key
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.