1樓：胡樂樂
首先得理解什麼是複雜SQL，巢狀查詢、多表關聯這些SQL複雜但不代表效能一定低下。
只要執行計畫合理，資料庫可以將資料快速取出並返回結果。
如果比較基於記憶體的資料處理計算，兩者差異應該不大。
2樓：萌豆
你想想看，首先應用層計算的演算法優化一般不如資料庫內部幾十年的優化能力強；其次多執行緒去拉資料在應用層計算，資料庫內部也有多執行緒，而且有更好更極致的多執行緒排程同步協調等能力；再次即使上述兩者一樣，你在資料庫側算完再到應用層比你所有資料都到應用層，肯定少了很多資料傳輸量，網路消化小很多（資料報啊，協議啊，序列化和反序列化等開銷），在資料庫內部做還有可能部分資料查詢被優化掉，計算量更少。
因此，如果資料庫壓力不大的話，同樣資源量下理論上大部分時候還是資料庫更快。當然不排除那些不夠成熟和完整，或者場景完全不合適的資料庫在特殊場景效能不夠好。
3樓：任弘迪
如果能預先知道查詢型別和準確的資料分布確定最優的訪問路徑和方式做預計算，那還是可能更快的。對乙個通用場景的話，不看好。
從題幹括號裡那些優化來看，不能。跟資料庫已經實現的優化相比基本拿不出手。題主好像有點小看資料庫行業無論學術界還是工業界幾十年的積累了。
4樓：野鴿知了
我覺得並不會，因為資料庫中的複雜 SQL，表關聯什麼的，其實很多也是在記憶體中執行，而搞資料庫的那群大神已經把這些優化做到了極致。
但是在遇到複雜 SQL 時，還是建議拆成多個查詢，在記憶體中處理資料。為什麼呢，因為大部分的專案，資料庫一般只會部署乙個例項，部署集群會比較麻煩，而應用部署集群就相對容易的多，所以一般是多個應用集群對應乙個資料庫例項。這樣的話，拆分複雜 SQL，減少資料庫的壓力，把資料處理的壓力放在應用中，會比較好。
在分布式資料庫儲存中，資料分割槽和資料放置有什麼區別？
楊東東 資料分割槽和資料放置是邏輯和物理的關係，邏輯是頂層設計，物理是具體實現，邏輯設計決定物理實現，物理約束反過來影響邏輯設計。舉個例子，給你10個桌球，要求放入3個盒子裡。如何決定哪個球放入哪個盒子？比如 按照編號大小 0 2放入盒子A，3 5放入盒子B，6 9放入盒子C 按照編號特徵 對3取餘...
向資料庫插入資料時，時間欄位的值，是在程式中新增還是依賴資料庫的函式，由資料庫去管理時間？？
首先要看你的時間字段用於什麼場景。如果你要用來對賬或者做某時間段的冪等的話，也就是具有功能性業務性的，推薦還是由程式決定。因為程式本身會產生時間，和你儲存好的這種時間進行對比，必須統一由程式決定。如果與功能無關推薦資料庫來管理。這樣的話不僅能讓資料在落地的時候統一標準，還可以依賴資料庫的特性來方便的...
微服務架構中可以直接使用資料庫作為註冊中心嗎？
小小笑兒 可以的，註冊中心只是為了統一管理服務的註冊資訊，是很多的對。所以說只要是能夠提供儲存和查詢資料的工具都可以用來作為註冊中心。比如你完全可以自己寫乙個 http server 來作為自己的註冊中心 類似 eureka 三觀成型沒法改 可以其實大多數公司連日均8000pv的訪問坎都過不去，my...