SQL數(shù)據(jù)庫(kù)連接數(shù)真的是越大越好嗎？

??

PostgreSQL max_connections配置優(yōu)化參考資料：????? https://www.cnblogs.com/wy123/p/14087274.html

https://blog.csdn.net/antch620/article/?details/120902705

? ? 最佳性能是當(dāng)存在300-500個(gè)并發(fā)連接時(shí)。在700之后，性能急劇下降(就每秒事務(wù)數(shù)和延遲而言)。超過(guò)1000個(gè)連接的任何連接均表現(xiàn)不佳，并且延遲不斷增加。在Google Cloud和Heroku這些云平臺(tái)上，也將max_connections限制在了500左右。難怪國(guó)外大佬們會(huì)給出"a few hundred,""not more than 500," and "definitely no more than 1000."

從上面可以得到一個(gè)通用的結(jié)論，max_connections不建議超過(guò)700，最大不超過(guò)1000，300 ~ 500區(qū)間性能最好。

max_connctions不易過(guò)大，要考慮到local memory，尤其是work_mem，推薦300 ~ 700區(qū)間的值，再高性能就損耗明顯了，對(duì)于高吞吐量的數(shù)據(jù)庫(kù)，可以考慮使用應(yīng)用層面內(nèi)置的連接池，也可以使用應(yīng)用和數(shù)據(jù)庫(kù)中間一層的連接池如pgbouncer。

如何處理對(duì)數(shù)據(jù)庫(kù)的并發(fā)請(qǐng)求數(shù)大于數(shù)據(jù)庫(kù)的最大連接數(shù)：

????如果連接數(shù)是一個(gè)合理的值，不是100或者200，真正的并發(fā)數(shù)超出最大連接數(shù)，此時(shí)必須使用連接池，否則會(huì)報(bào)超出最大連接數(shù)的錯(cuò)誤，連接池不僅可以提高連接效率，在超出最大連接后等待機(jī)制，也可以起到了限流的作用。

而如果真的不去限制最大連接數(shù)，隨著并發(fā)的增加去機(jī)械地增加連接數(shù)，只會(huì)沖垮數(shù)據(jù)庫(kù)，即便沖不跨數(shù)據(jù)庫(kù)，其結(jié)果就是所有的請(qǐng)求，在數(shù)據(jù)庫(kù)里相互牽制相互拖累。