概述

任何时候，改进你的系统的最好的方法是先避免做“蠢事”。小编并不是说你或你开发的东西“蠢”，只是有些决定很容易被人忽略掉其暗含的牵连，认识不到这样做对系统维护尤其是系统升级带来多大的麻烦。

图片，文件，二进制数据

既然数据库支持 BLOB 类型的数据，把文件塞进 BLOB 字段里一定没有错了！？

错，别的先不提，在很多数据库语言里，处理大字段都不是很容易。

把文件存放在数据库里有很多问题：

• 对数据库的读/写的速度永远都赶不上文件系统处理的速度
• 数据库备份变的巨大，越来越耗时间
• 对文件的访问需要穿越你的应用层和数据库层

这后两个是真正的问题所在。把图片缩略图存到数据库里？但你就不能使用 nginx 或其它类型的轻量级服务器来处理它们了。

所以最好的解决办法是：在数据库里只简单的存放一个磁盘上你的文件的相对路径，或者使用 S3 或 CDN 之类的服务。

短生命期数据

使用情况统计数据，测量数据，GPS 定位数据，session 数据，任何只是短时间内对你有用，或经常变化的数据。如果你发现自己正在使用定时任务从某个表里删除有效期只有一小时，一天或数周的数据，那说明你没有找对正确的做事情的方法。

最好的解决办法是使用 redis，statsd/graphite， Riak这些合适的工具。这建议也适用于对于收集那些短生命期的数据。

当然，用挖土机在后花园里种土豆也是可行的，但相比起从储物间里拿出一把铲子，你预约一台挖土机、等它赶到你的园子里挖坑，这显然更慢。你要选择合适的工具来处理手头上的事。

日志文件

把日志数据存放到数据库里，表面上看起来似乎不错，而且“将来也许我需要对这些数据进行复杂的查询”，好像看起来不错？这样做并不是一个特别差的做法，但如果你把日志数据和你的产品数据存放到一个数据库里就非常不好了。

也许你的日志记录做的很保守，每次 web 请求只产生一条日志。对于整个网站的每个事件来说，这仍然会产生大量的数据库插入操作，争夺你用户需要的数据库资源。如果你的日志级别设置为 verbose 或 debug，那等着看你的数据库着火吧。

最好的解决办法是使用一些比如 Splunk Loggly 或纯文本文件来存放你的日志数据。这样去查看它们也许会不方便，但这样的时候不多，甚至有时候你需要写出一些代码来分析出你想要的答案，但总的来说是值得的。

总结：图片，文件，二进制数据，短生命期数据，日志文件都不要放在数据库里面，这对于数据库的性能是有很大影响的。

PS：觉得有用的走波关注哦~下期内容更精彩！