1樓：極客
私以為查詢瓶頸最可能在網路和記憶體上
併發提高，需要的連線池連線數也要正比提高。
事實上，大佬有研究過：
資料庫連線數=2*(CPU數量)+硬碟數量就夠了所以連線數不要往高了設定。
資料庫瓶頸建議優先分析軟體層面：
SQL語句和查詢邏輯，系統配置引數，資料庫配置引數然後是硬體方面：
網路IO，記憶體，最後是硬碟和CPU
乙個有趣的事實是如果資料查詢比較集中或者記憶體足夠大，那麼快取命中率是非常高的，事實上很多應用快取命中率都能達到99%，如果資料量不大，資料庫甚至可以把全庫快取到記憶體命中率100%，那麼機械和固態其實差別不大，只有在快取不命中的時候，才有差別。
所以私以為瓶頸最可能在網路和記憶體上面。
2樓：
根據我多年的經驗,針對mysql來說就是資源,linux層面來說記憶體,CPU和IO.mysql層面來說就是慢查詢.解決方式有幾個 1 是優化慢sql 2是使用SSD 3是加大記憶體配置 4 針對庫表進行拆分
Oracle資料庫中生產庫 查詢庫 測試庫有什麼區別？
人馬酋長 兄弟or姐妹 你這個問題屬於入門級別的，不過一般沒接觸過肯定沒概念。我給你解釋一下。生產庫顧名思義，就是內容採集錄入的後台庫，一般公司都會將生產庫對接乙個程式化的可視作業系統，通過編輯人員編輯資料進入資料庫。又或者完全通過ETL工具將資料採集到資料庫中，這個庫故稱為生產庫。查詢庫就是給程式...
大資料場景下的查詢優化 vs 資料庫場景下的查詢優化
樹懶學堂 在樹懶君眼中，查詢優化的核心思路應該是這樣的 盡量使語句符合查詢優化器的規則避免全表掃瞄而使用索引查詢 盡量避免向客戶端返回大資料量，若資料量過大，應該考慮相應需求是否合理 建立高效的索引。而在大資料場景下，樹懶君認為，可以從下面的思路來解決查詢優化的問題 合理設計索引，盡量形成索引覆蓋 ...
資料庫聯表查詢時，是直接使用join好還是分別查詢到資料後自己處理較好？
sql語句背後的查詢優化提公升了應用開發的效能下限，同樣也限制了效能優化的天花板，這就是通用優化器的一體兩面。如果對自己的效能優化能力有信心，大可在應用程式中實現join任務，達到應用層 特性 感知的優化，往往比後端的建議更佳。 Shreck Ye 從查詢效率上來講，只要能用到相同的索引，效率應該是...