# Data Retrieval Best Practices
+ Do NOT retrieve more rows than your application needs
  + Limiting rows only in your application, instead of SQL, does not terminate the query after retrieving the number of rows required
  + Using a **`LIMIT`** clause in your SQL statement terminates the query
+ Do NOT retrieve unnecessary columns
  + Eliminate **`SELECT *`**
------------------------------------------------------------------------------
Developers who are not familiar with TiDB might assume that when they issue a query to return a specified number of rows (e.g., for paginating query results) and then close the result set, the query is terminated. However, this is not the case. TiDB always generates the complete result set. A more effective approach is to use a `LIMIT` clause in the query, which reduces network traffic by sending only the specified number of rows to the client. Nonetheless, `LIMIT` does not always decrease the number of rows the server reads, so it does not consistently enhance query performance on the server side.

Be cautious when using `SELECT *` to return all columns' data. This often includes irrelevant columns, especially when tables are joined, adding unnecessary overhead. Using `SELECT *` prevents the optimizer from leveraging any covering index that might fulfill a query requesting fewer columns. `SELECT *` returns columns based on the structure (and order) that exists in the table at the time of execution. If `SELECT *` is used in your code and the database structure changes, your application might not receive the data in the expected format. This means column definitions might vary, and column order might be incorrect.

The following inefficient query returns all columns from all joined tables:

```
SELECT * FROM t1, t2, t3 WHERE t1.id = t2.id AND t2.id = t3.id AND t1.id = t3.id;
```

Instead, specify the exact columns you want to retrieve from the tables:

```
SELECT t1.id, t2.name, t3.name FROM t1, t2, t3 WHERE t1.id = t2.id AND t2.id = t3.id AND t1.id = t3.id;
```