在项目中使用全局数据库连接变量不会有性能问题吗？

Question

在很多常驻内存的语言比如java，golang我们习惯性搞个连接池
但是看到很多项目中使用全局变量的数据库connection，这样并发量高了不会有性能问题吗？

每个执行在一个连接里排队

Answer 1

你可以从以下几个方面理解这个问题：

java。

java怎么做的呢？
整个应用共用一个dataSource。（多数据源另说）
datasource到底是什么呢？
数据库连接池。
那么数据库连接池到底是什么东西呢？
和go一样。
https://godoc.org/database/sq...

怎么对应的呢？
SetMaxIdleConns对应jdbc的maxIdle。
SetMaxOpenConns对应jdbc的maxActive。

如果你不求甚解的话，那么结论就是，既然java没问题，那么go这么操作，大概率也就没问题。

如果还要追究下去的话，

连接池

通常我们设置连接池的最大连接数，设置在5或者10左右，有些设置在20。

假设你是用的是单机房内部业务，mysql和应用服务器之间的ping延迟在0.1ms或者更低，那就可以忽略。

也就是说，如果我们sql写的没问题的话，假设一个SQL执行5-10ms，
那么连接数是5的连接池，可以支撑500-1000QPS的数据库访问，
连接数是10的，再翻倍。

而且，现在普遍使用的的mysql实例（SSD），
一方面是mysql自身带有buffer pool缓存，大部分SQL都会落在缓存中，直接返回，不进行IO操作。
另一方面，SSD极大地解决了mysql的随机IO问题，也能相当程度上提升rt，很多情况下数据库的访问rt在1ms左右或者更低。
这样连接数是5的话，支撑的数据库QPS在5000QPS以上。

当然，对于这个世界上大部分网站，数据库QPS在10以上已经很高了…

Answer 2

只有一个连接，不加锁：同一个连接是同一个数据库session，A线程开启的事务可能会被B线程给关掉…
只有一个连接，加锁：相当于一个只有一个连接的线程池，性能不好
9102年了，连接池也是无脑配置，能用就用吧

Answer 3

数据库连接是珍贵的，频繁建立连接和断开连接会消耗大量的数据库性能，每一个数据库的最大连接数量是有限制的，可以从配置文件里面配置。
倘若一个http请求建立一个数据库连接，在高并发的情况下，数据库连接 = http请求，

数据库 猝

因此推荐使用数据库连接池，池子里边放一堆连接，不够的话就从新建立，够得话直接获取，空闲的话就把多余的关掉。
这样限制了数据库连接的数量。

tcp 发包和收包是串行的
发包/收包越快，sql语句效率执行越高，连接禅让的越快 (为了让其他的线程获取到这个连接).

这里也是弊端所在，当连接池的连接超过了配置的最大连接数以后，客户端不会再建立新的连接，其他线程只有等待到有连接之后才会继续往下走。这里可以通过配置数据库最大连接数和增加服务器配置来优化。