Deprecated: Function set_magic_quotes_runtime()

     今天把php版本升级了一下，突然就出现了Deprecated: Function set_magic_quotes_runtime() is deprecated 错误，下面我们总结了

原因分析:

最近升级了PHP版本,新版本的PHP对set_magic_quotes_runtime()已经关闭
在PHP5.3后此特性（set_magic_quotes_runtime()）已经关闭。

而且在PHP6中已经完全移除此特性。

解决办法

你可以注释或者删除掉出错的行，或者是在set_magic_quotes_runtime()前面加@符号。

也可以在程序中如下操作

这样问题就解决了。

我用的linux系统，今天使用phpmyadmin时出现Wrong permissions on configuration file, should not be world writable!错误提示，

查资料一看，原来phpMyAdmin要在755权限下才能正常工作（777不行）。

所以解决办法也就来了：

cd到phpMyAdmin上级目录，

在我的linux系统用

用以下命令

这个问题就解决了。

phpMyAdmin 缺少 mysqli 扩展。请检查 PHP 配置 的解决方案 有需要的朋友可参考一下。

phpMyAdmin 缺少 mysqli 扩展。请检查 PHP 配置 的解决方案:
缺少 mysqli 扩展。请检查 PHP 配置。

打开你的php.ini->一般在C:WINDOWS目录下。
找到

需要开启哪个扩展，就把这一行前面的分号去掉就行，注意要重启Apache 或者IIS

解决步骤：
1.看看php的ext目录中是否有php_mysqli.dll文件
如果有，继续下面的步骤。没有的话重新装个php
2.打开php.ini，找到

把前面的分号";"去掉，改为

3.找到

把前面的分号";"去掉，改为(相对于php的安装路径的ext目录)
extension_dir = "e:phpext"
e:php为php的存放目录

4.把php.ini拷贝到c:windows下

5.把libmysql.dll复制到Windows下面的System32目录(这个很关键)

6.重新启动IIS（不是网站）

cmd下运行 iisreset　/RESTART 

如果上面方法还不行，可参考下面方法操作

第一步，输出 phpinfo() 看看 MySQL 模块是否成功装载，如果成功装载说明你见鬼了，否则看第二步,

IIS下phpinfo()无mysql模块是何原因？
原先用的php是.msi安装的，后来全部重来了一次，换成压缩包形式安装的。
又照着配置了php.ini，复制到winnt，复制libmysql.dll到system32。
之后测试成功。。。
第二步，查看 extension_dir 的设置是否正确
第三步，查看是否把 libmysql.dll 文件复制到 c:windowssystem32 下

1、没有正确安装Mysql数据库，在系统服务中Mysql相关的服务没有启动   （请查看正确安装Mysql的方法）

2、在系统的 system32（C:windowssystem32） 目录下缺少 libmysql.dll文件，解决方法是找到php目录下的libmysql.dll，并将libmysql.dll复制到C:windowssystem32目录中，然后重新启动Web服务。

3、在C:windows目录下的php.ini文件中，没有将“;extension=php_mysql.dll”中的前面一个“;”去掉，所以不能使用相应功能，解决方法是打开php.ini文件

4、Mysql目录没有读取权限，正确的目录权限如下：
administrator   完全控制
system    完全控制
user    读取加运行
其他的用户权限全部删除（也可保留，但安全性不高，建议删除），然后重启MYsql服务和Web服务。

PHP程序员最常用的两个函数莫过于require_once和include了，通过这两个函数，我们可以使用其他类库中定义的类等对象。但很多人在使用包含相同目录下的其他文件时，仅仅简单使用下面的代码进行文件引用：

include性能

当然这种方式并没有错误，只不过在效率上它比下面的方式要稍稍差些：

这种方式我们可能需要输入更多一些，但相对于前面那种需要PHP引擎去include_path 中迭代查找所有名称为'include.php’才能查找到相应对象来说，dirname(__FILE__)这种绝对路径的指定会让系统迅速定位到相应文件。

在PHP中常量__FILE__ 其实跟C#中的AppDomain.CurrentDomain.BaseDirectory非常类似，它返回的是当前代码正在执行的代码所在文件的绝对路径。而函数dirname()则返回其父文件夹路径。

另外一个更查找效率高，并且书写简单的方式是include('./include.php')，这相当于告诉系统查找当前路径下的'include.php’文件。

在大型系统中我们常常使用另外一个更好的方式，我们常常在路由文件或其他初始化文件中加入如下代码：

这相当于给系统添加了一个全局变量来指出系统根目录，当我们后面需要引用某具体路径下的文件时我们就可以使用如下代码了：

autoload与include性能比较

例如有以下四个脚本：

当执行script1.php时， include ‘include2.php’; 这行代码被执行了一次。而执行script2.php时，这行代码被执行了两次。
这里只是一个简单的例子，在实际的项目中，include2.php被include的次数可能更多。这样反复的include，是否会影响性能呢？为此我写了个脚本来测试。

当$loop值为1时，脚本耗时约0.00018906593322754秒，当$loop为1000时，脚本耗时约0.076701879501343秒。
如果我们用autoload实现呢？

在这段代码中，我定义了__autoload函数，几乎一样的脚本，当$loop为1时，耗时0.0002131462097168秒，而当$loop为1000时，耗时仅为前面代码的1/7，0.012391805648804秒。
但请注意看SimpleClass的代码，其中输出了一行字符串，如果去掉这行输出后再比较，会是什么样的结果呢？
在$loop同为1000的情况下，前者耗时0.057836055755615秒，而使用了autoload后，仅仅0.00199294090271秒！效率相差近30倍！
从上面的测试可以看出，当文件仅仅被include一次，autoload会消耗稍微多一点的时间，但如果在文件被反复include的情况下，使用autoload则能大大提高系统性能。
至于是否要使用autoload来解放程序员，这就仁者见仁，智者见智了。在我看来，条件允许的前提下，牺牲这一点性能（某些情况下，甚至可能是提升性能）更为便捷的开发，是值得的。

include()和require()性能

对include()来说，在 include()执行时文件每次都要进行读取和评估；

而对于require()来说，文件只处理一次（实际上，文件内容替换了require()语句）。

这就意味着如果有包含这些指令之一的代码和可能执行多次的代码，则使用require()效率比较高。

另一方面，如果每次执行代码时相读取不同的文件，或者有通过一组文件叠代的循环，就使用include(),

因为可以给想要包括的文件名设置一个变量，当参数为include()时使用这个变量。

在我们使用php缓存技术时会出现提示PHP class x has no unserializer 下面我们来介绍一下关于这个问题的办法。

PHP已经出到了5.3.8稳定版本，于是乎准备将公司生产服务器上的PHP从5.2.17升级到5.3.8，在测试服务器上调试的时候却发现了一个诡异的问题：

双PHP环境装好后，原先能在5.2.17正常运行的代码报错了，提示PHP class x has no unserializer，而同一套代码在同服务器上使用5.3.8则没有任何问题.Google一下了发现没有什么有用的信息，看来我是遇到冷门问题了，于是开始逐步debug检查,发现报错的地方位于使用memcache取数据的部分，在取出缓存在memcache中的数据时提示我的类没有反序列化功能，而此行代码运行在5.3.8的时候却没有任何问题. 

鉴于唯一的线索是这个反序列化的提示了，搜索了一下php官方相关序列化的信息，首先找到了序列化接口Serializable的介绍，在这里我注意到该接口有一个unserializ方法，这个是用于反序列化类时调用的借口. 同时，php的memcache扩展在把php数据对象存到memcache时是会将其序列化的，难道是我自己使用的对象没有实现Serializable接口的问题？追查了一下代码发现我存在memcache中的类是继承于Array_Object类,于是乎跑到官方Array_Object的介绍页面一看，果然如此，

如上图，Array_Object从5.3.0开始就实现了Serializable接口，而5.2是没有实现的。到这里，这个问题的原因也就明朗了,分析如下：
程序在两个版本的PHP下运行却使用同一个memcache缓存池，我先测试的是5.3.8版本，那么存进去的是PHP5.3的Array_Object对象，该对象在5.3下面可以正常序列化和反序列化，后来我又去访问了运行在PHP5.2下面的程序，这是在memcache中已经有了缓存对象，所以5.2读出来的是5.3中序列化的Array_Object对象，而在5.2中Array_Object是没有实现Serializable接口的，那么在反序列化时就会出现错误，也是就是提示PHP class x has no unserializer的原因。

解决这个问题的方法很简单，给每个程序使用不同的缓存池，避免产生数据污染和版本兼容问题。