OOM 问题
linux内核有个机制叫OOM killer(Out-Of-Memory killer)，当系统需要申请内存却申请不到时，OOM killer会检查当前进程中占用内存最大者，将其杀掉，腾出内存保障系统正常运行。
一般而言，一个应用的内存逐渐增加，肯定是不正常的，这个时候可认为该应用存在内存泄漏，当系统内存被占用到一定的时候，将会触发OOM，此时系统将会找一个最合适的进程杀掉，以释放内存。
原因：
大query带来内存上涨，大量连表查询加载数据到内存中，进行数据筛选，导致内存上涨，触发linux oom 机制 ，杀掉mysql ，同时表数量较多导致innodb数据字典内存占用多
内部解决思路：
1.先进行数据库配置升级，海豚库升级到16c128G配置，略知库升级到8c32g。
2.持续监测内存，发现内存占用基本60%左右。
3.进行慢sql，连表查询sql优化。
4.计划迁移mysql 到polardb。
5.排查linux日志，定位触发oom的时候mysql 占用内存大小。以及附近sql。
6.设置mysql 禁用oom机制，将mysql评分降为最低，oom时候 只会杀掉评分最高的进程。
7.降低mysql Buffer Pool值，因为阿里云rds 默认此值占用过高（最高65%内存），降低缓存区大小，可以预留一部分内存作为抵抗不可控风险使用。
8.彻底关闭linux oom机制。 sysctl -w vm.panic_on_oom=1
实际执行中遇到的问题：
- 由于阿里云RDS只支持对数据库的使用，不支持对系统层面的一些配置。所以上述第6条、上述第8条，不可用
- 由于阿里云RDS配置Buffer Pool
需要重启mysql，项目量级较大，重启耗时半小时以上，所以上述第7条，不可用，有动态调整缓存区大小方案，但是性能抖动很激烈，花费时间更久，不推荐。 - 由于阿里云RDS不支持查询linux日志，oom日志暂未获得，阿里方给了一部分oom附近sql。进行参考优化。
- 由于迁移polardb对现在数据库性能影响较大，迁移时间不可控，迁移过程中增量数据迁移方案未确定，目前正在调研中。
)
