MySQL performance: multiple tables vs. index on single table and partitions

by

Creating 20,000 tables is a bad idea. You’ll need 40,000 tables before long, and then more.

I called this syndrome Metadata Tribbles in my book SQL Antipatterns Volume 1. You see this happen every time you plan to create a “table per X” or a “column per X”.

This does cause real performance problems when you have tens of thousands of tables. Each table requires MySQL to maintain internal data structures, file descriptors, a data dictionary, etc.

There are also practical operational consequences. Do you really want to create a system that requires you to create a new table every time a new user signs up?

Instead, I’d recommend you use MySQL Partitioning.

Here’s an example of partitioning the table:

CREATE TABLE statistics (
  id INT AUTO_INCREMENT NOT NULL,
  user_id INT NOT NULL,
  PRIMARY KEY (id, user_id)
) PARTITION BY HASH(user_id) PARTITIONS 101;

This gives you the benefit of defining one logical table, while also dividing the table into many physical tables for faster access when you query for a specific value of the partition key.

For example, When you run a query like your example, MySQL accesses only the correct partition containing the specific user_id:

mysql> EXPLAIN PARTITIONS SELECT * FROM statistics WHERE user_id = 1\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: statistics
   partitions: p1    <--- this shows it touches only one partition 
         type: index
possible_keys: NULL
          key: PRIMARY
      key_len: 8
          ref: NULL
         rows: 2
        Extra: Using where; Using index

The HASH method of partitioning means that the rows are placed in a partition by a modulus of the integer partition key. This does mean that many user_id’s map to the same partition, but each partition would have only 1/Nth as many rows on average (where N is the number of partitions). And you define the table with a constant number of partitions, so you don’t have to expand it every time you get a new user.

You can choose any number of partitions up to 1024 (or 8192 in MySQL 5.6), but some people have reported performance problems when they go that high.

It is recommended to use a prime number of partitions. In case your user_id values follow a pattern (like using only even numbers), using a prime number of partitions helps distribute the data more evenly.

Re your questions in comment:

How could I determine a resonable number of partitions?

For HASH partitioning, if you use 101 partitions like I show in the example above, then any given partition has about 1% of your rows on average. You said your statistics table has 30 million rows, so if you use this partitioning, you would have only 300k rows per partition. That is much easier for MySQL to read through. You can (and should) use indexes as well — each partition will have its own index, and it will be only 1% as large as the index on the whole unpartitioned table would be.

So the answer to how can you determine a reasonable number of partitions is: how big is your whole table, and how big do you want the partitions to be on average?

Shouldn’t the amount of partitions grow over time? If so: How can I automate that?

The number of partitions doesn’t necessarily need to grow if you use HASH partitioning. Eventually you may have 30 billion rows total, but I have found that when your data volume grows by orders of magnitude, that demands a new architecture anyway. If your data grow that large, you probably need sharding over multiple servers as well as partitioning into multiple tables.

That said, you can re-partition a table with ALTER TABLE:

ALTER TABLE statistics PARTITION BY HASH(user_id) PARTITIONS 401;

This has to restructure the table (like most ALTER TABLE changes), so expect it to take a while.

You may want to monitor the size of data and indexes in partitions:

SELECT table_schema, table_name, table_rows, data_length, index_length
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE partition_method IS NOT NULL;

Like with any table, you want the total size of active indexes to fit in your buffer pool, because if MySQL has to swap parts of indexes in and out of the buffer pool during SELECT queries, performance suffers.

If you use RANGE or LIST partitioning, then adding, dropping, merging, and splitting partitions is much more common. See http://dev.mysql.com/doc/refman/5.6/en/partitioning-management-range-list.html

I encourage you to read the manual section on partitioning, and also check out this nice presentation: Boost Performance With MySQL 5.1 Partitions.

More Related Contents:

  1. DOs and DONTs for Indexes [closed]
  2. Higher cardinality column first in an index when involving a range?
  3. Does Order of Fields of Multi-Column Index in MySQL Matter
  4. MySQL load data infile – acceleration?
  5. Would it help to add index to BIGINT column in MySQL?
  6. Mysql performance on 6 million row table
  7. How can i optimize MySQL’s ORDER BY RAND() function?
  8. Why does MYSQL higher LIMIT offset slow the query down?
  9. How do I add indexes to MySQL tables?
  10. Is there a REAL performance difference between INT and VARCHAR primary keys?
  11. Is the primary key automatically indexed in MySQL?
  12. MySQL: Fastest way to count number of rows
  13. Mysql::Error: Specified key was too long; max key length is 1000 bytes
  14. MySQL vs MongoDB 1000 reads
  15. How to see indexes for a database or table in MySQL?
  16. Speeding up row counting in MySQL
  17. MySQL “IN” operator performance on (large?) number of values
  18. MySQL varchar index length
  19. What is better in MYSQL count(*) or count(1)?
  20. Mysql Improve Search Performance with wildcards (%%)
  21. How can I manipulate MySQL fulltext search relevance to make one field more ‘valuable’ than another?
  22. MySQL view performance
  23. MySQL Integer vs DateTime index
  24. is php sort better than mysql “order by”?
  25. How can “set timestamp” be a slow query?
  26. MySQL optimizing INSERT speed being slowed down because of indices
  27. Two single-column indexes vs one two-column index in MySQL?
  28. MySQL – why not index every field?
  29. MySQL: how to index an “OR” clause
  30. Workaround in mysql for partial Index or filtered Index?

Leave a Comment