MySql错误集
Navicat for Mysql 出现2003 - can't connect to MySQL server on 'localhost' 10061解决
环境：Navicat for Mysql 8.2 + MySQL Sever 5.1
问题：通过MySQL命令行能连接，但是通过Navicat for Mysql 8.2却连不上，出现如下错误：
2003 - can's connect to MySQL server on 'localhost' 10061
解决：
删除安装目录下的my.ini，然后打开/ MySQL Server / MySQL Server Instance Config Wizard（XX:\Program files\MySQL Server 5.1\bin\MySQLInstanceConfig.exe），重新配置。
Can t connect to MySQL server on 解决方法
错误编号：2003
问题分析：
无法连接到 mysql 服务器，可能的情况为：
1、mysql 服务没有启动，一般是在异常的情况下 mysql 无法启动导致的，比如无可用的磁盘空间，my.ini 里 mysql 的 basedir 路径设置错误等；
2、mysql 服务器资源紧张，导致无法连接。
解决方法：
2、如果你是独立主机用户（拥有管理主机权限），则按下面步骤检查：
1）检查是否启动了 mysql 服务。
windows 主机的话，右键点击我的电脑，单击管理，在服务和应用程序中找到
(10061)"， 说明你的mysql还没有启动。
解决办法：在服务中，启动mysql服务
解决方案，1。建议修改最大连接数，或者把 mysql_connect() 方法都改成了mysql_pconnect() 方法，
链接数的修改：
此错误与一个注册表键值tcptimedwaitdelay有关。减小windows中
tcptimedwaitdelay时间可解决此类问题，默认情况下为240（未设置的情况下也是
这个数值）。此项设置需要到注册表如下位置进行设置：[hkey_local_machine]
[system] [currentcontrolset] [services] [tcpip] [parameters]
[tcptimedwaitdelay]如果注册表中没有tcptimedwaitdelay这个项目，请增加这个
项目，并设置为双字节（dword）类型。数值设置为30 60 之间即可。
服务器端的操作系统是windowsxp sp2，自带的防火墙中打开3306（mysql的默认端
口）端口
错误编号：2003
问题分析：
无法连接到 MySQL 服务器，可能的情况为：
1、MySQL 服务没有启动，一般是在异常的情况下 MySQL 无法启动导致的，比如无可用的磁盘空间，my.ini 里 MySQL 的 basedir 路径设置错误等；
2、MySQL 服务器资源紧张，导致无法连接。
解决方法：
1、如果你是虚拟主机用户（购买的空间），则联系空间商检查 MySQL 是否正常启动，并确认 MySQL 的配置信息（是否为 localhost）；
2、如果你是独立主机用户（拥有管理主机权限），则按下面步骤检查：
1）检查是否启动了 MySQL 服务。
Windows 主机的话，右键点击我的电脑，单击管理，在服务和应用程序中找到 MySQL 服务，看是否是已启动的状态。
Linux主机，在控制台执行 service mysql start 启动 MySQL 服务。
2）检查磁盘空间是否还有剩余可用空间，尽量保持有足够的磁盘空间可用。
3）检查 my.ini 里的 basedir （MySQL 安装地址） 和 datadir （数据目录存放地址）等参数设置是否正确，然后重新启动下 MySQL 服务。
4）如果在刷新后偶尔能够正常显示而且服务器是Windows系统的话，那么减小Windows中TcpTimedWaitDelay时间可解决此类问题，默认情况下为240（未设置的情况下也是这个数值）此项设置需要到注册表如下位置进行设置HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay 如果注册表中没有TcpTimedWaitDelay这个项目，请增加这个项目，并设置为双字节（DWORD）类型数值设置为30 ~ 60 之间即可
长时间后mysql自动关闭连接
mysql5数据库连接超时问题的解决办法 最近碰到一个mysql5数据库的问题。就是一个标准的servlet/tomcat网络应用，后台使用mysql数据库。问题是待机一晚上后，第二天早上第一次登录总是失败。察看日志发现如下错误：
“com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:
Communications link failure
Last packet sent to the server was 0 ms ago.”
经过一番调研，发现很多人都碰到过类似问题，但网上令人满意的回答并不多。mysql网站上的提问也很多，但并没有正确答案;百度知道上倒是有一个近似正确的回答。现将本人的解决办法总结一下：
上述问题是由mysql5数据库的配置引起的。mysql5将其连接的等待时间(wait_timeout)缺省为8小时。在其客户程序中可以这样来查看其值：
mysql﹥ mysql﹥ show global variables like 'wait_timeout'; +---------------+---------+ | Variable_name | Value | +---------------+---------+ | wait_timeout | 28800 | +---------------+---------+ 1 row in set (0.00 sec) 28800 seconds，也就是8小时。
mysql> show variables like '%timeout%'; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | connect_timeout | 10 | | delayed_insert_timeout | 300 | | innodb_lock_wait_timeout | 50 | | innodb_rollback_on_timeout | OFF | | interactive_timeout | 28800 | | net_read_timeout | 30 | | net_write_timeout | 60 | | slave_net_timeout | 3600 | | table_lock_wait_timeout | 50 | | wait_timeout | 28800 | +----------------------------+-------+ 10 rows in set (0.00 sec)
如果在wait_timeout秒期间内，数据库连接(java.sql.Connection)一直处于等待状态，mysql5就将该连接关闭。这时，你的Java应用的连接池仍然合法地持有该连接的引用。当用该连接来进行数据库操作时，就碰到上述错误。这解释了为什么我的程序第二天不能登录的问题。
你可能会想到在tomcat的数据源配置中有没有办法解决?的确，在jdbc连接url的配置中，你可以附上“autoReconnect=true”，但这仅对mysql5以前的版本起作用。增加“validation query”似乎也无济于事。
本人觉得最简单的办法，就是对症下药：既然问题是由mysql5的全局变量wait_timeout的缺省值太小引起的，我们将其改大就好了。
查看mysql5的手册，发现对wait_timeout的最大值分别是24天/365天(windows/linux)。以windows为例，假设我们要将其设为21天，我们只要修改mysql5的配置文件“my.ini”(mysql5 installation dir)，增加一行：wait_timeout=1814400
需要重新启动mysql5。
linux系统配置文件：/etc/my.cnf
测试显示问题解决了。