我已经重写了我的网站 php 代码并添加了 MySQL 存储过程。
在我的本地版本中，一切正常，但在我将网站上传到托管服务器后，我不断收到致命错误“需要重新准备准备好的声明”。
有时页面加载，有时加载失败，我看到此错误。那是什么？
【问题讨论】：
【讨论】：
/etc/my.cnf 文件（在[mysqld] 部分下）添加table_definition_cache=5000 并重新启动mysqld 时，错误消失了。请注意，my.cnf 对您而言可能位于不同的位置。
table_definition_cache 以大于或等于 @ 987654332@).
我的解决方案是创建这样的例程：
DELIMITER $$
--
-- Procedimientos
--
DROP PROCEDURE IF EXISTS `dch_content_class_content`$$
CREATE DEFINER=`renuecod`@`localhost` PROCEDURE `dch_content_class_content`(IN $classId INTEGER)
BEGIN
-- vw_content_class_contents is a VIEW (UNIONS)
select * from vw_content_class_contents;
END$$
我希望这对某人有所帮助
【讨论】：
我在共享托管环境中的 Ruby on Rails 中遇到了同样的错误。它可能不是最安全的解决方案，但禁用准备好的语句对我来说消除了错误消息。
这可以通过将“prepared_statements: false”设置添加到您的 database.yml 文件来完成：
production:
prepared_statements: false
当您无法控制 MySQL 服务器上的配置设置时，这似乎是一个合理的解决方案。
【讨论】：
@docwhat's 的答案看起来不错，但在共享托管服务器上，并非所有人都可以触摸table_open_cache 或table_definition_cache 选项。
由于此错误与预准备语句有关，因此我尝试通过提供以下选项来“模拟”使用 PDO 的语句：
$dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass, [
PDO::ATTR_EMULATE_PREPARES => true
]);
注意：实际上这是在一个 Laravel 5.6 项目中，我在config/database.php 中添加了选项：
'connections' => [
'mysql' => [
'driver' => 'mysql',
'host' => env('DB_HOST', '127.0.0.1'),
'port' => env('DB_PORT', '3306'),
'database' => env('DB_DATABASE', 'forge'),
'username' => env('DB_USERNAME', 'forge'),
'password' => env('DB_PASSWORD', ''),
'unix_socket' => env('DB_SOCKET', ''),
'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',
'prefix' => '',
'strict' => true,
'engine' => null,
'options' => [
PDO::ATTR_EMULATE_PREPARES => true,
],
],
(...)
],
我没有测试过模拟准备好的语句对加载我的网站的持续时间的影响，但它可以解决我得到的错误SQLSTATE[HY000]: General error: 1615 Prepared statement needs to be re-prepared。
更新性能：仿真版本似乎稍微快（32.7±1.4ms 仿真，35.0±2.3ms 正常，n=10，p 值=0.027 对于双尾学生 T 检验）。
【讨论】：
table_definition_cache 是这里最合适的解决方案。但是当我阅读您的链接时，我开始怀疑。实际上我仍然面临这个问题，我观察到这发生在服务器 php 7.0 而不是 php 5.6 上（这是特定于我的设置）
table_definition_cache 更可靠。
问题：'准备好的语句需要重新准备'
此问题通常发生在使用任何计算机语言（如 Java）或从后端调用过程调用过程时。
解决方案：通过使用（执行）下面的脚本来增加缓存的大小。
脚本：设置全局 table_definition_cache = 4000;
【讨论】：
对于那些使用共享主机并且不想冒险使用 sql 注入的人来说，这是一种解决方法。根据这篇文章： Laravel Fluent Query Builder Join with subquery 您可以将视图的定义存储在函数中
private function myView(){
return DB::raw('(**definition of the view**) my_view_name)');
}
然后像这样使用它：
public function scopeMyTable(Builder $query)
{
return $query->join($this->myView(),'my_view_name.id','=','some_table.id');
}
这是一种 laravel 方法，但我确信它可以在大多数情况下应用，并且不需要大量的代码重构或架构更改。此外，它相对安全，因为您的报表保持准备就绪
【讨论】：
简而言之：不要在准备好的语句中使用 VIEWS。
这似乎是一个持续存在的问题
动态 SQL 处理视图很混乱
另一个错误报告Prepared-Statement fails when MySQL-Server under load 指出，当基础表繁忙时，错误 1615 不是错误。 （真的吗？）
虽然增加表缓存大小有一些好处（请参阅MySql error when working with a mysql view), it does not always work (See General error: 1615 Prepared statement needs to be re-prepared (selecting mysql view)）
替代方案 一年多前，有人在MySQL Forum (MySql “view”, “prepared statement” and “Prepared statement needs to be re-prepared”) 中提到了这一点。
有人想出了the simple idea of not using the view in the prepared statement but using the SQL of view in a subquery instead。另一个想法是create the SQL used by the view and execute it in your client code。
这些似乎是更好的解决方法，只是增加了表缓存大小。
【讨论】：
冲洗表；数据库上的命令为我解决了，我使用的是教义 orm。
【讨论】：
首先获得mysql shell的访问权限：
mysql
检查table_definition_cache的值：
show global variables like '%table_definition_cache%';
可能是 400 或 1400。
放大：
set global table_definition_cache = 4000;
一切顺利！
【讨论】：
这个错误是由一个大的group_concat_max_len 语句引起的
SET SESSION group_concat_max_len = 1000000000000000000;
删除它，错误消失了
【讨论】：
这样做：
SET GLOBAL table_definition_cache = 4096;
SET GLOBAL table_open_cache = 4096;
4096 可以小一点，所以设置为大一点。但是要确保两个值是一样的。
【讨论】：
好的，我们被困在笔记本电脑上，不允许 Tableau 从 MariaDB 10.3.31 数据库的视图中更新或检索数据。我们做了通常的谷歌和堆栈溢出，很多解决方案都行不通。但是，我们有另一台笔记本电脑可以连接并运行良好。因此，在多次挠头之后，灵光乍现的时刻到来了。 有问题的笔记本电脑同时安装了 V5.3.14 和 V8.0.26 ODBC 连接器。我们删除了 V8.0.26 ODBC 连接器和 Bang，所有视图问题都消失了。 希望有人觉得这个解决方案有用。
【讨论】：
我尝试运行一个正在连接视图和表的 UPDATE 查询，但也遇到了同样的错误。由于没有用户输入，我决定运行 DB::unprepared 来解决问题。
您可以在Laravel Documentation 中了解更多信息。
【讨论】：