# `Point_Get` Example for a Clustered Index for Primary Key
+ **`Point_Get`** is efficient
+ Only one object, specifically the table, is being accessed

```
tidb> SHOW CREATE TABLE universe.planets;

tidb> CREATE TABLE `planets` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  ...
  PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */,
  ...

tidb> EXPLAIN
  SELECT mass, gravity
  FROM universe.planets
  WHERE id = 3;

+-------------+---------+------+---------------+---------------+
| id          | estRows | task | access object | operator info |
+-------------+---------+------+---------------+---------------+
| ~!@Point_Get@!~_1 | 1.00    | root | table:planets | handle:3      |
+-------------+---------+------+---------------+---------------+
```

![`smart`](ClusteredTableWithPrimaryKey_en_001_20231116.png)

------------------------------------------------------------------------------
In the case of a primary key backing by a clustered index, the table and the index share the same underlying structure in TiKV.  

In the execution plan shown on the slide, `Point_Get` operator retrieves data directly from the clustered index in one step. In this scenario, TiDB works as a `key-value` NoSQL database. 

Later in this chapter, we will explore in more depth the participation of TiDB components (PD, TiDB server and TiKV server) in the `Point_Get` operation during the section of `SELECT` and `INSERT/UPDATE/DELETE` processes. Furthermore, in chapter 4, we will delve deeper into the execution plan perspective of the `Point_Get` action.