有些东西真别往数据库塞，麻烦多又不靠谱，越存越乱难清理

（知乎用户“程序员阿明”分享）
有次我接手个老项目，数据库里有个字段存的是用户上传的Excel文件——直接把二进制文件塞进表里了，等到客户要求导出历史数据时，发现早期存的文件版本因为没记录Office兼容性，用新软件打开全是乱码，更绝的是，有个离职同事在备注字段里贴过一沓JSON格式的日志，结果JSON里的引号和数据库引号冲突，备份时直接报错中断，这玩意儿就像在衣柜里塞螺丝刀，用的时候得翻遍所有衣服，还可能划破袖子。

（某创业公司CTO在技术复盘会吐槽）
我们曾把用户实时GPS轨迹点全插进MySQL，结果两周撑爆硬盘，后来抽出来用时空数据库重做，发现旧数据里竟有经纬度（181, 200）这种神仙坐标——前端没校验，后端直接入库，最头疼的是业务部门把“临时”计算的客户积分更新记录也塞主表，等要做用户画像时，同一个用户有300条积分记录，鬼知道该用哪条？这种“先存再说”的思维，相当于把装修废料堆在客厅，日子久了连走道都找不到。

（豆瓣小组“程序员们的日常”讨论帖）
见过最离谱的是用数据库存视频切片，本来CDN能搞定的事，非要把每段5MB的视频块编码成BASE64往表里怼，美其名曰“减少外部依赖”，等用户量上来，数据库延迟飙到3秒，拆库时不得不停服48小时迁移数据，还有人在用户名字段存emoji+HTML标签，系统漏洞扫描时直接报警说有XSS风险——清理时得逐行正则匹配，比掏下水道还费劲。

（匿名开发者论坛案例）
某电商系统把商品SKU和库存变化流水都塞同一张表，美其名曰“避免联表查询”，结果“双11”每秒两千笔订单，数据库锁等待直接崩盘，更麻烦的是业务逻辑依赖流水记录里的中文备注，客服手动减库存-李姐电话确认”，后来李姐离职，没人知道为什么某款手机会少扣20台，这种把业务因果链存进数据库的行为，就像用记事本记密码，时间久了连自己都解不开。

（技术博客《数据库设计七宗罪》节选）
有个政府项目在Oracle里存了十年公文扫描件（PDF+图片），单表超过500GB，审计要求按文号追溯时，发现早期文件没存MD5校验码，部分文件损坏都无法察觉，还有字段用varchar(255)存URL，结果后来网址超过长度被截断，生成的外链全部失效，这类“存了等于没存”的坑，好比把钥匙扔进废纸堆，需要时只能把纸堆全烧了炼金属。

（Reddit的r/programminghorror版块热帖）
同事设计过用数据库存定时任务日志，每天新增百万行却从不归档，某天磁盘告警，删数据时发现没建索引，一条delete执行6小时把从库拖垮，更魔幻的是表里有debug用的测试数据，日期写着“9999-12-31”，导致报表统计年年跳出一条未来数据，这种把数据库当“无限草稿纸”的用法，最终会让系统像塞满废纸的打印机，卡住的那一刻才知道早就该换纸篓。

（某金融系统架构师内部备忘录）
支付系统曾把风控规则配置全以XML格式塞进clob字段，每次修改都要锁表，有次误操作写入错误标签，导致全国POS机交易拒绝，复盘时发现竟没有配置版本回溯功能——因为觉得“数据库事务本身就能回滚”，这暴露了把数据库当版本控制工具的荒诞：就像用保险箱装油漆桶，看似安全实则一塌糊涂。

（总结自多个Stack Overflow高票答案）
为什么人们总爱乱塞数据？因为短期来看，ALTER TABLE比重构代码简单；长久却像在螺蛳粉里倒红酒，单看每个动作都合理，混合起来就成了灾难，真正的教训是：数据库该当严谨的账本，而非杂物间，那些“先存着说不定有用”的数据，往往变成数字沼泽里的恐龙骨架——挖出来费劲，不挖又碍事。