# `UPDATE` a Row from a Table with Non-Clustered Index for Primary Key

![`smart`](NonClusteredPrimaryKeyTableUPDATE01_aa_002_20230905.png)

```7
tidb> DESC t_nonclustered;
+-------+-------------+------+------+---------+-------+
| Field | Type        | Null | Key  | Default | Extra |
+-------+-------------+------+------+---------+-------+
| id    | int(11)     | NO   | PRI  | NULL    |       |
| name  | varchar(20) | YES  |      | NULL    |       |
| tel   | varchar(16) | YES  |      | NULL    |       |
+-------+-------------+------+------+---------+-------+

tidb> SELECT TABLE_NAME, TIDB_PK_TYPE FROM information_schema.tables 
  WHERE table_schema = 'test' AND table_name in ('t_nonclustered');
+----------------+--------------+
| TABLE_NAME     | TIDB_PK_TYPE |
+----------------+--------------+
| t_nonclustered | ~!@NONCLUSTERED@!~ |
+----------------+--------------+

tidb> SELECT _tidb_rowid, id, name, tel FROM t_nonclustered
  ORDER BY _tidb_rowid
+-------------+----+-------+-------------+
| ~!@_tidb_rowid@!~ | id | name  | tel         |
+-------------+----+-------+-------------+
|           1 |  1 | Tom   | 7073958726  |
|           2 |  2 | Jack  | 4782733578  |
|           3 |  3 | Frank | 147810546   |
|           4 |  4 | Tony  | 335451143   |
|           5 |  5 | Jim   | 1390811212  |
|           6 |  6 | Sam   | 1579915611  |
|           7 |  7 | Andy  | 18922118921 |
+-------------+----+-------+-------------+

tidb> UPDATE t_nonclustered SET tel = '147810001' WHERE id = 3;
...
```
------------------------------------------------------------------------------
The slide shows a table `t_nonclustered` with 7 rows, which is a table with non-clustered index with primary key. The primary key is on column `id`.

Database client has issued a `UPDATE` statement:
```
UPDATE t_nonclustered SET tel = '147810001' WHERE id = 3;
```

Then, five important steps executed by the TiDB server instance in a specific order: 
`1.` The metadata of the `t_nonclustered` table in the `Placement Driver` is retrieved. As a result, the TiDB server instance becomes aware of the TiKV node that contains the desired TiKV Region.
`2.` A `Point_Get` operation is executed on the index by using the unique `id` value to located the interested `key-value` entry.
`3.` A `Point_Get` operation is executed on the table by using the unique `_tidb_rowid` value to located the interested `key-value` entry.
`4.` Stores the newly created `key-value` entry with the new value and a higher version number appended to the `key` in the TiKV Region where the table is located. The old version of `key-value` entry is kept for the sake of MVCC.
`5.` Stores the newly created `key-value` in the corresponding index entry.

In the "Introduction to TiDB" course, we obtained a brief understanding of `MVCC`. For a more comprehensive understanding of `MVCC`, please refer to the "TiDB Essentials" course.