惨痛教训，为什么不建议大字段跟主字段存储在一张表

问题描述

当初接手一个老项目，在已有功能上需要增加拉取脚本数量，量级在数万，不超过十万。每个脚本的数量大约10k左右，需要一次性将脚本全部拉取下来。

由于没有第三方存储，直接存的数据库，因为脚本数量定死了不会过多（勿喷）。

而脚本是从第三方拉取下来的，一次性全量，并且每次都会伴随着一条记录的多次更新。

从而导致了insert失败超时，update失败死锁等问题。

第一版解决方案

使用本地队列（无消息中间件），开启一个定时任务消费队列，减缓更新速度。问题得以减缓，但偶尔还是会出现死锁。

当然，索引是存在的，但是脚本内容与主字段存储在一起的

第二版解决方案

拆分表，缩短文本字段长度（之前是longtext）。

独立一张小文件管理表，记录文件MD5值，从而实现闪传（其实就是已经上传了，检测到MD5值一样，直接上传成功）

原来的大字段则存储文件的ID。小文件插入数据时也使用队列+定时任务消费。问题得到解决。

第三版方案

文件内容存数据库真的太难了，量小还好，量大就完蛋。公司最后决定在新版本上使用中间存储解决。感谢上苍！