Mysql连接数设置和获取的方法

获取连接数

--- 获取最大连接数
SHOW VARIABLES LIKE '%max_connections%'; 

--- 获取连接列表
SHOW PROCESSLIST; 
--- 获取连接列表
SHOW FULL PROCESSLIST; 

--- 获取当前的链接信息 Threads_connected是当前的连接数
SHOW STATUS LIKE 'Threads%';

--- 获取连接统计 比如历史最大连接数以及最大连接时长等
SHOW STATUS LIKE '%Connection%';

mysql> SHOW STATUS LIKE 'Threads%';
+-------------------+-------+
| Variable_name   | Value |
+-------------------+-------+
| Threads_cached  | 58  |
| Threads_connected | 57  |  ---这个数值指的是打开的连接数
| Threads_created  | 3676 |
| Threads_running  | 4   |  ---这个数值指的是激活的连接数，这个数值一般远低于connected数值
+-------------------+-------+

Threads_connected 跟show processlist结果相同，表示当前连接数。准确的来说，Threads_running是代表当前并发数

设置连接数

临时设置

mysql>show variables like 'max_connections'; --- 查可以看当前的最大连接数
msyql>set global max_connections=1000; --- 设置最大连接数为1000，可以查看是否设置成功
mysql>exit --- 退出

永久设置
可以在/etc/my.f里面设置数据库的最大连接数

[mysqld]
max_connections = 1000

项目中连接池设置

狼蚁网站SEO优化公式由 PostgreSQL 提供，不过底层原理是不变的，它适用于市面上绝大部分数据库产品。还有，你应该模拟预期的访问量，并通过狼蚁网站SEO优化的公式先设置一个偏合理的值，然后在实际的测试中，通过微调，来寻找最合适的连接数大小。

连接数 = ((核心数 2) + 有效磁盘数)

核心数不应包含超线程(hyper thread)，即使打开了超线程也是如此，如果热点数据全被缓存了，那么有效磁盘数实际是0，随着缓存命中率的下降，有效磁盘数也逐渐趋近于实际的磁盘数。需要注意，这一公式作用于SSD 的效果如何，尚未明了。
好了，按照这个公式，如果说你的服务器 CPU 是 4核 i7 的，连接池大小应该为 ((42)+1)=9。

取个整, 我们就设置为 10 吧。你这个行不行啊？10 也太小了吧！

你要是觉得不太行的话，可以跑个性能测试看看，我们可以保证，它能轻松支撑 3000 用户以 6000 TPS 的速率并发执行简单查询的场景。你还可以将连接池大小超过 10，那时，你会看到响应时长开始增加，TPS 开始下降。

你需要的是一个小连接池，和一个等待连接的线程队列

假设说你有 10000 个并发访问，而你设置了连接池大小为 10000，你怕是石乐志哦。

改成 1000，太高？改成 100？还是太多了。

你仅仅需要一个大小为 10 数据库连接池，然后让剩下的业务线程都在队列里等待就可以了。

连接池中的连接数量大小应该设置成数据库能够有效进行的查询任务数（通常情况下来说不会高于 2CPU核心数）。

你应该经常会看到一些用户量不是很大的 web 应用中，为应付大约十来个的并发，却将数据库连接池设置成 100， 200 的情况。请不要过度配置您的数据库连接池的大小。

是不是越大约好

模拟 9600 个并发线程来操作数据库，每两次数据库操作之间 sleep 550ms，注意，视频中刚开始设置的线程池大小为 2048。

让我们来看看数据库连接池的大小为 2048 性能测试结果的鬼样子

每个请求要在连接池队列里等待 33ms，获得连接之后，执行SQL需要耗时77ms, CPU 消耗维持在 95% 左右；

接下来，我们将连接池的大小改小点，设置成 1024，其他测试参数不变，结果咋样？

“这里，获取连接等待时长基本不变， SQL 的执行耗时降低了！”

哎呦，有长进哦！

接下来，我们再设置小些，连接池的大小降低到 96，并发数等其他参数不变，看看结果如何

每个请求在连接池队列中的平均等待时间为 1ms, SQL 执行耗时为 2ms.

我去！什么鬼？

我们没调整任何东西，仅仅只是将数据库连接池的大小降低了，这样，就能把之前平均 100ms 响应时间缩短到了 3ms。吞吐量指数级上升啊！

你这也太溜了！

为啥有这种效果?

我们不妨想一下，为啥 Nginx 内部仅仅使用了 4 个线程，其性能就大大超越了 100 个进程的 Apache HTTPD 呢？追究其原因的话，回想一下计算机科学的基础知识，答案其实非常明显。

要知道，即使是单核 CPU 的计算机也能“”运行着数百个线程。但我们其实都知道，这只不过是操作系统快速切换时间片，跟我们玩的一个小把戏罢了。

一核 CPU同一时刻只能执行一个线程，然后操作系统切换上下文，CPU 核心快速调度，执行另一个线程的代码，不停反复，给我们造成了所有进程运行假象。

其实，在一核 CPU 的机器上，顺序执行A和B永远比通过时间分片切换“”执行A和B要快，其中原因，学过操作系统这门课程的童鞋应该很清楚。一旦线程的数量超过了 CPU 核心的数量，再增加线程数系统就只会更慢，而不是更快，因为这里涉及到上下文切换耗费的额外的性能。

说到这里，应该恍然大悟了 ……

以上就是Mysql连接数设置和获取的方法的详细内容，更多关于Mysql连接数设置和获取的资料请关注狼蚁SEO其它相关文章！