Writing Applications for the InnoDB memcached Plugin •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. 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. •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. Because using  InnoDB  in combination with  memcached  involves writing all data to disk, whether immediately or sometime later, raw performance is expected to be somewhat slower than using memcached  by itself. When using the  InnoDB memcached  plugin, focus tuning goals for  memcached operations on achieving better performance than equivalent SQL operations. Benchmarks suggest that queries and DML operations (inserts, updates, and deletes) that use the memcached  interface are faster than traditional SQL. DML operations typically see a larger improvements. Therefore, consider adapting write-intensive applications to use the  memcached  interface first. Also consider prioritizing adaptation of write-intensive applications that use fast, lightweight mechanisms that lack reliability. The types of queries that are most suited to simple  GET  requests are those with a single clause or a set of AND  conditions in the  WHERE  clause: SQL: SELECT col FROM tbl WHERE key = ’key_value’; memcached: get key_value SQL: SELECT col FROM tbl WHERE col1 = val1 and col2 = val2 and col3 = val3; memcached: # Since you must always know these 3 values to look up the key, 3375 Adapting SQL Queries 15.20.6.3 Tuning InnoDB memcached Plugin Performance