Fehler erhalten: [Err] 1615 - Die vorbereitete Anweisung muss mit MySQL 5.6.30 neu vorbereitet werden

Problem / Problem: Fehler erhalten: [Err] 1615 - Prepared statement needs to be re-prepared

Ich habe eine gespeicherte Prozedur, die eine vorbereitete Anweisung und eine Ansicht enthält

DROP PROCEDURE IF EXISTS `sampleProc`;

DELIMITER ;;
CREATE DEFINER = `root`@`localhost` PROCEDURE `sampleProc`()
BEGIN

SET @select = "SELECT * FROM `viewSample` ";

  PREPARE stmt FROM @select ;
  EXECUTE stmt ;
  DEALLOCATE PREPARE stmt ;

END  ;;
DELIMITER ;

Der folgende Anruf gibt manchmal einen Fehler aus CALL sampleProc();

Mögliche Umgehung / Lösungen

Es scheint, dass die beste Lösung darin besteht, den Wert von table_definition_cache zu erhöhen, aber es scheint, dass es nicht funktioniert, da es bereits von 1400 (Standard) auf 16384 erhöht wurde. Table_open_cache wurde ebenfalls auf 32162 erhöht

Variable_name               Value
table_definition_cache      16384
table_open_cache            32162
table_open_cache_instances  4

Dies scheint ein fortlaufendes Problem zu sein

Ansichten sind mit Dynamic SQL unübersichtlich

Der früheste Fehler war, dass in vorbereiteten Anweisungen von vor 11 Jahren keine ANSICHTEN erstellt werden konnten. Es wurde ein Patch hinzugefügt, um das Problem zu beheben .

Ein anderer Fehlerbericht, Prepared-Statement, schlägt fehl, wenn MySQL-Server unter Last steht , und besagt, dass Fehler 1615 kein Fehler ist, wenn die zugrunde liegenden Tabellen ausgelastet sind. (Ja wirklich ?)

Das Erhöhen der Tabellen-Cache-Größe hat zwar einige Vorteile (siehe MySQL-Fehler beim Arbeiten mit einer MySQL-Ansicht ), funktioniert jedoch nicht immer (siehe Allgemeiner Fehler: 1615 Die vorbereitete Anweisung muss neu vorbereitet werden (Auswahl der MySQL-Ansicht) ).

ALTERNATIVEN

Vor über einem Jahr erwähnte dies jemand im MySQL-Forum (MySQL-Ansicht, vorbereitete Anweisung und vorbereitete Anweisung müssen neu vorbereitet werden) .

Jemand hatte die einfache Idee, nicht die Ansicht in der vorbereiteten Anweisung zu verwenden, sondern stattdessen die SQL der Ansicht in einer Unterabfrage . Eine andere Idee wäre , das von der Ansicht verwendete SQL zu erstellen und es in Ihrem Client-Code auszuführen .

Dies scheinen bessere Problemumgehungen zu sein, die nur die Größe des Tabellencaches erhöhen.