LIST Partitioning job_code INT, store_id INT ); (This is the same table used as a basis for the examples in Section 24.2.1, “RANGE Partitioning” . As with the other partitioning examples, we assume that the  default_storage_engine  is  InnoDB .) Suppose that there are 20 video stores distributed among 4 franchises as shown in the following table. Region Store ID Numbers North 3, 5, 6, 9, 17 East 1, 2, 10, 11, 19, 20 West 4, 12, 13, 14, 18 Central 7, 8, 15, 16 To partition this table in such a way that rows for stores belonging to the same region are stored in the same partition, you could use the  CREATE TABLE  statement shown here: CREATE TABLE employees ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT ’1970-01-01’, separated DATE NOT NULL DEFAULT ’9999-12-31’, job_code INT, store_id INT ) PARTITION BY LIST(store_id) ( PARTITION pNorth VALUES IN (3,5,6,9,17), PARTITION pEast VALUES IN (1,2,10,11,19,20), PARTITION pWest VALUES IN (4,12,13,14,18), PARTITION pCentral VALUES IN (7,8,15,16) ); This makes it easy to add or drop employee records relating to specific regions to or from the table. For instance, suppose that all stores in the West region are sold to another company. In MySQL 8.0, all rows relating to employees working at stores in that region can be deleted with the query  ALTER TABLE employees TRUNCATE PARTITION pWest , which can be executed much more efficiently than the equivalent  DELETE  statement  DELETE FROM employees WHERE store_id IN (4,12,13,14,18); . (Using  ALTER TABLE employees DROP PARTITION pWest  would also delete all of these rows, but would also remove the partition  pWest  from the definition of the table; you would need to use an  ALTER TABLE ... ADD PARTITION  statement to restore the table’s original partitioning scheme.) As with  RANGE  partitioning, it is possible to combine  LIST  partitioning with partitioning by hash or key to produce a composite partitioning (subpartitioning). See Section 24.2.6, “Subpartitioning” . Unlike the case with  RANGE  partitioning, there is no “catch-all”  such as  MAXVALUE ; all expected values for the partitioning expression should be covered in  PARTITION ... VALUES IN (...)  clauses. An INSERT  statement containing an unmatched partitioning column value fails with an error, as shown in this example: mysql>  CREATE TABLE h2 ( -> c1 INT, -> c2 INT ->  ) ->  PARTITION BY LIST(c1) ( -> PARTITION p0 VALUES IN (1, 4, 7), -> PARTITION p1 VALUES IN (2, 5, 8) ->  ); Query OK, 0 rows affected (0.11 sec) 4666