最近上手一个新项目，开始熟悉表的的时候发现其中一个表打开速度很慢，详细查看里面存储的数据，里面存储着img 编码后的数据，这样的一个大字段必然会导致查询数据变慢；这也跟开发中遇到的OOM对应上了；
OOM发生的背景:
微服务架构需要启动多个项目，所以自己给每个项目分配了150M内存，每当自己发布活动的时候、或者上架活动的时候本地项目就会发生OOM，但是一开始没有想这么多就多给了一些内存，现在想起来这个大字段就是真凶之一（最起码是重要原因）。
原因：
当发布活动或者上架活动时，对象就是一个超大对象（它属性中拥有一个超大数据字段）,内存空间（年轻代、老年代均不足）无法开辟这么大的空间的时候直接跑出 OOM
解决方案：
1、先弄清楚一开始为什么用mysql存储图片静态资源
方案一：不修改原来业务逻辑的情况下，进行大字段分表再关联至activity表中，必要情况下再查询图片资源；
方案二：使用资源服务器专门存放这些静态资源，然后数据库中只存放静态资源url;
优化：
基于方案一：
优化前：
sql大字段优化前.PNG
优化后：
sql大字段优化后.PNG
由截图见，优化前总数据量才四百多，但是一个简单查询就花了15s多，可见响应速度多慢，经过简单的分表后查询速度提升至0.05s，提升巨大，使用主键查询一条时，优化前花时:0.182s，优化后花时：0.048s 同样有3、4倍的提升；特别假如数据量达百万级别时如果不优化系统简直无法使用；但是OOM的问题还是没有解决，所以业务允许情况下个人推荐使用方案二；
网友评论