0

我刚开始研究一个遗留的 PHP 应用程序，发现自己在与一种奇怪的行为作斗争。我将尝试解释场景/代码/错误：

  1. 所有查询都通过一个单例类执行，该类打开一个连接并在整个会话中保持打开状态（据我所知代码）

  2. 每次 amysql_query返回时false，都会引发异常。

  3. 许多查询执行“很好”，甚至抱怨不存在表（我的任务之一是清理混乱的剪辑器继承数据库方案，所以我正在运行代码并根据需要创建表）。创建缺失表后，查询通常运行良好。

  4. 一些查询返回1045错误：Access denied for user 'appuser'@'localhost' (using password: YES)

这是“奇怪”的行为：

  1. 我已经在我的 MySQL 安装中启用了常规日志，但是没有提到拒绝访问错误。应用程序查询似乎运行良好（我说“似乎”是因为我实际上在理解日志格式的某些部分时遇到了问题）。

  2. 在单例类中配置的用户名/密码是可以的。我可以使用 MySQL CLI 界面登录，除了许多其他查询运行良好。如果我尝试在 MySQL CLI 上使用错误的用户名/密码，则拒绝访问会正确记录在常规日志中。

  3. 抛出异常的堆栈跟踪（显然是在 PHP 中）表明异常确实来自处理查询的单例类。

  4. “拒绝”查询中似乎没有模式。它们是大SELECT查询，但仅此而已。有些有LEFT OUTER连接，有些有 24 个FROM子句。

  5. 我正在记录mysql_stat每个查询的结果，它会在工作查询和失败查询之前打印服务器状态。虽然，我不确定这个函数是否真的依赖于与 MySQL 服务器的有效凭证/会话。

那么，你们认为这里发生了什么？有什么线索吗？任何有根据的猜测？

如果有人需要更多信息/背景，我很乐意提供...... :)

4

1 回答 1

1

更详细地检查有问题SELECT的 s，我可以在它们之间找到一个公共表。你猜怎么了？实际上，它不是一个TABLE，而是一个VIEW。当我尝试使用图形工具（MySQL Workbench）SELECT从这个开始VIEW时，错误很明显并且“明显”。

当开发人员导出数据库（MySQL Dump）时，该工具只是在每个VIEW创建代码上添加了这样的一行：

/*!50013 DEFINER=`oldappuser`@`%` SQL SECURITY DEFINER */

我不知道为什么，但确实如此。由于我的本地数据库有不同的用户名/密码/方案，这成为我 4 小时头痛的根源。

为了修复它，我只是删除了旧的VIEW并重新创建了它，没有DEFINER指令。

故事的寓意：在转储数据库时注意您检查的选项并注意这些SECURITY内容，以防您在新服务器中更改用户/通行证/方案。

于 2013-04-05T17:44:09.487 回答