开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2610人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6群均已爆满，新人进7群破300，8群，准备9群)
最近好久不写MySQL了，并不是不想写，主要有两个原因
1 我们的确用MySQL越来越少了，都换PolarDB了
2 我们用PG 比较多，按照某大佬的说法，我们单位的PG算的上国内的 TOP N 了。
另外最近一直在学习OceanBase,时代在变，虽然我是个老登，但我还不服老，我还要往前走，那天走不动了，再说。
这篇是群友的要求，说必须要给他写一篇关于MySQL的内存表，这就满足群友要求，写一篇。（后面告诉我是SQL SERVER 的内存表，那这篇写了就写了）
其实说来，虽然MySQL很多人拿它当一个数据库容器来看，但MySQL是符合之前互联网的一些特性的，比如就这个内存表。首先互联网的要求是快，内存表本身是存储在内存中的，他的访问速度是高于我们日常的INNODB引擎下的表的，同时我们也不愿意在频繁的使用REDIS 这样的数据库产品，在这样的情况下，减少我们的数据库架构的复杂性，所以有了MySQL内存表的用武之地。
那么对于他的特性我们需要进行一个梳理
数据存储位置： 数据存储在内存中，而非磁盘。
访问速度： 由于内存的访问速度远高于磁盘，因此内存表的查询速度非常快。
数据生命周期： 当MySQL服务重启或连接断开时，内存表中的数据会丢失。
不支持事务： 内存表不支持事务，因此不能保证数据的ACID特性。
不支持BLOB和TEXT类型： 由于内存限制，内存表不支持BLOB和TEXT等大文本类型。
支持索引： 内存表支持索引，可以进一步提高查询效率。
CREATE TABLE my_memory_table (
id INT PRIMARY KEY,
name VARCHAR(50)
) ENGINE=MEMORY;
从原理和支持的范围上，从某个角度这样的表好像比REDIS 更香，因为我可以用SQL来操作内存的数据，不用去学REDIS 的用法，速度还快，可以建立索引。
内存表的应用场景 缓存： 将频繁访问的小型数据集缓存在内存表中，可以显著提高查询性能。 临时表： 用作临时计算结果的存储，可以避免频繁的磁盘I/O操作。 会话级数据： 存储会话级别的临时数据，例如购物车信息。
这里内存表的特点是要理解为什么会有这个需求，且为什么开发要用这个表，这会提高我们DBA的一个逼格，高级的DBA都会侵入到开发的环节，甚至会到架构的环节，这就是在提高自己，把自己往架构师的队伍里面迁移。
今天详细说说内存表中的一个需求的来源，会话缓存。
什么是会话级的数据，这里我做一个解释
1 客户的访问会产生一些临时的数据，这些数据标志着用户的一些操作的历史，或者一些用户特殊的爱好，或者一些用户的操作痕迹。
为什么有这个需求，很简单，你不能保证客户和你的应用连接是一直稳定的，如果客户不稳定他掉线了，或者操作错误了怎么办，他要回去。怎么回去，把这些数据都写到你的数据库里面吗？如果此时有100个客户度这样，你的MySQL能扛得住SESSION级别的并发吗？
NO NO NO ，撑不住，这也是大部分情况用REDIS的原因之一。 比如购物车，比如在聊天临时的一些设置，比如一些客户在点餐时临时的喜好设定，这些变化是非常大的，数据库是不能将这些数据库都存储的，如果这么干了你的数据库将是一个垃圾堆。
所以临时表的特性就在这里出现了，快速，临时，高效，且这些数据量都不大，后续可以将这些数据在刷到磁盘上的方法更简单。同时这里还有一个特性，就是用户可能很快速的退出，比如突然想买东西了，又不买了等等，然后过5分钟又上来买了，你说说，你让程序怎么设计，这些数据到底是存不存。
所以对于这些数据，大部分程序设计对其的定义是，必要但非必须得数据，你说客户登录上来，之前的购物车清空了，他也不会怎么样，那么在MySQL使用中没有他的好基友，REDIS。使用这个也可以来满足一些需求。
CREATE TABLE my_memory_table (
id INT PRIMARY KEY,
name VARCHAR(50),
age INT
) ENGINE=MEMORY;
CREATE INDEX idx_name ON my_memory_table(name);
任何事物都有他的优缺点MySQL的内存表的问题也是显而易见
1 不能存储一些特殊的字段，比如BLOB,TEXT 等字段，当然如果用了这个内存表，也不应该用类似的字段类型。
2 不支持事务，对不支持事务，你见过REDIS支持事务吗，见过，但那也是MySQL中的内存表是不支持事务，也就是你写进去无法进行ROLLBACK，你可以理解为autocommit。
3 不要本末倒置，内存表是好用，但是要有限度，或者你的这个数据库服务器如果大量使用了内存表就不要把核心的业务，往这个MySQL上放，INNODB BUFFER POOL 和 你的 内存表都会用内存，如果两方争抢内存，那么对系统是糟糕的，甚至导致 OOM。
这里注意一个参数max_heap_table_size： 内存表的最大尺寸，这里的参数是指的一个表，如果你有多个表就是多个表的N * max_heap_table_size = 总内存，说到这里聪明的同学已经意识到一个问题。
MySQL的内存表所在的数据库服务器的innodb_buffer_pool 不能设置的和普通的MySQL一样大，因为要预留出来内存表要使用的内存空间。具体多大，怎么可以用一个简单的公式来计算。
总内存 - 4G - innodb_buffer_pool - 最大连接数*链接内存 = 内存表总内存/ 表数 = max_heap_table_size
最后，咱们说说软件设计中的内存表使用的关键
在MySQL的内存表的使用中，最重要的注意这两点
1 MySQL内存表是不可以进行从一个MySQL节点到另一个节点的
2 MySQL的故障转移是不会带着内存表的信息的
那么在使用中就必须有一个定期刷新内存表到实体表的过程，具体的频率和方式与业务有关，这样才能在MySQL故障的时候，带着你的内存表走。
截止今天共发布1266篇文章
PostgreSQL “我怎么就连个数据库都不会建？” --- 你还真不会！
PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆
PostgreSQL 分组查询可以不进行全表扫描吗？速度提高上千倍？
POSTGRESQL --Austindatabaes 历年文章整理
PostgreSQL 查询语句开发写不好是必然，不是PG的锅
OceanBase 相关文章
跟我学OceanBase4.0 --阅读白皮书 （4.0优化的核心点是什么）
跟我学OceanBase4.0 --阅读白皮书 （0.5-4.0的架构与之前架构特点）
跟我学OceanBase4.0 --阅读白皮书 （旧的概念害死人呀，更新知识和理念）
PolarDB 相关文章
PolarDB-MySQL 并行技巧与内幕--（怎么薅羊毛）
PolarDB 并行黑科技--从百套MySQL撤下说起 （感谢8018个粉丝的支持）
PolarDB 杀疯了，Everywhere Everytime Everydatabase on Serverless
POLARDB 从一个使用者的角度来说说，POALRDB 怎么打败 MYSQL RDS
PolarDB 最近遇到加字段加不上的问题 与 使用PolarDB 三年感受与恳谈
PolarDB 从节点Down机后，引起的主从节点强一致的争论
PolarDB serverless 真敢搞，你出圈了你知道吗!!!!
PolarDB VS PostgreSQL "云上"性能与成本评测 -- PolarDB 比PostgreSQL 好？
临时工访谈：PolarDB Serverless 发现“大”问题了 之 灭妖记 续集
临时工访谈：庙小妖风大-PolarDB 组团镇妖 之 他们是第一
POLARDB -- Ausitndatabases 历年的文章集合
PolarDB for PostgreSQL 有意思吗？有意思呀
MongoDB 相关文章
MongoDB 合作考试报销活动 贴附属，MongoDB基础知识速通
MongoDB 使用网上妙招，直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)
数据库 《三体》“二向箔” 思维限制 ！8个公众号联合抽奖送书 建立数据库设计新思维
MongoDB 是外星人，水瓶座，怎么和不按套路出牌的他沟通？
阿里云系列
阿里云数据库产品权限设计缺陷 ，六个场景诠释问题，你可以做的更好？
阿里云数据库--市场营销聊胜于无--3年的使用感受与反馈系列
阿里云数据库产品 对内对外一样的卷 --3年阿里云数据库的使用感受与反馈系列
阿里云数据库使用感受--客户服务问题深入剖析与什么是廉价客户 --3年的使用感受与反馈系列
阿里云数据库使用感受--操作界面有点眼花缭乱 --3年的使用感受与反馈系列
