创建20,000个表是一个坏主意。您很快将需要40,000个表，然后更多。
我在《SQL反模式》一书中将此综合症称为
Metadata Tribbles
。您每次计划创建“每X表格”或“每X列”时都会看到这种情况。
当您有成千上万个表时，这确实会导致实际的性能问题。每个表都需要MySQL维护内部数据结构，文件描述符，数据字典等。
还有实际的操作后果。您是否真的要创建一个系统，该系统要求您每次注册新用户时都创建一个新表？
相反，我建议您使用MySQL分区。
这是对表进行分区的示例：
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;
这给您带来了定义一个逻辑表的好处，同时还可以将该表分为许多物理表，以便在查询分区键的特定值时可以更快地进行访问。
例如，当您像示例一样运行查询时，MySQL仅访问包含特定user_id的正确分区：
mysql> EXPLAIN PARTITIONS SELECT * FROM statistics WHERE user_id = 1\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: statistics
partitions: p1
type: index
possible_keys: NULL
key: PRIMARY
key_len: 8
ref: NULL
rows: 2
Extra: Using where; Using index分区的HASH方法意味着通过整数分区键的模数将行放置在分区中。这确实意味着许多user_id都映射到同一分区，但是每个分区平均只有平均行数的1 /
N(其中N是分区数)。而且您用固定数量的分区来定义表，因此不必在每次获得新用户时都对其进行扩展。
您可以选择多达1024个分区(在MySQL 5.6中为8192)的任意数量的分区，但是有些人报告说，当分区过高时会出现性能问题。
建议使用素数分区。如果您的user_id值遵循某种模式(例如仅使用偶数)，则使用质数分区可以帮助更均匀地分配数据。
在评论中回答您的问题：
如何确定合理的分区数量？
对于HASH分区，如果您使用101个分区(如上例所示)，则任何给定分区平均约占行的1％。您说统计信息表有3000万行，因此，如果使用此分区，则每个分区只有30万行。对于MySQL而言，这更容易阅读。您也可以(也应该)使用索引-
每个分区都有其自己的索引，并且其大小仅为整个未分区表的索引的1％。
因此，如何确定合理数量的分区的答案是：整个表有多大，并且您希望分区平均有多大？
分区数量不应该随着时间增长吗？如果是这样：我该如何自动化？
如果您使用HASH分区，则分区的数量并不一定需要增加。最终，您可能总共有300亿行，但是我发现，当您的数据量增长几个数量级时，无论如何都需要一种新的体系结构。如果您的数据变得如此之大，则可能需要在多个服务器上进行
分片 以及将其分区到多个表中。
也就是说，您可以使用ALTER TABLE重新分区表：
ALTER TABLE statistics PARTITION BY HASH(user_id) PARTITIONS 401;
这必须重新组织表(就像大多数ALTER TABLE更改一样)，因此希望它花一些时间。
您可能要监视分区中数据和索引的大小：
SELECT table_schema, table_name, table_rows, data_length, index_length
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE partition_method IS NOT NULL;
与任何表一样，您希望活动索引的总大小适合您的缓冲池，因为如果在SELECT查询期间MySQL必须在缓冲池中交换部分索引进出索引，则性能会受到影响。
如果使用RANGE或LIST分区，则添加，删除，合并和拆分分区更为常见。
