mysql memory内存表引擎导致的诡异情况

现象：生产某实例突然告警，被踢出ha集群，该实例为从机。检查发现实例binlog中写入了3条delete语句，DELETE FROM `rrxgroup`.`rrx_session`、DELETE FROM `rrxgroup`.`rrx_sso_session`、DELETE FROM `rrxgroup`.`rrx_times`，时间点是2019-05-02 06:16:20。因为ha软件本身是根据主从gtid判断数据一致性的，因而该实例被踢出ha集群。

现象分析：生产环境业务账号默认是没有delete权限的。以为可以排查业务账号导致的，不巧的是这个业务账号申请了delete权限。排查下访问过的用户连接信息

select * from performance_Schema.accounts order by user;

所有连接过的用户均无delete权限，排除了用户直接登录删除的可能性。根据以往经验，memory引擎表在数据库重启时是会出现此种现象。检查下表引擎，三个都是memory引擎表。

排查到这，以为结束了，肯定是数据库重启了。然后检查下错误日志，发现最近一次重启是2019-04-25那天，因为服务器报修需停机，重启了数据库，这就很诡异了，memory引擎表清理数据怎么也不能隔了一个星期执行删除。怀疑是不是有其他的操作触发了内存表delete，查看了下官方文档：官方文档描述的是数据库停止或重启会导致memory引擎表数据丢失。此外没有其他说明。原文描述如下：

• Operations involving transient, non-critical data such as session management or caching. When the MySQL server halts or restarts, the data in MEMORY tables is lost.

此时，只能通过测试加源码调试分析，经过测试分析发现，memory引擎表并不是重启就立马清理数据，而是重启后第一次访问该表所在数据库的时候触发清理操作。

结论：memory引擎表在数据库重启后，第一次访问该引擎表所在数据库时触发清理操作，而且是会记录至binlog中，不管有没有数据。据官方代码注释来看，此种方式是为了解决内存表数据在重启后丢失导致的主从数据不一致问题