Question

每次尝试将中等大小的JSON对象同步到数据库时，我都遇到过这个问题，因此我们可以对其进行一些报告。通过研究导致它的原因，我在这个问题上遇到了这些联系。

http://blog.corrlabs.com/2013/04/mysql-prepared-statement-needs-to-be-re.html http://bugs.mysql.com/bug.php?id=42041

两者似乎都指向了table_definition_cache的方向。但是，这就是说问题是由于服务器上同时发生了mysqldump。我可以向你保证，事实并非如此。此外，我将查询精简到一次只插入一个对象。

public function fire($job, $data) 
{
    foreach (unserialize($data['message']) as $org) 
    {
        // Ignore ID 33421 this will time out.
        // It contains all users in the system.
        if($org->id != 33421) {
            $organization = new Organization();
            $organization->orgsync_id = $org->id;
            $organization->short_name = $org->short_name;
            $organization->long_name = $org->long_name;
            $organization->category = $org->category->name;
            $organization->save();

            $org_groups = $this->getGroupsInOrganization($org->id);
            if (!is_int($org_groups))
            {
                foreach ($org_groups as $group)
                {
                    foreach($group->account_ids as $account_id)
                    {
                        $student = Student::where('orgsync_id', '=', $account_id)->first();
                        if (is_object($student))
                        {
                            $student->organizations()->attach($organization->id, array('is_officer' => ($group->name == 'Officers')));
                        }
                    }
                }
            }
        }
    }

    $job->delete();
}

这是抛出错误时运行的代码。通常以。的形式出现。

SQLSTATE[HY000]: General error: 1615 Prepared statement needs to be re-prepared (SQL: insert into `organization_student` (`is_officer`, `organization_id`, `student_id`) values (0, 284, 26))

然后重复3次此错误。

SQLSTATE[HY000]: General error: 1615 Prepared statement needs to be re-prepared (SQL: insert into `organizations` (`orgsync_id`, `short_name`, `long_name`, `category`, `updated_at`, `created_at`) values (24291, SA, Society of American, Professional, 2014-09-15 16:26:01, 2014-09-15 16:26:01))

如果有人能指出我正确的方向，我将非常感激。我对实际触发错误的内容更加好奇，然后查找此特定问题的原因。在使用ORM时，在laravel应用程序中似乎也有些常见。

Answer 1

虽然mysqldump是常见的原因，但它不是唯一的原因。

在我的案例中，运行工匠：在任何数据库上迁移也会为同一服务器上的不同数据库触发此错误。

http://bugs.mysql.com/bug.php?id=42041 提到将在mysqldump中调用的表锁/刷新，因此值得检查是否有同时发生的迁移，锁定或刷新。

未能尝试将准备切换为模拟。

'options'   => [
            \PDO::ATTR_EMULATE_PREPARES => true
        ]

Answer 2

当mysqldump正在进行时会发生此错误。哪个数据库转储正在进行并不重要。等待转储完成，此错误将消失。

问题在于转储的表定义会导致此错误。

是的，我尝试更改这些mysql设置，但它仍然会发生（大多数时候在晚上运行繁重的mysql备份/转储时）..

table_open_cache 128 =＆gt; 16384

table_definition_cache 1024 =＆gt; 16384

Answer 3

我遇到了类似的问题。在我的情况下，问题似乎是由使用本身使用其他视图的视图引起的，最终效果可能是需要几个毫秒来处理。这特别烦人，因为有时会发生错误，有时不会。我通过在存储过程中创建临时表而不是依赖视图来编程绕过它。运行数据库的服务器使用 MariaDb 版本报告。 10.2.35

一般错误：1615准备好的陈述需要重新准备

3 个答案: