考虑对那些经常访问且只读或很少更新的非关键数据使用MEMORY表。在实际工作负载下，将你的应用程序与等效的InnoDB或MyISAM表进行基准测试，以确认任何额外的性能提升是否值得承担数据丢失的风险，或在应用程序启动时从基于磁盘的表复制数据的开销。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.

为了在 MEMORY 表上获得最佳性能，请检查每个表上的查询类型，并为每个相关索引指定要使用的类型，可以是 B 树索引或哈希索引。在 CREATE INDEX 语句中，使用子句 USING BTREE 或 USING HASH。B 树索引对于通过 > 或 BETWEEN 等操作符进行大于或小于比较的查询非常快速。哈希索引仅对通过 = 操作符查找单个值，或通过 IN 操作符查找有限集合的查询快速。关于为什么 USING BTREE 通常比默认的 USING HASH 更好的选择，请参见 第 10.2.1.23 节，“避免全表扫描”。有关不同类型 MEMORY 索引的实现细节，请参见 第 10.3.9 节，“B 树和哈希索引的比较”。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 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 Section 10.2.1.23, “Avoiding Full Table Scans”. For implementation details of the different types of MEMORY indexes, see Section 10.3.9, “Comparison of B-Tree and Hash Indexes”.