通过本文主要向大家介绍了mysql memory 引擎,mysql memory,mysql out of memory,mysql shared memory,memory引擎等相关知识,希望本文的分享对您有所帮助
后来看到博客园在用NorthScale Memcached Server（官方站点：http://www.couchbase.com/products-and-services/memcached），貌似共享收费，又犹豫了。其实项目里的需求很简单，也想自己用.Net Cache来实现，但稳定性难以评估，开发维护成本又似乎太大，没办法，My SQL Memory Storage成了唯一选择，因为几乎不怎么需要编写代码。
先看官方手册，然后写了个简单的性能测试。因为官方最新的文档都是英文版的，所以译了5.5版本 MySQL Memory Storage章节。
官方文档（译自5.5版本的The Memory Storage Engine）
Memory存储引擎将表的数据存放在内存中。Memory替代以前的Heap成为首选项，但同时向下兼容，Heap仍被支持。
Memory存储引擎特性：
Memory 与 MySQL Cluster的比较
希望部署内存引擎的开发者们会考虑MySQL Cluster是否是更好的选择，参考如下Memory引擎的使用场景及特点：
能像会话（Session）或缓存（Caching）一样方便操作和管理。
充分发挥内存引擎的特点：高速度，低延迟。
只读或读为主的访问模式（不适合频繁写）。
但是内存表的性能受制于单线程的执行效率和写操作时的表锁开销，这就限制了内存表高负载时的扩展性，特别是混合写操作的并发处理。此外，内存表中的数据在服务器重启后会丢失。
MySQL Cluster（集群）支持与Memory引擎同样的功能并且提供更高的性能，同时拥有Memory不支持的更多其它功能：
行锁机制更好的支持多线程多用户并发。
更好的支持读写混合语句以及扩展。
可选择磁盘存储介质永久保存数据。
Shared-nothing和分布式架构保证无单点故障，99.999% 可用性。
数据自动分布在各个节点，应用开发者无需考虑分区或分片解决方案。
支持MEMORY中不支持的变长数据类型（包括BLOB 和 TEXT）。
关于MySQL集群与Memory引擎更多细节方面的比较，可以查看Scaling Web Services with MySQL Cluster: An Alternative to the MySQL Memory Storage Engine，该白皮书包括了这两种技术的性能研究，并一步步指导你如何将Memory用户迁移到MySQL集群。
每个Memory表和一个磁盘文件关联起来。文件名由表的名字开始，并且由一个.frm的扩展名来指明它存储的表定义。要明确指出你想要一个Memory表，可使用ENGINE选项来指定：
CREATE TABLE t (i INT) ENGINE = MEMORY;
如它们名字所指明的，Memory表被存储在内存中，且默认使用哈希索引。这使得它们非常快，并且对创建临时表非常有用。可是，当服务器关闭之时，所有存储在Memory表里的数据被丢失。因为表的定义被存在磁盘上的.frm文件中，所以表自身继续存在，在服务器重启动时它们是空的。
这个例子显示你如何可以创建，使用并删除一个Memory表：
/* Quer
先看官方手册，然后写了个简单的性能测试。因为官方最新的文档都是英文版的，所以译了5.5版本 MySQL Memory Storage章节。
官方文档（译自5.5版本的The Memory Storage Engine）
Memory存储引擎将表的数据存放在内存中。Memory替代以前的Heap成为首选项，但同时向下兼容，Heap仍被支持。
Memory存储引擎特性：
| Storage limits | RAM | Transactions | No | Locking granularity | Table |
| MVCC | No | Geospatial data type support | No | Geospatial indexing support | No |
| B-tree indexes | Yes | Hash indexes | Yes | Full-text search indexes | No |
| Clustered indexes | No | Data caches | N/A | Index caches | N/A |
| Compressed data | No | Encrypted data | Yes | Cluster database support | No |
| Replication support | Yes | Foreign key support | No | Backup / point-in-time recoveryc | Yes |
| Query cache support | Yes | Update statistics for data dictionary | Yes |
希望部署内存引擎的开发者们会考虑MySQL Cluster是否是更好的选择，参考如下Memory引擎的使用场景及特点：
能像会话（Session）或缓存（Caching）一样方便操作和管理。
充分发挥内存引擎的特点：高速度，低延迟。
只读或读为主的访问模式（不适合频繁写）。
但是内存表的性能受制于单线程的执行效率和写操作时的表锁开销，这就限制了内存表高负载时的扩展性，特别是混合写操作的并发处理。此外，内存表中的数据在服务器重启后会丢失。
MySQL Cluster（集群）支持与Memory引擎同样的功能并且提供更高的性能，同时拥有Memory不支持的更多其它功能：
行锁机制更好的支持多线程多用户并发。
更好的支持读写混合语句以及扩展。
可选择磁盘存储介质永久保存数据。
Shared-nothing和分布式架构保证无单点故障，99.999% 可用性。
数据自动分布在各个节点，应用开发者无需考虑分区或分片解决方案。
支持MEMORY中不支持的变长数据类型（包括BLOB 和 TEXT）。
关于MySQL集群与Memory引擎更多细节方面的比较，可以查看Scaling Web Services with MySQL Cluster: An Alternative to the MySQL Memory Storage Engine，该白皮书包括了这两种技术的性能研究，并一步步指导你如何将Memory用户迁移到MySQL集群。
每个Memory表和一个磁盘文件关联起来。文件名由表的名字开始，并且由一个.frm的扩展名来指明它存储的表定义。要明确指出你想要一个Memory表，可使用ENGINE选项来指定：
CREATE TABLE t (i INT) ENGINE = MEMORY;
如它们名字所指明的，Memory表被存储在内存中，且默认使用哈希索引。这使得它们非常快，并且对创建临时表非常有用。可是，当服务器关闭之时，所有存储在Memory表里的数据被丢失。因为表的定义被存在磁盘上的.frm文件中，所以表自身继续存在，在服务器重启动时它们是空的。
这个例子显示你如何可以创建，使用并删除一个Memory表：
/* Quer