mysql - SQL標準UPSERT呼び出し

Question

UPSERT標準のSQL" "ステートメントを探しています。存在する場合は、挿入と更新を1回呼び出します。

実用的で効率的でクロスプラットフォームの通話を探しています。

、、、を見MERGEたことがありますが、ニーズを満たすステートメントはありません。UPSERTREPLACEINSERT .. ON DUPLICATE UPDATE

ところで、私はユニテストにMYSQLとHSQLDBを使用しています。HSQLDBには制限があり、必要なものをカバーできない可能性があることは理解していますが、HSQLDBがなくても標準的な方法を見つけることができませんでした。今のところ、MYSQLとHSQLDBだけで十分であるというステートメント。

私はしばらく探していましたが、答えを得ることができませんでした。

私のテーブル：

CREATE TABLE MY_TABLE (
  MY_KEY varchar(50) NOT NULL ,
  MY_VALUE varchar(50) DEFAULT NULL,
  TIME_STAMP bigint NOT NULL,
  PRIMARY KEY (MY_KEY)
);

何か案が？

Answer 1

Answer 2

The only solution that is supported by both MySQL and HSQLDB is to query the rows you intend to replace, and conditionally either INSERT or UPDATE. This means you have to write more application code to compensate for the differences between RDBMS implementations.

1. START TRANSACTION.
2. SELECT ... FOR UPDATE.
3. If the SELECT finds rows, then UPDATE.
4. Else, INSERT.
5. COMMIT.

MySQL doesn't support the ANSI SQL MERGE statement. It supports REPLACE and INSERT...ON DUPLICATE KEY UPDATE. See my answer to "INSERT IGNORE" vs "INSERT ... ON DUPLICATE KEY UPDATE" for more on that.

---

Re comments: Yes, another approach is to just try the INSERT and see if it succeeds. Otherwise, do an UPDATE. If you attempt the INSERT and it hits a duplicate key, it'll generate an error, which turns into an exception in some client interfaces. The disadvantage of doing this in MySQL is that it generates a new auto-increment ID even if the INSERT fails. So you end up with gaps. I know gaps in auto-increment sequence are not ordinarily something to worry about, but I helped a customer last year who had gaps of 1000-1500 in between successful inserts because of this effect, and the result was that they exhausted the range of an INT in their primary key.

As @baraky says, one could instead attempt the UPDATE first, and if that affects zero rows, then do the INSERT instead. My comment on this strategy is that UPDATEing zero rows is not an exception -- you'll have to check for "number of rows affected" after the UPDATE to know whether it "succeeded" or not.

But querying the number of rows affected returns you to the original problem: you have to use different queries in MySQL versus HSQLDB.

HSQLDB:

CALL DIAGNOSTICS(ROW_COUNT);

MySQL:

SELECT ROW_COUNT();