Can't connect to MySQL server是不能连接本地数据库服务器MYSQL数据库服务器出错。
成都创新互联主营城步网站建设的网络公司,主营网站建设方案,App定制开发,城步h5重庆小程序开发公司搭建,城步网站营销推广欢迎城步等地区企业咨询
宽带连接在网上邻居右键属性里可以找到
检查服务器端MySQL服务是否已经启动。
检查系统配置文件config.inc.php内提供的MySQL连接帐号是否正确。
如果此问题频繁间断出现，尝试修改config.inc.php内pconnect参数为1，开启MySQL长连接。
资料拓展
电脑无法连接的几个问题
一、网络设置的问题
二、DNS服务器的问题
三、IE浏览器本身的问题
四、网络防火墙的问题
五、网络协议和网卡驱动的问题
六、HOSTS文件的问题
七、系统文件的问题
用户少，使用长连接，减少web端与数据库的逻辑连接数，可以让连接保持久一点，不用频繁建立连接。
用户多，使用短链接，这样用于使用完后就释放连接了。但是消耗系统资源多一点。
web端默认连接池缓存100个连接，超过100个用户同时连接，若使用长连接占用久，物理连接和逻辑连接都需要等待以至超时。使用短连接频繁断开和连接，消耗CPU、内存等
首先它们都是数据库系统，ACCESS适合运用于小型数据库，其建立及管理相对来说比较简单；而SQL
SERVER则使用于企业级别大型数据库，它的建立、配置及管理就复杂很多了。
ACCESS是小型数据库，最大可以运行到100人吧，最多可以用到几万条信息，缺点是容易被下载，文件容易破损，会生成临时文件，在被asp调用时占用IIS资源，降低网站资源利用率，ACCESS不是用于网站开发的数据库。
SQL
Server的安全性比较高，使用的是数据库系统，一般不存在文件损坏问题，有单独的资源池，不会占用IIS的资源。如果你的SQL被下载了，那就是因为你的ASP程序有漏洞。
要是个人用，用access就可以了，不过要注意不要使用长连接连接数据库，要使用短连接。就是在访问完数据库后，运行.close语句来释放资源
有台服务器，访问量挺大，每天近250w动态pv，数据库查询平均每秒近600次 另一台服务器，跑的程序跟这台一样，不过只有每天约40w动态pv 前段时间连续卡死过几次，当时的状态是 服务器没崩溃，数据库可正常登陆。只是所有的查询都卡在“sending data”状态，长时间无法执行完，这些简单的sql语句，有时候集中在A表上，有时候集中在B表上，同时还有一些卡死在locked状态或update状态 看mysql的说明，sending data状态表示两种情况，一种是mysql已经查询了数据，正在发给客户端；另一种情况是，mysql已经知道某些数据需要去什么地方读取，正在从数据文件中读取 mysql官方说，这不是mysql的bug，但是官方也没说怎么处理......那么，看情况，就应该是配置方面的问题了。 首先从sql优化的角度来查了查，那些卡死的sql语句，都是简单查询，消耗非常低，索引做的非常好，所以觉得应该不是sql语句的问题。而且慢查询日志里也没有出现慢查询。 把表都做了优化，就是optimize table ，过几天发现，还是会出现卡死的情况..... 后来考虑增加并发性能，增加了key_buffer thread_cache 等一系列的内存配置，发现没什么作用。情况依旧 再后来，把query_cache减小到默认值 16M，把一些不怎么变动的数据，做了静态化。惊奇的发现，12天过去了，没再出过问题...... 后来想想，修改query_cache可能对这个问题有些帮助，毕竟数据更新比较频繁，query_cache的更新也很频繁。不过看mysql的状态，query_cache的命中率还是相当高的，差不多75％。 觉得问题可能出在程序上，只是没查出来。后来静态化的那些内容，是一些产品的说明文字，一般一个产品的说明也就三五十个汉字。 这里出问题的嫌疑比较大，一个页面有七八个产品，加起来可能三五百个汉字，虽然不多，不过查询很频繁，从这个表上查询的数据量应该是很可观的，mysql会频繁的从这个表拿数据。不过，不过有时候卡死的语句并不是在查询这个表...... 手头没有好使的工具，郁闷。反正问题貌似好了，先放下备案吧，等以后水平高些，再来查。 MySQL很容易进程满而死的一个重要原因建站不容易已经远远超过了我的设想和预期,除了经济上还有技术上的,有些问题不是一般技术人员能解决。不过在这段时间里让我也学会了如何思考问题和解决问题，特别是连续解决了几个问题，可以说真不是开发人员或者别的技术人员能解决的，对此自信心也越来越足了! 谈到这，必须说下我们的站布衣生活网，基本配置，LINUX 9.0系统,JBOSS42 WEB服务，MYSQL，从五一到现在，运行有段时间了，目前的访问量是4000IP左右。 记得以前发生过一个问题也是检查了好久都没解决的，故障一发生CPU就跑到100%左右，系统没响应，MYSQL、JBOSS进程死。当初是通过对一些大数据表建立索引解决的!这次问题现象和这个有点象，死的时候几乎服务没有响应，通过查看后台MYSQL进程，居然已经超过我设置的1000个限制，第1天我把配置改成3000，想想是否跟这个有关，最近的访问量增大了。说实话，我还是不相信并发1000个连接，但事实摆在面前，现在就是1000个进程堵在这!第2天发现3000也不行了，在进程列表中看到基本上很容易就进程满，而且每个进程都在sending data 状态，查找了2天还是无法解决问题，不论是重新配置启动参数还是检查外来攻击都无法解决，按照一些人的说法，把临时缓冲表增大到512M也是没有任何帮助。象这种的每增加个连接都几乎会卡死，而且是sending data 状态!是数据无法发出还是查询不能完成呢? 带着这个问题，跟开发的沟通，是否存在数据死锁或者没有提交的问题，造成的查询锁死!而且有时候是正常，但大部分是不正常的死锁!查了半天，报告说，程序没发现问题，因为根据命令已经能定位到程序的准确代码上了!那么是什么问题呢? 想起以前MS SQLSERVER2000下曾经发生过的数据库损坏的问题，也尝试了修复。根据堵塞命令集中在几个重要的表上，其一是餐馆信息表(4万条记录)，用修复命令都无法修复!发现设置的类型是inoubox ,把类型改成MYISAM 后再修复，修复也没报告什么错误，但重新启动系统后一切问题就解决了!
1、使用show engines 命令查看数据库是否已支持FEDERATED引擎：
2、开启federated引擎
vi /etc/my.cnf
在[mysqld]之后添加：
federated
3、先来安装federated存储引擎
install plugin federated soname 'ha_federated.so';
mysql install plugin federated soname 'ha_federated.so';
ERROR 1125 (HY000): Function 'federated' already exists
已经安装好了，只是没有启用
4、测试一下是否可以：
[root@rhel6Mysql02 ~]# mysqld_safe --federated
[1] 2194
[root@rhel6Mysql02 ~]# 130620 18:12:28 mysqld_safe Logging to '/var/lib/mysql/rhel6Mysql02.err'.
130620 18:12:28 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
若提示mysqld_safe A mysqld process already exists，说明mysql的进程占用了log文件，将mysql服务停止即可：
root@iZ94j7vkg4wZ:~#mysqld_safe --federated
root@iZ94j7vkg4wZ:~# 160726 20:00:07 mysqld_safe Can't log to error log and syslog at the same time. Remove all --log-error configuration options for --syslog to take effect.
160726 20:00:07 mysqld_safe Logging to '/var/log/mysql/error.log'.
160726 20:00:07 mysqld_safe A mysqld process already exists
将mysql服务停止，然后再次运行即可：root@iZ94j7vkg4wZ:~#service mysql status
5、重启mysql服务后，用show engines 命令再次查看，已支持
6、使用FEDERATED建表语句如下：
CREATE TABLE (......) ENGINE =FEDERATED CONNECTION='mysql://[name]:[pass]@[location]:[port]/[db-name]/[table-name]'
创建成功后就可直接在本地查询相应的远程表了。
需要注意的几点：
1. 本地的表结构必须与远程的完全一样。
2.远程数据库目前仅限MySQL
3.不支持事务
4.不支持表结构修改
本地虚拟表名与远程表名，可不相同。
经过测试，这个引擎的一些额外特点：
1. 本地虚拟表与远程实体表之间是 TCP 长连接，并且是多个客户端利用的。所以不用担心因频繁建立连接带来的网络开销。
2. 本虚拟表表与远程实体表之间的网络连接断开后，当对虚拟表发起查询时，它会尝试重新连接远程实体表，所以我们不用担心网络连接断开造成的永久中断问题。
3. 如果无时间未对本地虚拟表作任何操作，虚拟表与实体表之间的连接将在远程主机的 wait_timeout 秒后自动断开，当对虚拟表发起查询时，连接又会重新建立。
一些注意事项：
1. 对本地虚拟表的结构修改，并不会修改远程表的结构
2. truncate 命令，会清除远程表数据
3. drop命令只会删除虚拟表，并不会删除远程表
4. 不支持 alter table 命令
目前使用federated 最大的缺点：
1. select count(*), select * from limit M, N 等语句执行效率非常低，数据量较大时存在很严重的问题，但是按主键或索引列查询，则很快，如以下查询就非常慢（假设 id 为主索引）
select id from db.tablea where id 100 limit 10 ;
而以下查询就很快：
select id from db.tablea where id 100 and id150
自定义消息推送的话，需要使用长连接保持客户端不掉线，然后服务器中需要记录客户端唯一标识符与其对应连接，服务器获取消息后，向指定客户端连接发送消息，如果发送失败，定时器应该在tick到达时再次尝试。
