一直连接属于长连接，网站加入并发请求数会很多，如果是一个长连接的话，你的网站加入并发请求数很多，也就是说同时有很多人来访问你的网站，并且每个访问者都需要查询一次mysql数据库的话，会很快把你的系统资源消耗完了。
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：申请域名、雅安服务器托管、营销软件、网站建设、九江网站维护、网站推广。
每次连接都属于短链接，短链接就没有这个问题，每次查询完就马上关闭了，这样不容易消耗过多的系统资源。但是长连接也有个好处就是，频繁查询的时候，可以节省了多次建立TCP连接的时间
如果操作这个数据的人不多，并你进行长连接的连接资源使用很频繁的话使用长连接。这样速度比较快。
顾名思义，长连接就是一直连接从未断开。你应该清楚数据库连接有的是限定连接个数的。你一直连接就占用了一个连接资源。如果连接这个数据库的人不多的话，这样没问题，还能加快速度，你每次操作数据库的时候不用在进行连接操作。这样会加快效率。
如果这个数据库使用的人比较多的话，最好使用短链接，这样用完就释放。不会一直占着连接资源。导致其他人想用都连接不上。
可以 用pconnect就行，但是要设置好连接数和过期时间。
长连接避免了每次请求都重新建立连接，理论上是好事儿，欣然用之；后发现nginx偶尔会报如下错误：
.... [error] 23951#0: *121082947 readv() failed (104: Connection reset by peer) while reading upstream ...
而且有同事A反应，调用同事B的接口时，收到了200响应码，但是没有收到响应的其他数据，而且确认不是因为超时所致；同事B反馈说，接口执行正常，应该有数据返回，而且确认接口执行速度很快，日志为证。
双方说的都对，事实却是如此，我试图模拟这种情况的出现，模拟办法：
让接口输出响应码后，直接杀死fpm进程，nginx果然报出了几乎一样的错误；但是实际场景中，没有发现fpm猝死的任何蛛丝马迹，也找不到fpm会在响应头输出之后就猝死的理由；