# Best Practices with Partitioned Tables

+ Use the partition keys in the `WHERE` predicates when possible to leverage partition pruning
+ Use partition-wised (DROP/TRUNCATE PARTITION) instead of table-wised DML when possible
+ Use placement rules to to separate hot and cold data by table partitions (for storage tiering use case)

------------------------------------------------------------------------------
Partition pruning is an optimization based on the schema metadata which is based on a very simple idea - do not scan the partitions that do not match.

The `RANGE COLUMNS` and `LIST COLUMNS` partitioning types enable the use of multiple columns in the partitioning key.

Both `KEY` partitioning and `HASH` partitioning can evenly distribute data into a certain number of partitions. The difference is that `HASH` partitioning only supports distributing data based on a specified integer expression or an integer column, while `KEY` partitioning supports distributing data based on a column list, and partitioning columns of `KEY` partitioning are not limited to the integer type. The `HASH` algorithm of TiDB for `KEY` partitioning is different from that of MySQL, so the table data distribution is also different.

We will discuss partition pruning in detail in chapter 4.