# Tips - Using `SQL` Hints

+ Specify SQL hint between the **`SELECT`** command and the column list expressions by using **`/*+ ... */`**
+ Override the optimizer's decision to perform a comparison between plans

```7
tidb> EXPLAIN SELECT /*+ ~!@USE_INDEX_MERGE@!~(employees, idx_first_name, idx_last_name) */ *
   -> FROM employees 
   -> WHERE first_name='Peter' AND last_name='Candy';
+---------------------------+---------+-----------+---------------------------------------------------+-------------------------------------------+
| id                        | estRows | task      | access object                                     | operator info                             |
+---------------------------+---------+-----------+---------------------------------------------------+-------------------------------------------+
| ~!@IndexMerge@!~_8              | 0.14    | root      |                                                   | type: intersection                        |
| ├─IndexRangeScan_5(Build) | 236.39  | cop[tikv] | table:employees, index:idx_first_name(first_name) | range:["Peter","Peter"], keep order:false |
| ├─IndexRangeScan_6(Build) | 183.92  | cop[tikv] | table:employees, index:idx_last_name(last_name)   | range:["Candy","Candy"], keep order:false |
| └─TableRowIDScan_7(Probe) | 0.14    | cop[tikv] | table:employees                                   | keep order:false                          |
+---------------------------+---------+-----------+---------------------------------------------------+-------------------------------------------+
4 rows in set (0.00 sec)
```

------------------------------------------------------------------------------
The execution plan on this slide shows that `IndexMerge` is enabled even though the query involves an intersection. This is possible because a SQL hint, `/*+ USE_INDEX_MERGE(employees, idx_first_name, idx_last_name) */`, was manually added to instruct the optimizer to use `IndexMerge`.