# `UPDATE` a Row in a Clustered Primary Key Table

![`smart`](ClusteredPrimaryKeyTableUPDATE01_aa_002_20230905.png)

```7
tidb> DESC t_clustered;
+-------+-------------+------+------+---------+-------+
| 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_clustered');
+-------------+--------------+
| TABLE_NAME  | TIDB_PK_TYPE |
+-------------+--------------+
| t_clustered | ~!@CLUSTERED@!~    |
+-------------+--------------+

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

tidb> UPDATE t_clustered SET tel = '147810001' WHERE id = 3;
...
```
------------------------------------------------------------------------------
The slide shows a table `t_clustered` with 7 rows, which is a table with clustered index for primary key. As a result, `_tidb_rowid` column does not exist. The primary key is on column `id`.

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

Then, three important steps executed by the TiDB server instance in a specific order: 
`1.` The metadata of the `t_clustered` 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 by using the unique `id` value to located the interested `key-value` entry.
`3.` 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 Multi-version Concurrency Control `(MVCC)`.

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