mysql默认最大连接数是多少

Posted 2023-05-04

参考技术A

在使用mysql数据库的时候，经常会遇到这么一个问题，就是“Can not connect to MySQL server. Too many connections”-mysql 1040错误，这是因为访问MySQL且还未释放的连接数目已经达到MySQL的上限。

通常，mysql的最大连接数默认是100, 最大可以达到16384。

在Windows下常用的有两种方式修改最大连接数。

第一种：命令行修改。

>mysql -uuser -ppassword(命令行登录MySQL)

mysql>show variables like \'max_connections\';(查可以看当前的最大连接数)

msyql>set global max_connections=1000;(设置最大连接数为1000，可以再次查看是否设置成功)

mysql>exit(推出)

这种方式有个问题，就是设置的最大连接数只在mysql当前服务进程有效，一旦mysql重启，又会恢复到初始状态。

因为mysql启动后的初始化工作是从其配置文件中读取数据的，而这种方式没有对其配置文件做更改。

第二种：修改配置文件。

这 种方式说来很简单，只要修改MySQL配置文件my.ini 或 myf的参数max_connections，将其改为max_connections=1000，然后重启MySQL即可。

但是有一点最难的就是my.ini这个文件在哪找。

通常有两种可能，一个是在安装目录下（这是比较理想的情况），另一种是在数据文件的目录下，安装的时候如果没有人为改变目录的话，一般就在C:/ProgramData/MySQL往下的目录下。

与连接数相关的几个参数：

在修改最大连接数的时候会有这样一个疑问—这个值是不是越大越好，或者设置为多大才合适？这个参数的大小要综合很多因素来考虑，比如使用的平台所支持的线程库数量（windows只能支持到2048）、服务器的配置（特别是内存大小）、每个连接占用资源（内存和负载）的多少、系统需要的响应时间等。

可以在global或session范围内修改这个参数。

连接数的增加会带来很多连锁反应，需要在实际中避免由此引发的负面影响。

首先看一下MySQL的状态：

mysql> status;

--------------

mysql Ver 14.14 Distrib 5.5.15, for Win32 (x86)

Connection id: 1

Current database:

Current user: root@localhost

SSL: Not in use

Using delimiter: ;

Server version: 5.5.15 MySQL munity Server (GPL)

Protocol version: 10

Connection: localhost via TCP/IP

Server characterset: utf8

Db characterset: utf8

Client characterset: gbk

Conn. characterset: gbk

TCP port: 3306

Uptime: 1 hour 3 min 27 sec

Threads: 12 Questions: 18 Slow queries: 10 Opens: 33 Flush tables: 5 Open tab

les: 34 Queries per second avg: 6.256

--------------

Open tables:34,即当前数据库打开表的数量是34个，注意这个34并不是实际的34个表，因为MySQL是多线程的系统，几个不同的并发连接可能打开同一个表，这就需要为不同的连接session分配独立的内存空间来存储这些信息以避免冲突。

因此连接数的增加会导致MySQL需要的文件描述符数目的增加。

另外对于MyISAM表，还会建立一个共享的索引文件描述符。

在MySQL数据库层面，有几个系统参数决定了可同时打开的表的数量和要使用的文件描述符，那就是table_open_cache、max_tmp_tables和open_files_limit。

mysql> show variables like \'table_open%\';

+------------------+-------+

| Variable_name | Value |

+------------------+-------+

| table_open_cache | 256 |

+------------------+-------+

1 row in set (0.00 sec)

table_open_cache:256，这就是说所有的MySQL线程一共能同时打开256个表，我们可以搜集系统的打开表的数量的历史记录和这个参数来对比，决定是否要增加这个参数的大小。

查看当前的打开表的数目(Open tables)可用上边提到过的status命令，另外可以直接查询这个系统变量的值：

mysql> show status like \'open_tables\';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| Open_tables | 3 |

+---------------+-------+

1 row in set (0.00 sec)

Open_tables就是当前打开表的数目，通过flush tables命令可以关闭当前打开的表。

这个值如果过大，并且如果没有经常的执行flush tables命令，可以考虑增加table_open_cache参数的大小。

接下来看max_tmp_tables:

mysql> show variables like \'max_tmp%\';

+----------------+-------+

| Variable_name | Value |

+----------------+-------+

| max_tmp_tables | 32 |

+----------------+-------+

1 row in set (0.00 sec)

max_tmp_tables:32即单个客户端连接能打开的临时表数目。

查看当前已打开的临时表的信息：

mysql> show global status like \'%tmp%table%\';

+-------------------------+-------+

| Variable_name | Value |

+-------------------------+-------+

| Created_tmp_disk_tables | 0 |

| Created_tmp_tables | 11 |

+-------------------------+-------+

2 rows in set (0.00 sec)

根据这两个值可以判断临时表的创建位置，一般选取BLOB和TEXT列、Group by 和 Distinct语句的数据量超过512 bytes，或者union的时候select某列的数据超过512 bytes的时候，就直接在磁盘上创建临时表了，另外内存中的临时表变大的时候，也可能被MySQL自动转移到磁盘上（由tmp_table_size和max_heap_table_size参数决定）。

增加table_open_cache或max_tmp_tables 参数的大小后，从操作系统的角度看，mysqld进程需要使用的文件描述符的个数就要相应的增加，这个是由open_files_limit参数控制的。

mysql> show variables like \'open_files%\';

+------------------+-------+

| Variable_name | Value |

+------------------+-------+

| open_files_limit | 2670 |

+------------------+-------+

1 row in set (0.00 sec)

但是这个参数是OS限制的，所以我们设定的值并不一定总是生效。

如果OS限制MySQL不能修改这个值，那么置为0。

如果是专用的MySQL服务器上，这个值一般要设置的尽量大，就是设为没有报Too many open files错误的最大值，这样就能一劳永逸了。

当操作系统无法分配足够的文件描述符的时候，mysqld进程会在错误日志里记录警告信息。

相应的，有两个状态变量记录了当前和历史的文件打开信息：

mysql> show global status like \'%open%file%\';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| Open_files | 0 |

| Opened_files | 76 |

+---------------+-------+

2 rows in set (0.00 sec)

MySQL为每个连接分配线程来处理，可以通过threads_connected参数查看当前分配的线程数量：

mysql> show status like \'%thread%\';

+------------------------------------------+-------+

| Variable_name | Value |

+------------------------------------------+-------+

| Delayed_insert_threads | 0 |

| Performance_schema_thread_classes_lost | 0 |

| Performance_schema_thread_instances_lost | 0 |

| Slow_launch_threads | 0 |

| Threads_cached | 0 |

| Threads_connected | 1 |

| Threads_created | 1 |

| Threads_running | 1 |

+------------------------------------------+-------+

8 rows in set (0.00 sec)

比较threads_connected参数和前面提到的max_connections参数，也可以作为目前的系统负载的参照，决定是否需要修改连接数。

查看每个线程的详细信息：mysql>show processlist;对影响系统运行的线程：kill connection|query threadid的命令杀死。

mysql数据库最大连接数可以设置为多少

MySQL服务器的最大并发连接数是16384。

MySQL作为一种开放源代码的关系型数据库管理系统（RDBMS），使用最常用的数据库管理语言结构化查询语言（SQL）进行数据库管理。

MySQL服务器的最大并发连接数受服务器配置，及网络环境等制约，实际服务器支持的并发连接数会小一些，主要决定因素有：

服务器CPU及内存的配置，网络的带宽。

互联网连接中上行带宽的影响尤为明显。

扩展资料：

与其他的大型数据库例如Oracle、IBM DB2、MS SQL等相比，MySQL自有它的不足之处，如规模小、功能有限等，但是这丝毫也没有减少它受欢迎的程度。对于一般的个人用户和中小型企业来说，MySQL提供的功能已经绰绰有余，而且由于MySQL是开放源码软件，因此可以大大降低总体拥有成本。

由于这四个软件都是开放源码软件，因此使用这种方式可以以较低的成本创建起一个稳定、免费的网站系统。MySQL加PHP的配对在互联网上的应用相比LAMP来说更为常见，并获得了动态配对的雅号，大部分Blog网站基于的WordPress系统主要运用MySQL加PHP的配对。除了LAMP之外，用于Solaris、Windows和Mac上的网站构架也分别被称为SAMP、WAMP和MAMP。

参考资料来源：百度百科——MySQL数据库

参考技术A 就是说可以100个数据库用户同时登陆。
解释：因为数据库连接是可以并发访问的，也就是说100个用户同时访问同一个数据库，只要数据库服务器内存足够，mysql并发100个是没任何问题的，如果超过电脑可承受范围，可能直接导致荡机，所以建议根据实际情况调整最大连接数。 参考技术B 通常，mysql的最大连接数默认是100, 最大可以达到16384

与连接数相关的几个参数：

在修改最大连接数的时候会有这样一个疑问—这个值是不是越大越好，或者设置为多大才合适？这个参数的大小要综合很多因素来考虑，比如使用的平台所支持的线
程库数量（windows只能支持到2048）、服务器的配置（特别是内存大小）、每个连接占用资源（内存和负载）的多少、系统需要的响应时间等。可以在
global或session范围内修改这个参数。连接数的增加会带来很多连锁反应，需要在实际中避免由此引发的负面影响。本回答被提问者采纳 参考技术C

现象

Sysbench对MySQL进行压测, 并发数过大(>5k)时, Sysbench建立连接的步骤会超时.

猜想

猜想: 直觉上这很简单, Sysbench每建立一个连接, 都要消耗一个线程, 资源消耗过大导致超时.

验证: 修改Sysbench源码, 调大超时时间, 仍然会发生超时.

检查环境

猜想失败, 回到常规的环境检查:

MySQL error log 未见异常.

syslog 未见异常.

tcpdump 观察网络包未见异常, 连接能完成正常的三次握手; 只观察到在出问题的连接中, 有一部分的TCP握手的第一个SYN包发生了重传, 另一部分没有发生重传.

自己写一个简单的并发发生器, 替换sysbench, 可重现场景. 排除sysbench的影响

猜想2

怀疑 MySQL 在应用层因为某种原因, 没有发送握手包, 比如卡在某一个流程上:

检查MySQL堆栈未见异常, 仿佛MySQL在应用层没有看到新连接进入.

通过strace检查MySQL, 发现 accept() 调用确实没有感知到新连接.

怀疑是OS的原因, Google之, 得到参考文档: A TCP “stuck” connection mystery【http://www.evanjones.ca/tcp-stuck-connection-mystery.html】

分析

参考文档中的现象跟目前的状况很类似, 简述如下:

正常的TCP连接流程:

Client 向 Server 发起连接请求, 发送SYN.

Server 预留连接资源, 向 Client 回复SYN-ACK.

Client 向 Server 回复ACK.

Server 收到 ACK, 连接建立.

在业务层上, Client和Server间进行通讯.

当发生类似SYN-flood的现象时, TCP连接的流程会使用SYN-cookie, 变为:

Client 向 Server 发起连接请求, 发送SYN.

Server 不预留连接资源, 向 Client 回复SYN-ACK, 包中附带有签名A.

Client 向 Server 回复ACK, 附带 f(签名A) (对签名进行运算的结果).

Server 验证签名, 分配连接资源, 连接建立.

在业务层上, Client和Server间进行通讯.

当启用SYN-cookie时, 第3步的ACK包因为 某种原因 丢失, 那么:

从Client的视角, 连接已经建立.

从Server的视角, 连接并不存在, 既没有建立, 也没有”即将建立” (若不启用SYN-cookie, Server会知道某个连接”即将建立”)

发生这种情况时:

若业务层的第一个包应是从 Client 发往 Server, 则会进行重发或抛出连接错误

若业务层的第一个包应是从 Server 发往 Client的, Server不会发出第一个包. MySQL的故障就属于这种情况.

TCP握手的第三步ACK包为什么丢失

参考文档中, 对于TCP握手的第三步ACK包的丢失原因, 描述为:

Some of these packets get lost because some buffer somewhere overflows.


我们可以通过Systemtap进一步探究原因. 通过一个简单的脚本:

probe kernel.function("cookie_v4_check").return


source_port = @cast($skb->head + $skb->transport_header, "struct tcphdr")->source

printf("source=%d, return=%d\\n",readable_port(source_port), $return)

function readable_port(port)

return (port & ((1<<9)-1)) << 8 | (port >> 8)

观察结果, 可以确认cookie_v4_check (syn cookie机制进行包签名检查的函数)会返回 NULL(0). 即验证是由于syn cookie验证不通过, 导致TCP握手的第三步ACK包不被接受.

之后就是对其中不同条件进行观察, 看看是哪个条件不通过. 最终原因是accept队列满(sk_acceptq_is_full):

static inline bool sk_acceptq_is_full(const struct sock  *sk)   return sk->sk_ack_backlog > sk-   >sk_max_ack_backlog;


恢复故障与日志的正关联

在故障处理的一开始, 我们就检查了syslog, 结论是未见异常.

当整个故障分析完成, 得知了故障与syn cookie有关, 回头看syslog, 里面是有相关的信息, 只是和故障发生的时间不匹配, 没有正关联, 因此被忽略.

检查Linux源码:

if (!queue->synflood_warned &&

sysctl_tcp_syncookies != 2 &&

xchg(&queue->synflood_warned, 1) == 0)

pr_info("%s: Possible SYN flooding on port %d. %s.


Check SNMP counters.\\n",

proto, ntohs(tcp_hdr(skb)->dest), msg);

可以看到日志受到了抑制, 因此日志与故障的正关联被破坏.

粗看源码, 每个listen socket只会发送一次告警日志, 要获得日志与故障的正关联, 必须每次测试重启MySQL.

解决方案

这种故障一旦形成, 难以检测; 系统日志中只会出现一次, 在下次重启MySQL之前就不会再出现了; Client如果没有合适的超时机制, 万劫不复.

解决方案:
1. 修改MySQL的协议, 让Client先发握手包. 显然不现实.
2. 关闭syn_cookie. 有安全的人又要跳出来了.
3. 或者调高syn_cookie的触发条件 (syn backlog长度). 降低系统对syn flood的敏感度, 使之可以容忍业务的syn波动.

有多个系统参数混合影响syn backlog长度, 参看【http://blog.dubbelboer.com/2012/04/09/syn-cookies.html】

下图为精华总结

请点击输入图片描述