遇到一个问题如图：之前没见过。背景是数据库自己关闭了。MySQL8.
但是输出的第一行报错不是数据库自己的日志，而是terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc。从字面分析错误的分配。怀疑和内存溢出有关。结合监控看到了SWAP开始大量释放。
MySQL的内存给了20G，不大但是也不算小。怀疑是大事务导致连续内存不足，而导致溢出。解析一下binlog，发现有些的确是比较大的。
std::bad_alloc这个报错经过查询是C++的输出，该异常是因为在使用new分配内存空间时，内存空间不够时就会抛出该异常。这么一想就通了。MySQL是C写的。那么一定是数据库需要内存而没有，导致了数据库异常退出。
为此我特意去官网上查Bug发现没有。进而我们看看整个机制。malloc分配内存是先在虚拟内存中分配地址的，到实际使用时才真正的映射到物理内存
到了MySQL真正要映射物理内存时，首先分配物理内存，此时top的res增加。如果物理内存不够用了，分配swap，此时性能很差，此时top的res增加
所以，如果由于机器内存使用不当，到了MySQL真正要映射物理内存时，如果物理内存（内存+swap）不足了，就会出错甚至退出。
（为什么数据库物理机相对来说好，这又是一个佐证）
结论：innodb_buffer_pool_size在mysqld启动时在虚拟内存中分配地址，在使用过程中再映射到物理内存,如果物理内存（内存+swap）不足了，就会出错甚至退出。
一般来说其实内存也够用，即使不够用也就是慢。因为内存和磁盘大量交互。而直接退出这个的确不常见。我依然怀疑这个是大事务造成，而且是连续性的。这里不得不说这个机器的背景，就是用来做大量分析。其实这不是MySQL擅长的。咱们不能因为讲MySQL就说MySQL什么都好，也不能说其他就不行。尺有所短寸有所长。如果使用MySQL做分析，请使用MySQL云端的企业版，配上heatwave插件。
数据库选型是个学问，最好是懂数据库的人一锤定音，而不是负责应用开发的人发表想法。
