正如我在幾次演講中所說，改進系統的最好方法是首先不要做“愚蠢的事情”。我并不是說你或你的開發人員是“愚蠢的”，很容易忽視這些類型的決策的含義，而沒有意識到它們對可維護性有多糟糕，更不用說擴展了。作為一名顧問，我一直看到這些東西，我還沒有看到它對任何人都有效。
圖像、文件和二進制數據
您的數據庫支持 BLOB，所以將文件塞進去一定是個好主意，對嗎？不，不是！地獄，與許多數據庫語言綁定一起使用甚至不是很方便。
在數據庫中存儲文件存在一些問題：
- 讀/寫數據庫總是比文件系統慢
- 您的數據庫備份變得龐大且更耗時
- 訪問文件現在需要遍歷應用程序和數據庫層
最后兩個才是真正的殺手。將縮略圖存儲在數據庫中？太好了，現在你不能使用Nginx或其他輕量級的Web服務器來提供它們。
幫自己一個忙，在數據庫中存儲磁盤上文件的簡單相對路徑，或者改用 S3 或任何 CDN 之類的東西。
臨時數據
使用情況統計信息，指標，GPS位置，會話數據 任何僅在短時間內對您有用或經常更改的內容。如果您發現自己使用 cron 作業刪除了某個表的一小時、一天或幾周，那么您為該作業使用了錯誤的工具。
使用redis，statsd / graphite，Riak任何其他更適合該類型工作負載的東西。同樣的建議也適用于不會存活很長時間的臨時數據的聚合。
當然，可以使用反鏟在花園里種植一些西紅柿，但是在車庫里拿起鏟子比用反鏟安排時間讓它到達你的地方并挖掘要快得多。為手頭的工作使用正確的工具。
日志
從表面上看，這個似乎還可以，“我可能需要在未來的某個時候對它們使用復雜的查詢”的論點似乎贏得了人們的支持。將日志存儲在數據庫中并不是一個可怕的想法，但將它們存儲在與其他生產數據相同的數據庫中才是可怕的。
也許您對日志記錄很保守，通常每個 Web 請求只發出一個日志行。這仍然會為站點上爭用用戶可能使用的資源的每個操作生成日志插入。將日志記錄提高到詳細或調試級別，然后看著生產數據庫著火！
相反，使用諸如Splunk，Loggly或普通的舊旋轉平面文件之類的內容來記錄日志。有幾次你需要以奇怪的方式檢查它們，甚至不得不寫一些代碼來找到你的答案，很容易被它放在你的系統上的持續資源所抵消。
日志要想做復雜的分析，可以用ELK比較好。
轉自：https://www.revsys.com/tidbits/three-things-you-should-never-put-your-database/
