問題/問題:エラーの取得:_[Err] 1615 - Prepared statement needs to be re-prepared
_
Prepared Statementとビューを含むストアドプロシージャがあります。
_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 ;
_
次の呼び出しでエラーが発生することがありますCALL sampleProc();
可能な回避策/ソリューション
最善の解決策はtable_definition_cacheの値を増やすことですが、すでに1400(デフォルト)から16384に増加しているため、機能していないようです。table_open_cacheも32162に増加しています。
_Variable_name Value
table_definition_cache 16384
table_open_cache 32162
table_open_cache_instances 4
_
これは現在進行中の問題のようです
ビューは動的SQLで処理するには面倒です
最初のバグは 11年前の準備済みステートメントでVIEWを作成できませんでした。これに対処するためにパッチが入れられました 。
別のバグレポート Prepared-Statementは、負荷がかかっているMySQL-Server で失敗し、基になるテーブルがビジーである場合、エラー1615はバグではないと述べています。 (本当に ?)
テーブルキャッシュサイズを増やすことにはいくつかのメリットがありますが(mysqlビューを操作するときの MySqlエラーを参照してください )、常に機能するとは限りません( を参照)エラー:1615準備済みステートメントを再準備する必要があります(mysqlビューを選択しています) )
1年以上前、誰かが MySQLフォーラムでこれについて言及しました(MySqlの「ビュー」、「準備されたステートメント」、および「準備されたステートメントは再準備する必要があります」) 。
誰かが プリペアドステートメントでビューを使用せず、代わりにサブクエリでビューのSQLを使用するという簡単なアイデアを思いついた 。別のアイデアは、ビューで使用されるSQLを 作成し、クライアントコードで実行することです 。
これらは、テーブルキャッシュサイズを増やすだけの回避策のようです。