#### 13.2.6.2 INSERT ... ON DUPLICATE KEY UPDATE Statement

 If you specify an `ON DUPLICATE KEY UPDATE` clause and a row to be inserted would cause a duplicate value in a `UNIQUE` index or `PRIMARY KEY`, an [`UPDATE`](update.html) of the old row occurs. For example, if column `a` is declared as `UNIQUE` and contains the value `1`, the following two statements have similar effect:

```
INSERT INTO t1 (a,b,c) VALUES (1,2,3)
  ON DUPLICATE KEY UPDATE c=c+1;

UPDATE t1 SET c=c+1 WHERE a=1;
```

 The effects are not quite identical: For an `InnoDB` table where `a` is an auto-increment column, the `INSERT` statement increases the auto-increment value but the `UPDATE` does not.

 If column `b` is also unique, the [`INSERT`](insert.html) is equivalent to this [`UPDATE`](update.html) statement instead:

```
UPDATE t1 SET c=c+1 WHERE a=1 OR b=2 LIMIT 1;
```

 If `a=1 OR b=2` matches several rows, only *one* row is updated. In general, you should try to avoid using an `ON DUPLICATE KEY UPDATE` clause on tables with multiple unique indexes.

 With `ON DUPLICATE KEY UPDATE`, the affected-rows value per row is 1 if the row is inserted as a new row, 2 if an existing row is updated, and 0 if an existing row is set to its current values. If you specify the `CLIENT_FOUND_ROWS` flag to the [`mysql_real_connect()`](https://dev.mysql.com/doc/c-api/8.0/en/mysql-real-connect.html) C API function when connecting to [**mysqld**](mysqld.html), the affected-rows value is 1 (not 0) if an existing row is set to its current values.

 If a table contains an `AUTO_INCREMENT` column and [`INSERT ... ON DUPLICATE KEY UPDATE`](insert-on-duplicate.html) inserts or updates a row, the [`LAST_INSERT_ID()`](information-functions.html#function_last-insert-id) function returns the `AUTO_INCREMENT` value.

 The `ON DUPLICATE KEY UPDATE` clause can contain multiple column assignments, separated by commas.

 In assignment value expressions in the `ON DUPLICATE KEY UPDATE` clause, you can use the [`VALUES(*`col_name`*)`](miscellaneous-functions.html#function_values) function to refer to column values from the [`INSERT`](insert.html) portion of the [`INSERT ... ON DUPLICATE KEY UPDATE`](insert-on-duplicate.html) statement. In other words, [`VALUES(*`col_name`*)`](miscellaneous-functions.html#function_values) in the `ON DUPLICATE KEY UPDATE` clause refers to the value of *`col_name`* that would be inserted, had no duplicate-key conflict occurred. This function is especially useful in multiple-row inserts. The [`VALUES()`](miscellaneous-functions.html#function_values) function is meaningful only in the `ON DUPLICATE KEY UPDATE` clause or [`INSERT`](insert.html) statements and returns `NULL` otherwise. Example:

```
INSERT INTO t1 (a,b,c) VALUES (1,2,3),(4,5,6)
  ON DUPLICATE KEY UPDATE c=VALUES(a)+VALUES(b);
```

 That statement is identical to the following two statements:

```
INSERT INTO t1 (a,b,c) VALUES (1,2,3)
  ON DUPLICATE KEY UPDATE c=3;
INSERT INTO t1 (a,b,c) VALUES (4,5,6)
  ON DUPLICATE KEY UPDATE c=9;
```

Note

 The use of [`VALUES()`](miscellaneous-functions.html#function_values) to refer to the new row and columns is deprecated beginning with MySQL 8.0.20, and is subject to removal in a future version of MySQL. Instead, use row and column aliases, as described in the next few paragraphs of this section.

 Beginning with MySQL 8.0.19, it is possible to use an alias for the row, with, optionally, one or more of its columns to be inserted, following the `VALUES` or `SET` clause, and preceded by the `AS` keyword. Using the row alias `new`, the statement shown previously using `VALUES()` to access the new column values can be written in the form shown here:

```
INSERT INTO t1 (a,b,c) VALUES (1,2,3),(4,5,6) AS new
  ON DUPLICATE KEY UPDATE c = new.a+new.b;
```

 If, in addition, you use the column aliases `m`, `n`, and `p`, you can omit the row alias in the assignment clause and write the same statement like this:

```
INSERT INTO t1 (a,b,c) VALUES (1,2,3),(4,5,6) AS new(m,n,p)
  ON DUPLICATE KEY UPDATE c = m+n;
```

 When using column aliases in this fashion, you must still use a row alias following the `VALUES` clause, even if you do not make direct use of it in the assignment clause.

 Beginning with MySQL 8.0.20, an `INSERT ... SELECT ... ON DUPLICATE KEY UPDATE` statement that uses `VALUES()` in the `UPDATE` clause, like this one, throws a warning:

```
INSERT INTO t1
  SELECT c, c+d FROM t2
  ON DUPLICATE KEY UPDATE b = VALUES(b);
```

 You can eliminate such warnings by using a subquery instead, like this:

```
INSERT INTO t1
  SELECT * FROM (SELECT c, c+d AS e FROM t2) AS dt
  ON DUPLICATE KEY UPDATE b = e;
```

 You can also use row and column aliases with a `SET` clause, as mentioned previously. Employing `SET` instead of `VALUES` in the two `INSERT ... ON DUPLICATE KEY UPDATE` statements just shown can be done as shown here:

```
INSERT INTO t1 SET a=1,b=2,c=3 AS new
  ON DUPLICATE KEY UPDATE c = new.a+new.b;

INSERT INTO t1 SET a=1,b=2,c=3 AS new(m,n,p)
  ON DUPLICATE KEY UPDATE c = m+n;
```

 The row alias must not be the same as the name of the table. If column aliases are not used, or if they are the same as the column names, they must be distinguished using the row alias in the `ON DUPLICATE KEY UPDATE` clause. Column aliases must be unique with regard to the row alias to which they apply (that is, no column aliases referring to columns of the same row may be the same).

 For [`INSERT ... SELECT`](insert-on-duplicate.html) statements, these rules apply regarding acceptable forms of `SELECT` query expressions that you can refer to in an `ON DUPLICATE KEY UPDATE` clause:

* References to columns from queries on a single table, which may be a derived table.

* References to columns from queries on a join over multiple tables.

* References to columns from `DISTINCT` queries.

* References to columns in other tables, as long as the [`SELECT`](select.html) does not use `GROUP BY`. One side effect is that you must qualify references to nonunique column names.

 References to columns from a [`UNION`](union.html) are not supported. To work around this restriction, rewrite the [`UNION`](union.html) as a derived table so that its rows can be treated as a single-table result set. For example, this statement produces an error:

```
INSERT INTO t1 (a, b)
  SELECT c, d FROM t2
  UNION
  SELECT e, f FROM t3
ON DUPLICATE KEY UPDATE b = b + c;
```

 Instead, use an equivalent statement that rewrites the [`UNION`](union.html) as a derived table:

```
INSERT INTO t1 (a, b)
SELECT * FROM
  (SELECT c, d FROM t2
   UNION
   SELECT e, f FROM t3) AS dt
ON DUPLICATE KEY UPDATE b = b + c;
```

 The technique of rewriting a query as a derived table also enables references to columns from `GROUP BY` queries.

 Because the results of [`INSERT ... SELECT`](insert-select.html) statements depend on the ordering of rows from the [`SELECT`](select.html) and this order cannot always be guaranteed, it is possible when logging [`INSERT ... SELECT ON DUPLICATE KEY UPDATE`](insert-on-duplicate.html) statements for the source and the replica to diverge. Thus, [`INSERT ... SELECT ON DUPLICATE KEY UPDATE`](insert-on-duplicate.html) statements are flagged as unsafe for statement-based replication. Such statements produce a warning in the error log when using statement-based mode and are written to the binary log using the row-based format when using `MIXED` mode. An [`INSERT ... ON DUPLICATE KEY UPDATE`](insert-on-duplicate.html) statement against a table having more than one unique or primary key is also marked as unsafe. (Bug #11765650, Bug #58637)

 See also [Section 17.2.1.1, “Advantages and Disadvantages of Statement-Based and Row-Based Replication”](replication-sbr-rbr.html).

