# Query `(SELECT)` a Row from a Table with Clustered Index for Primary Key

![`smart`](ClusteredPrimaryKeyTableSELECT01_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> EXPLAIN SELECT name, tel FROM t_clustered WHERE id = 3;
+-------------+---------+------+-------------------+---------------+
| id          | estRows | task | access object     | operator info |
+-------------+---------+------+-------------------+---------------+
| Point_Get_1 | 1.00    | root | ~!@table:t_clustered@!~ | handle: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 `SELECT` statement:
```
SELECT name, tel FROM t_clustered WHERE id = 3;
```

Then, two 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. In addition, the TiDB server will not have to query the `Placement Driver` every time to determine which TiKV Store has the corresponding TiKV Region due to the TiKV Region cache.
`2.` The table is accessed to retrieve the row of interest by using the unique `id` value directly, it is referred to as a `Point_Get` operation.

Note the `handle:3` under the `operator info` column in the explain table, which indicates that the TiDB server `(Root)` instance directly requests the TiKV server using the `GET(3)` (pseudo code) in step 2.