Consider using 'MEMORY' tables for noncritical data that is accessed often, and is read-only or rarely updated. Benchmark your application against equivalent 'InnoDB' or 'MyISAM' tables under a realistic workload, to confirm that any additional performance is worth the risk of losing data, or the overhead of copying data from a disk-based table at application start.
For best performance with 'MEMORY' tables, examine the kinds of queries against each table, and specify the type to use for each associated index, either a B-tree index or a hash index. On the note 'CREATE INDEX': create-index. statement, use the clause 'USING BTREE' or 'USING HASH'. B-tree indexes are fast for queries that do greater-than or less-than comparisons through operators such as '>' or 'BETWEEN'. Hash indexes are only fast for queries that look up single values through the '=' operator, or a restricted set of values through the 'IN' operator. For why 'USING BTREE' is often a better choice than the default 'USING HASH', see note table-scan-avoidance::. For implementation details of the different types of 'MEMORY' indexes, see *note index-btree-hash::.
File: manual.info.tmp, Node: execution-plan-information, Next: controlling-optimizer, Prev: optimizing-memory-tables, Up: optimization