明明关了mysql数据库了 但是为什么php探针还是显示mysql数据库支持？

主要问题就是你的系统PATH设置有问题，系统找不到php5的安装路径，所以使用的是默认路径，当然就找不到dll文件了，你按照下面这篇文章的调整一下吧。 转载自IT博客园原文地址: 按照我前篇文章Apache+php+mysql安装图解安装完成后。重启Apache时提示无法正确加载php_mysql.dll。google了一下，网上有不少的文章写这个，即提示：PHP startup: Unable to load dynamic library './php_mysql.dll 找不到指定的模块。:D:\php \php-5.0.5-Win32\ext\php_mysql.dll。明明php_mysql.dll就摆在extension_dir (= D:/php/php-5.0.5-Win32/ext)下的嘛，在环境变量里按图示设置的，没有错呀！怪了！有人说copy libmysql.dll到 ％windir％\system32下就可以解决问题，试了下，再重启，还是没有用喔。晕死掉了。 php被我放在D盘，还是设置时还要加上什么目录什么的。还是环境变量没有设对？！%ProgramFiles%到D:\下，导致一些要依赖于其他dll才能工作的扩展无法正常加载这些dll，出现加载扩展出错，以刚才的php_mysql.dll为例，php_mysql依赖libmysql.dll，由于给PHP挪窝了，而又没有把新的D:\PHP加到%PATH%中去，所以没法找到这个libmysql.dll，才会出错。所以为了能够使用这些mysql的扩展，除了要正确地配置extension_dir外，还得保证系统能够这些扩展所依赖的dll，解决的办法有两个： 1 将这些依赖的dll拷贝到％windir％\system32下 2 或者将PHP的安装目录添加到%PATH%中。 以上方面都不行时。我是用把PHP目录下的所有DLL复制到windir%\system32下再试了下，还是不行再把。php_mysql.dll 复制到windir%\system32下，重启Apache，搞定! 总结如下： 1、extension_dir要设置正确。 2、把所依赖的dll拷贝到%windir%\system32 3、或者将PHP的安装目录添加到%path%中. 还是不行，就按我上面的方法就是把那些。DLL 都复制到windir%\system32目录下。应该是把php_mysql.dll和libmysql.dll就可以搞定了。其它的方法类似。就是把他本身的DLL和所依赖的DLL都COPY到windir%\system32目录中就行。重启下就知道了。 够简单的. 到底哪些扩展依赖哪些dll呢？请看下面的列表： php_curl.dll CURL, Client URL library functions Requires: libeay32.dll, ssleay32.dll (bundled) php_domxml.dll DOM XML functions PHP = 4.2.0 requires: libxml2.dll (bundled) PHP = 4.3.0 requires: iconv.dll (bundled) php_fdf.dll FDF: Forms Data Format functions. Requires: fdftk.dll gnu_gettext.dll (bundled), PHP = 4.2.3 requires libintl-1.dll, php_iconv.dll ICONV characterset conversion Requires: iconv-1.3.dll php_ingres.dll Ingres II functions Requires: Ingres II libraries php_interbase.dll InterBase functions Requires: gds32.dll (bundled) php_java.dll Java functions PHP = 4.0.6 requires: jvm.dll (bundled) php_ldap.dll LDAP functions PHP = 4.2.0 requires libsasl.dll(bundled), PHP = 4.3.0 requires libeay32.dll,ssleay32.dll (bundled) php_mcrypt.dll Mcrypt Encryption functions Requires: libmcrypt.dll php_mhash.dll Mhash functions PHP = 4.3.0 requires: libmhash.dll (bundled) php_mcrypt.dll Mcrypt Encryption functions Requires: libmcrypt.dll php_mhash.dll Mhash functions PHP = 4.3.0 requires: libmhash.dll (bundled) php_msql.dll mSQL functions Requires: msql.dll (bundled) php_mssql.dll MSSQL functions Requires: ntwdblib.dll (bundled) php_mysql.dll MySQL functions PHP = 5.0.0, requires libmysql.dll (bundled) php_mysqli.dll MySQLi functions PHP = 5.0.0, requires libmysqli.dll (bundled) php_oci8.dll Oracle 8 functions Requires: Oracle 8.1+ client libraries php_openssl.dll OpenSSL functions Requires: libeay32.dll (bundled) php_oracle.dll Oracle functions Requires: Oracle 7 client libraries php_sybase_ct.dll Sybase functions Requires: Sybase client libraries php_xmlrpc.dll XML-RPC functions PHP = 4.2.1 requires: iconv.dll (bundled) php_xslt.dll XSLT functions PHP = 4.2.0 requires sablot.dll, expat.dll (bundled). PHP = 4.2.1 requires sablot.dll, expat.dll, iconv.dll (bundled).

参考资料：

查看MySQL数据库的死锁日志

1. 使用终端或命令提示符登录到MySQL，输入命令：mysql -h xxxx.xxx.xxx -P 3306 -u username -p 解释：xxxx.xxx.xxx是数据库IP地址，username是数据库用户名，输入命令后，会让你输入username对应的密码，就可以登录了

2. 如何查看MySQL数据库的死锁信息 在MySQL客户端下输入命令： show engine innodb status \G

3. 如何定位MySQL数据库的死锁信息 在打印出来的信息中找到“LATEST DETECTED DEADLOCK”一节内容，看图中红线

4. 如何分析日志，定位死锁原因 看3里面的图，紫色划线部分 分析： 事务1，等待 RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`，这个位置的X锁 事务2，持有 RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`这个地方的S锁 事务2，等待这个地方的X锁 理论上这个事务2是可以提交的不会，死锁，但是这个事务日志只打印最后一部分死锁，信息，这里面隐含的条件是，事务1也持有 RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`这个地方的S锁，这样，事务2不能加X锁，同时事务1也不能加X锁，产生死锁。

方法1：利用 metadata_locks 视图

此方法仅适用于 MySQL 5.7 以上版本，该版本 performance_schema 新增了 metadata_locks，如果上锁前启用了元数据锁的探针（默认是未启用的），可以比较容易的定位全局锁会话。

方法2：利用 events_statements_history 视图此方法适用于 MySQL 5.6 以上版本，启用 performance_schema.eventsstatements_history（5.6 默认未启用，5.7 默认启用），该表会 SQL 历史记录执行，如果请求太多，会自动清理早期的信息，有可能将上锁会话的信息清理掉。

方法3：利用 gdb 工具如果上述两种都用不了或者没来得及启用，可以尝试第三种方法。利用 gdb 找到所有线程信息，查看每个线程中持有全局锁对象，输出对应的会话 ID，为了便于快速定位，我写成了脚本形式。也可以使用 gdb 交互模式，但 attach mysql 进程后 mysql 会完全 hang 住，读请求也会受到影响，不建议使用交互模式。

方法4：show processlist

如果备份程序使用的特定用户执行备份，如果是 root 用户备份，那 time 值越大的是持锁会话的概率越大，如果业务也用 root 访问，重点是 state 和 info 为空的，这里有个小技巧可以快速筛选，筛选后尝试 kill 对应 ID，再观察是否还有 wait global read lock 状态的会话。

方法5：重启试试！

---