执行存储过程在生产服务器上不起作用，权限丢失？答案

【问题标题】：Executing stored procedure won't work on production server, permissions missing?执行存储过程在生产服务器上不起作用，权限丢失？
【发布时间】：2012-10-31 10:15:59
【问题描述】：

我在使用 PHP 运行的存储过程时遇到了一些问题，而且我已经连续四天摸不着头脑了（和技术支持人员）。也许您可以帮助阐明这一点。

简而言之：我在本地计算机 (spcTest) 上定义了一个存储过程。 PHP 页面可以毫无问题地运行它，因此它返回一个单行记录集。当我在生产服务器上重新创建过程时，PHP 页面没有得到相同的结果。

我很确定这是一个权限问题，但我很难确定它。我可以通过 phpMyAdmin 访问生产服务器，这就是我运行所有创建脚本的地方。我还看到存储过程 spcTest 出现在生产环境中（使用SELECT * FROM ROUTINES），我也可以成功更新它。

当我运行以下命令时：

SHOW GRANTS FOR triis@localhost;

这些是我分别在开发服务器和生产服务器上得到的结果：

~~~=== 在开发服务器上 ===~~~

GRANT ALL PRIVILEGES ON *.* TO 'triis'@'localhost' IDENTIFIED BY PASSWORD '*F05[~~(snip)~~]72'

GRANT ALL PRIVILEGES ON `tri_is`.* TO 'triis'@'localhost'

~~~=== 在生产服务器上 ===~~~

GRANT USAGE ON *.* TO 'triis'@'localhost' IDENTIFIED BY PASSWORD '*F05[~~(snip)~~]72'

GRANT ALL PRIVILEGES ON `tri_is`.* TO 'triis'@'localhost'

注意GRANT USAGE-line 的区别，在开发端不存在。我已经阅读了 mySQL 文档，但可能错过了答案……简而言之，我的问题是：生产服务器上的权限是否如上所示，是否允许执行任何存储过程，包括 spcTest？

在我看来，triis 用户似乎不应该有执行权限，因为没有特别提到 EXECUTE-attribute。但是看到SHOW GRANTS-command 在生产和开发服务器上返回惊人相似的结果（尤其是双方的ALL PRIVILEGES）我有点困惑为什么PHP代码只能在开发端工作。

如果这被证明是生产中的权限问题，像 GRANT CREATE ROUTINE, EXECUTE ON * TO triis@'localhost' 这样的东西会帮助授予此存储过程和任何未来存储过程的执行权限吗？

感谢您的宝贵时间！ :)

【问题讨论】：

如果你的SP是在tri_is数据库中定义的，你的用户拥有所有权限，你当然应该可以执行。
所以所有权限都包括执行？我想我在某处读到过，您必须明确授予执行存储过程的访问权限（在本例中为“triis”），即使“triis”是创建它的用户。
The ALL or ALL PRIVILEGES privilege specifier is shorthand. It stands for “all privileges available at a given privilege level” (except GRANT OPTION). For example, granting ALL at the global or table level grants all global privileges or all table-level privileges.。您在数据库级别有ALL：Table or routine privileges also can be specified at the database level, in which case they apply to all tables or routines in the database.
感谢@eggyal 让我远离权限。我创建了一个非常简单的脚本，它使用与我的程序相同的构建块，并逐步跟踪它。我发现是这样的：在我的 SP 中的 UPDATE-statement 中，提供了一个表名作为 p_productGroup，当单独运行 UPDATE-statement 时，我收到一条错误消息，说那里找不到这样的表。显然，表名区分大小写，但 SP 没有返回错误（只是失败，但仍然运行正常，返回 0 行）。
注意区分大小写不仅仅是反引号：存储 MySQL 数据文件的文件系统是 very relevant。另外，请注意SHOW WARNINGS; 可能有助于追踪此问题...

标签： mysql stored-procedures permissions

【解决方案1】：

这不是我最初认为的权限问题，而是在存储过程 (SP) 中运行的 UPDATE-statement 中发生的错误。

该错误源于表名（正在更新）区分大小写，以及开发和生产环境的大小写不匹配。存储过程在phpMyAdmin中运行时并没有直接报错，而且我没有资源在生产服务器上的mySQL shell中运行它来进一步调查。在 PHP 中运行 SP 进行诊断并没有帮助，虽然似乎拥有在两种环境中运行 SPs 的完全权限，但仍然只能在开发方面获得结果，这让我感到困惑。

每日一课：虽然反引号很难打字（至少在冰岛语键盘上是这样），但最好一开始就将它们包括在内。另一种选择是不在您的表名或过程中使用驼峰式大小写。通过 phpMyAdmin 生成 mySQL-scripts 将添加刻度并且区分大小写。仅在您的一个环境中运行生成的脚本可能会导致仍在开发中的脚本出现问题（而不是生成的批处理的一部分）。

【讨论】：