Showing posts with label 数据库. Show all posts
Showing posts with label 数据库. Show all posts

Thursday, August 12, 2010

PHP 5.3 无法连接 MySQL localhost 服务器问题

最近在 Windows 7 上搭建 WEB 开发环境,下载了各组建最新的版本:
  • Apache httpd 2.2.16
  • MySQL 5.1.49
  • PHP 5.3.3
  • phpMyAdmin 3.3.5

照常安装好以后,phpinfo() 运行一切正常但是在 phpMyAdmin 中却无法连接本机的 MySQL。点击“登录”按钮后,页面等待很长时间,然后出现白页。

经过多番搜寻,终于找到了问题的原因。PHP 升级到 5.3 版本后开始使用 native 的 MySQL 驱动,该驱动连接 MySQL 服务时的行为和之前的 libmysql.dll 有所区别,新驱动对 localhost 的解析,似乎是基于 Windows 自己的 hosts 文件的。而在 Windows Vista / Windows 7 以及 Windows Server 2008 上,hosts 文件里 localhost 解析为 ::1,而非传统的 127.0.0.1。开一个 CMD 的窗口执行 ping localhost 即可验证。从而导致函数 mysql_connect() 无法解析和链接到 localhost。

不仅 phpMyAdmin,用 PHP 5.3.x 在任何时候连接 MySQL 的 localhost 服务器都会出现类似问题,例如:
$db = new PDO('mysql:host=localhost;dbname=windia', DB_USER, DB_PASS);

解决的办法有两个:
  • 在代码中避免使用 localhost 而使用 127.0.0.1
  • 将 Windows 的 hosts 文件中
    ::1          localhost
    改为
    127.0.0.1    localhost

Sunday, August 16, 2009

phpMyAdmin 使用时 Apache 崩溃问题

最近笔记本的硬盘时常怪响,因此换了一块硬盘以防万一,系统重装了,因此开发环境 PHP + MySQL + Apache 也需要重搭。因为已经做过很多次,做起来轻车熟路,然而装好 phpMyAdmin 以后,在登入界面输入用户名密码点登入,居然弹出一个 Windows 应用程序进程崩溃的 report 对话框:Apache 崩溃了……

重新试了几次,仍然如此,换以前硬盘上的 PHP 目录(保证 PHP 的配置和以前一致),无效;换 Apache 版本,无效;换 phpMyAdmin 较早的可以正常使用的版本,无效;用 MySQL 官方的 GUI 客户端登录,可以读写数据,因此不是 MySQL 的问题,于是我就没辙了……

上 Google,发现很多人都有类似的问题,最早的帖子甚至可以追溯到 2003 年,然而没有看到一个有用的解释或者回答,但终究找到一个网页提到架设 PHP + MySQL + Apache 的时候,要保持 MySQL 的客户端连接库 libmysql.dll 版本一致,最好使用 PHP 自带的 dll。

想到这次设置 PHP 时,没有像以前把所有的 dll 都拷贝到 %windows_root%\system32 下,而只是直接的把 D:\PHP 加入到了 PATH 环境变量中。于是马上照以前的办法,把 PHP 包中的相关 dll 都拷贝到了 system32 下,再启动 Apache,进 phpMyAdmin,问题解决了。

用了一会儿,问题有时候仍然存在,于是又把 %Apache%\bin\libmysql.dll 删除(或改名),则问题解决了。但是在 phpMyAdmin 登入后,首页下方会提示说当前使用的 MySQL 客户端版本和服务器版本不相符,可能导致不可预料的结果。

如果各位对此问题有没有更透彻的解释以及彻底的解决办法,望不吝赐教。

Update 2010-02-10:

这个问题似乎和 MySQL 的版本有关。之前出现此问题的 MySQL 版本是 5.4 beta。最近在新机器上同样的架构和设置,只是 MySQL 版本为 5.1,没有出现该问题。

Tuesday, February 13, 2007

MySQL 的自动断开连接问题

最近发现 MySQL 会自动断开 IDLE 时间超过 8 小时的数据库连接,从而导致一些基于数据库连接的应用程序,特别是 WEB 应用程序出错。

有两个办法可以解决这个问题:

第一个办法是修改 MySQL 的配置参数。这个参数的名称是 wait_timeout,其默认值为 28800(单位秒),刚好就是 8 小时。其意义为关闭一个连接之前在这个连接上等到行动的秒数,也就是说,如果一个连接闲置超过这个选项所设置的秒数,MySQL 会主动断开这个连接。

有实践表明,没有办法把这个值设置成无限大,即永久。因此如果你无法保证你的应用程序必定在设定的秒数内至少有一次操作,那么最好用第二个方法解决这个问题。

第二个办法是如下修改 JDBC 连接的 URL:
jdbc:mysql://hostaddress:3306/schemaname?autoReconnect=true

添加 autoReconnect=true 这个参数,即能解决这个问题。

另外,对于 Java 的应用程序,据说第三方的数据库连接池应用 Proxool 能够对断开的数据库连接发起自动重连,不过我没有用过,有兴趣的朋友可以尝试一下。

Tuesday, November 22, 2005

SQL Server 2000 数据库日志

SQL Server 2000 数据库对数据的事务会记录日志,并且能够根据日志回滚数据库操作,这个想必大家都知道。不过,如果日志变得很大,或者达到了限定的日志文件上限,就会对数据库产生较大的影响。

先来看看 SQL Server 2000 数据库日志文件的两种设定方式。


右下角可以设置日志文件的大小,上面一个选项是可以无限增大,后面一个选项是可以指定一个允许的最大值。数据库在运行过程中,这个日志文件会不断的增大,增大的速度视提供服务的压力而定。当这个文件达到预设的最大值时,任何数据库操作都会失败,会提示“无法写入日志”之类的报错信息;也可以允许这个文件无限增大,不过,当文件大到一定的程度,写入的效率会很低。笔者曾经遇到这个文件涨到 2.5 GB,在查明原因以前,整个系统莫名其妙效率降低很多,最后查到瓶颈在数据库。各种优化手段用上未果,最后发现日志是设置成无限增长的。把日志删除并把日志文件缩减后,问题解决。

因此,无论是让文件无限增长,还是设置文件最大值,都不可避免的遇到日志的删除和缩减问题。要缩减数据库日志,可以用查询分析工具 (SQL Query Analyzer) 运行如下命令:
DUMP TRANSACTION [db_name] WITH NO_LOG

然后如下图用“收缩数据库”(Shrink Database) 工具将删除后留下的空白空间收回。具体的:




然后选择“Files...”:


在“Database file”中选择日志对应的文件,一般是“[db_name]_Log”,“Shrink action”选择的第 4 项,将缩减的值设定为目前允许的最小值,然后点击“OK”即可。