SO、私たちは画面に行くレポートを実行しようとしていますが、保存されているデータは変更されません。ただし、複雑なため、いくつかの (TEMPORARY*) テーブルを通過する必要があります。
レプリケートされたライブ テーブルからデータを取得します。
「適格な」レコードを取得する際の厄介な点
temp_PreCalc
ライブ データからデータを取り込み、次の (TEMPORARY*) テーブル出力を作成します。
効果的に次のようになります。
INSERT INTO temp_PostCalc (...) SELECT ... FROM temp_PreCalc live_Tab1 に参加 ... live_Tab2 に参加 ... live_Tab3 に参加 ...
レポートは「決定的な」回答ではありません。期待されるのは、単なる「スナップショット」レポートであり、画面に表示されるとすぐに古くなります。
順序や再現性の問題はありません。
したがって、理想的には、TRANSACTION ISOLATION LEVEL を READ COMMITTED に下げます...ただし、live_Tab1,2,3 は BIN_LOG STATEMENT タイプで複製されるため、できません...
ステートメントは素敵で迅速です-実行にほとんど時間がかからないため、リソースの負荷は以前よりも少なくなりました（選択と挿入を別々に行っていました）が、待機するSELECTのために（私が理解しているように）待機します結果を安全に複製できるように、live_Tab の反復可能/同期可能なロック用。実際、その待機のために時間がかかるようになりました。
応答時間のパフォーマンス上の利点を確認したいと思います!
ただし、データが (TEMPORARY*) テーブルに書き込まれてから破棄されます。
live_ テーブルの宛先はありません - ソースのみ...
- これらのテーブルは、実際には TEMPORARY TABLES ではなく、動的に作成されて破棄される InnoDB テーブルです。これは、レポートの計算に自己結合と削除が必要なためです...しかし、それらは一時的なものです
私は今、答えを見つけるためにぐるぐる回っているようです。
SUPER 特権を持っていないので、この接続セッションで BIN_LOG=0 を設定することはできません (なぜこれが必要なのですか?)
そう...
すべての temp_ "Temporary" テーブルをレプリケーションから除外するスクラッチ データベースまたはテーブル ワイルドカードがある場合... (この変更がホスト センターで行われるのを待っています)
MySQL は私に許可しますか?
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
INSERT INTO temp_PostCalc (...) SELECT ... FROM temp_PreCalc JOIN live_Tab1 ON ... JOIN live_Tab2 ON ... JOIN live_Tab3 ON ... ;
それとも私はまだ私のものを手に入れますか
「ステートメントを実行できません: BINLOG_FORMAT = STATEMENT であるため、バイナリ ログに書き込むことができず、少なくとも 1 つのテーブルが行ベースのログ記録に限定されたストレージ エンジンを使用しています...」
技術的には真実ではありませんが？「INSERT」ステートメントが表示されるという理由だけでレプリケーションが開始され、実際には宛先がレプリケーションではない場合でも、レプリケーションに適格である関連するテーブルの簡単なチェックを行うと推測しているため、私はそれを期待しています。対象....
それとも嬉しい驚きでしょうか？
私は本当に不快なソリューションを使用して直面することはできません
OUTFILE を選択 LOAD DATA INFILE
実際、それを使用することさえできないと思います-どうすれば一意のファイル名を取得できますか? どうすればそれらをクリーンアップできますか? レポートはエンド ユーザーによってオンデマンドで直接実行され、サーバーへのアクセスは MySQL インターフェイスのみです。
またはPHPクライアントを介してストリーミングし、INSERTをSELECTから分離して、MySQLがどのテーブルがレプリケーションの対象であるかについて動揺しないようにします....