Movatterモバイル変換

If there are key values longer than a few bytes, it may be more efficient to use a numeric auto-increment column as theprimary key of theInnoDB table, and to create a uniquesecondary index on the column that contains thememcached key values. This is becauseInnoDB 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 usingmemcached, consider setting up a separateInnoDB table for each type of data. Define additional table identifiers in theinnodb_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 enablecompression 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 additionalsecondary indexes on tables that are frequently used to generate reports using SQL.

Preferably, configure a stable set of table definitions for use with thedaemon_memcached plugin, and leave the tables in place permanently. Changes to theinnodb_memcache.containers table take effect the next time theinnodb_memcache.containers table is queried. Entries in the containers table are processed at startup, and are consulted whenever an unrecognized table identifier (as defined bycontainers.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 defaultinnodb_only caching policy, calls toadd(),set(),incr(), and so on can succeed but still trigger debugging messages such aswhile expecting 'STORED', got unexpected response 'NOT_STORED. Debug messages occur because new and updated values are sent directly to theInnoDB table without being saved in the memory cache, due to theinnodb_only caching policy.