いつものビジネスシナリオでは、多くの時間があってもよく、増加またはライブラリの動作を変更する必要があります（対応するデータ行がすでに存在している）（データの行に対応することは存在しない）、この時間は、誰かがどんな言語だと思いません、私がチェックしますそこにこのラインには、対応するライブラリデータはありませんし、その後の結果に従って動作する、（既存のデータが変更され、データが追加されていない）、それを離れて得ることはありません。
考えることができるソリューションは良いですが、これは、追加またはプログラムの最初のチェック後に変更、次のような理由から、重大な欠点があります：
手術後の1、あなたの最初のチェックは、そのようなスレッド1とスレッド2として動作するように複数のスレッドが、この結果を照会し、図書館がビジネスを行っているならば、連続して、操作を挿入していないとき、これは、アトミックではありません唯一の制約データ、この状況は文句を言うでしょう。スレッドの安全性の問題の様々なをもたらすでしょう。おそらくあなたが思うだろう、スレッド安全性の問題を、それがまだ巣をロックすると離れて取得していない？ロックはもちろん可能ですが、高い同時実行のためのいくつかのビジネスシナリオについては、このパフォーマンスの損失、良いよりもいくつかのより多くの害。
ターゲットテーブルが何百万とデータレベルの順であれば2、操作後の最初のチェックは、この調査の費用、このクエリ結果は、必ずしもすぐに結果を返すことができない（文字列インデックスの特定の事例）あなたは比較的高い周波数、IOデータベースの負荷、またはインタフェースの応答性だけではなく、かつ複数のデータベース要求が懸念され、これを呼び出した場合のインタフェースとの間のネットワーク遅延は、それが小さなオーバーヘッドでないとき。そして、この時間のかかるお問い合わせ、セキュリティスレッドが話して拡大します。
、に置き換え
table文の構造に最初の
`student`（CREATE TABLEを
` id` BIGINT（22）の符号なしNULL NOT AUTO_INCREMENTコメント'主键自增ID'、
'student_id` BIGINT（22）NOT NULL DEFAULT '0' COMMENT '学生ID'、
' chinese_socre`小数（18 、6）NOT NULL DEFAULT '0.000000' COMMENT '语文分数'、
`math_score`小数（18,6）NOT NULL DEFAULT '0.000000' COMMENT '数学分数'、
PRIMARY KEY（` id`）BTREE、USING
UNIQUE KEY `をun_idx_stu_id （ `` student_id`）BTREEを用い
）ENGINE = InnoDBのデフォルトのCHARSET = UTF8のCOMMENT = '学生' テーブル ';
シーン：
グレード言語と数学のテストのメイクアップ（パフォーマンスデータは、すでに一部の学生が存在しますが、何かが最後に来なかったので、何らかの理由で、一部の学生が二次審査（既存のデータ）、およびいくつかであること試験終了）（メイクアップは、元のデータが存在しない彼の最初のテストである）、この時間は、構文に便利になる置き換えます
.......（2,60,61）、（3,62,63）、学生（STUDENT_ID、chinese_socre、math_score）の値（1,58,59）に交換してください。
メリット
1、単純な構文が、幅広い状況をカバーします：
生徒の第二の試験のために、この最初のデータに挿入されているが、彼の最新のスコアデータのメイクアップに更新され、元のデータを上書きします（ここでは、当面は厳しい生産環境として考慮されていない、あなたはその歴史を保持する必要があるかもしれません得点シーン）
学生の最初の検査のために、すべてのです。この時間は、それが新しいデータを挿入します
メイクアップ、今回の操作に参加する必要がない学生のために、元のデータは影響を受けません。
2、データベースは唯一のインデックスは、最終的なデータの一意性を保証するために、両方の、ビジネス上の制約を行うために使用するだけでなく、以前よりも後の最初のチェックされているため、大幅に（複数のネットワークが存在しない場合は、一意性、通信コストを呼び出して一意のインデックス、等により、効率的なデータベースクエリを確実にするために）の効率を向上させるための動作モード
注：
1、データテーブルに挿入は、主キーまたは一意のインデックスを持っている必要があります！それ以外の場合は、データがテーブルに表示され、重複につながるであろう、直接データを挿入するに置き換えます
元の表のデータが既に存在する場合は2、更新（新しいバック、オリジナルを削除するには）全体量の更新を行うことに置き換え、追加、存在しない、新しいデータで（完全がある（主キー索引に応じているか否かが判断します）勝つ、元のデータ）が保存されていません
ビジネスシナリオのアナロジー：
例えば、今、2つのシステムが、システムが出力側Aで、ドッキング、製品データの同期化が必要とされ、Bシステムは、次のことができ、受信機、与えられたデータAが完了し、全体量、およびこの時間ですこの文法を使用して、Bシステムは、構文が単純で、マルチカバーです。更新する必要が、最終的には既に存在している、または以前持っていたされ、製品情報オーバーのためのシステムを検討する必要はありません。
二、に無視挿入
.......（3,62,63）、学生（STUDENT_ID、chinese_score、math_score）値（1,58,59）、（2,60,61）に無視インサート。
シーンは、利点
1は、例えば、そして、もともと学生のデータ入力部の一部のみでした誤って中断したが、そのうちのいくつかが入力されている解決していない場合、次の構文を使用することができ、元のデータは影響を与えません（ありませんそれは、一意のインデックスの重複データ入力やエラー中断につながる）となっているが、データは新しいに挿入されますので、
2、データベースが原因でビジネスを行うの制約の一意のインデックスの使用は、両方のは、最終的なデータの一意性を確保するために、だけでなく、運転効率後の最初のチェック以前より方法が大幅に改善されている（複数の通信ネットワークの通話料金は一意で、存在しませんなど、効率的なデータベースとクエリを、保証する唯一のインデックス）
注：
1、データテーブルに挿入は、主キーまたは一意のインデックスを持っている必要があります！それ以外の場合は、テーブルに表示されたデータを複製するためにつながるれ、直接データを挿入するに無視挿入
図2に示すように、元のデータテーブルが既に（プライマリキーインデックスがか否かが判断される）が存在する場合、任意の操作がない、DOに無視存在する、追加、挿入しないインサートケース増分（元のデータが重複が存在する、ありますそれは）、元のデータの対象となります
ビジネスシナリオのアナロジー：
例えば、2つのシステムが今そこにあるドッキング、注文データの同期、受信機システムを必要とし、各新規受注データ同期の成功に基づいて、いくつかの関連の統計を行います
解決策は、時間または特定のリアルタイム同期例外の一定の期間を避けるために、夜は完全な同期を実行する時間の量であろう、この時間は、あなたがこの文法を使用することができ、システムはA、Bを考える必要はありません、Bシステムのリアルタイム同期システムを行うことですこの構文は、ケースとインサートの両方と互換性があると最後に来るための情報システムは、既にその影響に応じて行数が最終的に決定することができる、新たな収益を発生するかしないMyBatisのJavaフレームワークのいくつかの単一（組み合わせを追加することです。最後にインクリメントの主キーを返すことができます成功した挿入は、それぞれの後続のトラフィック統計計算ロジックを実行するために、これらの新しいシングルの成功のどの、決定することです）
三、重複keyupdate上に挿入
複製上.......（3,62,63）、学生（STUDENT_ID、chinese_score、math_socre）の値（1,58,59）、（2,60,61）に挿入鍵更新chinese_socre =値（chinese_score）、math_socre = math_socre。
シーンは、利点
などメイクアップとしては、メイクアップ言語だけ、ない数学のテストを。このような文法を採用することができ、更新されたカスタム（既存のデータ、つまり、メイクアップ）
1、構文は簡単ですが、広い状況をカバーします：
学生だけその言語の達成、数学の成績を更新するか、元のデータを維持するために、第二に参加している場合たとえば、検査、
学生の最初の検査のために、すべてのです。この時間は、それが新しいデータを挿入します
メイクアップ、今回の操作に参加する必要がない学生のために、元のデータは影響を受けません。
2、データベースは唯一のインデックスは、最終的なデータの一意性を保証するために、両方の、ビジネス上の制約を行うために使用するだけでなく、以前よりも後の最初のチェックされているため、大幅に（複数のネットワークが存在しない場合は、一意性、通信コストを呼び出して一意のインデックス、等により、効率的なデータベースクエリを確実にするために）の効率を向上させるための動作モード
注：
1、データテーブルに挿入は、主キーまたは一意のインデックスを持っている必要があります！それ以外の場合は、データを複製するためにつながるデータに直接この構文は、テーブルに表示されます
元のデータテーブルが既に存在する場合は2は、重複するキー更新のカスタムアクション後の更新の存在を（主キー索引が存在したか否かを判断する）、新しい不在、彼は、インサートの全体量をしたか、更新するカスタム
ビジネスシナリオのアナロジー：
例えば、今2つのドッキングシステムを持っている他はありません、商品代金のみのデータ変更が発生し、そのシステムを想定した（データ同期の製品を必要とし、上記の例では、商品のすべての属性データであり、注意差）
リアルタイムの同期プログラムを実行するシステムがシステムBにある、この時間は、あなたがこの文法を使用することができ、Bシステムは、すでにこの構文の互換性のインサート2と、発生するかしない終わりに来て、製品情報のシステムを検討する必要はありません。ケースや製品データを既存のこのような状況の出現、唯一の価格情報を更新し、更新はスペースの構文をサポートするカスタム操作を提供するために、複雑な拡張することができた後に動作も、データベースのオーバーヘッドを削減
------ ----------
免責事項：この記事は元の記事CSDNブロガー「永遠ではない」であり、BY-SAの再現著作権契約、CC 4.0に従って、元のソースのリンクと、この文を添付してください。
オリジナルリンクします。https：//blog.csdn.net/qq_18406563/article/details/80639029