我刚刚开始研究遗留的PHP应用程序，发现自己正在与一种奇怪的行为作斗争。我将尝试解释场景/代码/错误：
所有查询都是通过打开的单例类执行的 一个连接并保持它为整个会话打开（就我而言 可以理解代码）
每次mysql_query返回false时，都会抛出异常。
许多查询执行“很好”，甚至抱怨不存在的表（我的任务之一是清理凌乱的剪辑器继承的数据库方案，所以我正在运行代码并创建表因为他们是需要的）。创建缺失的表后，查询通常运行良好。
有些查询返回1045错误：Access denied for user 'appuser'@'localhost' (using password: YES)
这是“怪异”的行为：
我在MySQL安装中启用了常规日志，但是没有提到访问被拒绝错误。应用程序查询似乎运行正常（我说“似乎”因为我实际上在理解日志格式的某些部分时遇到了问题）。
单例类中配置的用户名/密码正常。我可以使用MySQL CLI界面登录，除了许多其他查询运行正常。如果我尝试在MySQL CLI上使用错误的用户名/密码，则会在通用日志中正确记录拒绝访问。
抛出异常的堆栈跟踪（显然在PHP中）显示异常确实来自处理查询的单例类。
“被拒绝”查询中似乎没有模式。它们是大SELECT个查询，但仅此而已。有些人有LEFT OUTER个加入，有些人有24 FROM个条款。
我在每个查询中都记录了mysql_stat结果，并在处理查询和失败查询之前打印服务器状态。虽然，我不确定这个功能是否真的取决于与MySQL服务器的有效凭证/会话。
那么，你们认为这是怎么回事？任何线索？任何有根据的猜测？
如果有人需要更多信息/背景，我很乐意提供......：）
答案 0 :(得分：1)
详细检查有问题的SELECT，我可以在所有这些之间找到一个共同的表格。你猜怎么着？实际上，它不是TABLE，而是VIEW。当我使用图形工具（MySQL Workbench）从SELECT尝试VIEW时，错误很明显且“显而易见”。
当开发人员导出数据库（MySQL Dump）时，该工具只在每个VIEW创建代码上添加了这样的一行：
/*!50013 DEFINER=`oldappuser`@`%` SQL SECURITY DEFINER */
我不知道为什么，但确实如此。由于我的本地数据库有不同的用户名/密码/方案，这成了我长达4小时头痛的源头。
为了解决这个问题，我刚刚删除旧VIEW并重新创建它，没有DEFINER指令。
故事的道德：注意在转储数据库时检查的选项，并注意这些SECURITY内容，以防您在新服务器中更改用户/密码/方案。