mysql - 为什么在MySQL中拆分表会使插入和查询变慢

Question

我的目标是在一个MySQL表中保存大约6000万行用于高速读取，并且正确地继续插入。
对于产品设计来说，这6000万行自然可以分成3000块，所以我决定做一个表切分策略，把1-60M的表分成3000个表。
我取了300万数据进行以下测试：
一个表中有300万行：
然后，这300万个数据的平均插入时间是80秒，每1000个查询（每个查询从这300万个数据表中获取1000行）大约需要10秒。
300万行平均分为3000个表：
在3000个表中插入300万个数据：79秒（不是很快）；
平均每1000次查询3000个表（其中每个表有1000行）：120秒（比上面慢12倍）
为什么？虽然我有3000个表，但基本上都是MySQL管理的文件，每个查询只访问一个只有1000行的表，但为什么这么慢呢？
我在一台8核机器上运行，该机器配有15G RAM，配置如下：

open_files_limit 300000
table_open_cache 100000

经过2-3次的模拟重新尝试，我还搜索了MySQL的“打开的文件”，如下所示，这似乎可以为我的3000表设置？
打开的桌子：9463
我怎样才能摆脱这个问题？
-----------编辑和更多想法-----------
目前我只在尝试表分片的可能性，也许MySQL合并引擎可以在这个方向上帮一点忙。
另一方面，分区也不是个坏主意。。。以MySQL为例，按范围划分，我可以将范围设为1000万，然后60M表变成6个分区的表。。。查询和插入是否都更快？
-----------尝试表分区的更新-----------
正如下面的评论一样，我认为，表的分区也可以是一个很好的解决方案，尤其是当它保持相同的表名并且对现有代码影响最小的时候。
我试着在这个6000万的表上做6个分区；
1）一开始，我做了如下伪代码：

CREATE TABLE `datatable` (  
`id` int(11) NOT NULL AUTO_INCREMENT,  
`type` int(11) NOT NULL DEFAULT 0,  
`description` varchar(255),  
`datimeutc` datetime,  
`datimelocal` datetime,  
`value` double,  
PRIMARY KEY (`id`), 
KEY INDEX_TYPE ON (type)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1  
PARTITION BY RANGE (id) (  
    PARTITION p0 VALUES LESS THAN (10000000),  
    PARTITION p1 VALUES LESS THAN (20000000),  
    PARTITION p2 VALUES LESS THAN (30000000),  
    PARTITION p3 VALUES LESS THAN (40000000),  
    PARTITION p4 VALUES LESS THAN (50000000)  
    PARTITION p5 VALUES LESS THAN MAXVALUE
);

结果很好。导入300万数据进行测试大约需要1分钟，总共需要63分钟来导入所有6000万数据。
每个查询（从60米基于分区的表中获取20000行）的搜索时间约为90毫秒。对于一个6000万表，我没有任何关于查询性能的比较数据，但是90毫秒是一个合理的值吗？
2）我尝试了字段“type”上的分区，希望将传入的单个查询限制在单个分区上，因为MySQL对带分区的唯一键有限制，所以伪代码如下：

CREATE TABLE `datatable` (  
`id` int(11) NOT NULL AUTO_INCREMENT,  
`type` int(11) NOT NULL DEFAULT 0,  
`description` varchar(255),  
`datimeutc` datetime,  
`datimelocal` datetime,  
`value` double,   
KEY (`id`), 
KEY INDEX_TYPE ON (type)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1  
PARTITION BY RANGE (type) (  
    PARTITION p0 VALUES LESS THAN (500),  
    PARTITION p1 VALUES LESS THAN (1000),  
    PARTITION p2 VALUES LESS THAN (1500),  
    PARTITION p3 VALUES LESS THAN (2000),  
    PARTITION p4 VALUES LESS THAN (2500)  
    PARTITION p5 VALUES LESS THAN MAXVALUE
);

此时，当我插入60米数据时，与第一种情况相比，插入时间太长了。我还没有结果，但到目前为止，只插入400万数据已经花了3个小时。。。
为什么？
我在想，也许我是按顺序插入60米，即行Id从1开始到600万。所以在第一种情况下，我基本上打开并锁定第一个要插入的分区，一旦插入第一个10米，我打开第二个分区继续。
另一方面，在2）分区的情况下，我需要频繁地随机地打开所有6个分区（它们都是按“type”而不是“id”设计的），所以表的锁定和解锁花费了太多的时间？这可能是原因吗？

Answer 1

是的，在MySQL中拆分表对于以下场景是一种通用的好做法：
表太大，常规的表操作时间变得无法忍受（性能急剧下降）
表中热数据的百分比相对较小
数据上有一个时间窗口（数据可以及时存档或清除）
为了提高并发性，在这种情况下，数据通常分布在不同的独立物理服务器或不同的存储系统中
在你最初的文章中，我认为你主要关心第一个场景，所以让我们进一步讨论。
为什么当表很大时性能会急剧下降？尺寸界限是多少？都是关于记忆的。除非您购买了FusionIO或任何类型的SSD系统，否则当I/O命中磁盘时，总是会有一个陡峭的曲线。通常，SATA/SAS磁盘阵列只能执行大约50~200个随机IOPS（写缓存受BBU保护），与DDR的200000多个随机IOPS相比，这太慢了。当MySQL的变量被设置为一个合理的值并且表的大小不比缓存的大小大时，性能是相当好的，但是当表增长超过这个限制时，就会发生退化。因此，不要过度优化表结构，除非您知道它们将增长到多大，并测试了整个系统的极限。过早地拆分表不会显示出太多的优势，而且由于数据碎片化带来的其他副作用，性能甚至可能变得更差。
基准就像游戏，你知道，它们不能真正代表现实生活中的情况，所以我们需要规范游戏规则。我对my.cnf设置很好奇，特别是缓冲区变量，因为第一个场景的性能很大程度上取决于内存缓存和磁盘读/写策略。变量包括：
table_definition_cache：此变量指示内存中可以存储多少表元数据（对MyISAM来说，它们是.frm文件）。如果一个表被重复打开，它不会有帮助，但是如果有很多表需要打开（在您的例子中，是3000个表），如果这个缓存可以包含所有表的元数据，它会有帮助。
table_open_cache：这个变量指示MySQL可以在内存中保存多少内部表处理程序，就像上面一样，它将提高表上下文切换速度。
key_buffer_size：因为您使用的是MyISAM，所以这个变量在性能上会起到非常重要的作用。它设置MySQL可以分配给MyISAM表的最大内存空间大小，如果使用MyISAM，首选值将是系统内存的30%。我取30%的原因是有两个东西要缓存，一个是索引，另一个是行数据；key_buffer_size表示索引，OS负责行数据缓存（块I/O缓冲缓存）。为索引保留30%，为行数据保留50%，为表缓存、线程缓存、连接缓存等其他缓冲区缓存保留20%。看起来此变量不会同时降低这两种情况的速度，但谁知道，设置得太小可能会同时影响这两种情况，而多表的影响更大。
key_cache_block_size：这个变量设置缓存块的大小，这将浪费I/O（头/尾读）并导致读复写（先读后写）。多表方案可能会受到更多的影响，因为它有更多的表（文件）。
我还很好奇SQL查询是如何编写的，您使用了多少线程来读/写MySQL。例如，顺序写入一个表就像顺序写入，速度比随机写入快得多；顺序写入3000个表就像随机写入，速度可能不如随机写入。当创建3000个表时，有3000个.MYI文件和3000个.MYD文件，它们在磁盘上可能不连续（会发生随机I/O），但是1.MYI和1.MYD，它们很可能在磁盘上自己连续。这也适用于磁盘读取。但是在你的例子中，读比写慢得多，我想这可能是因为写是缓冲的，但是读不是，如果你是第一次选择行的话。当从一个表中读取时，MySQL可以将key_cache作为一个整体预加载一次，OS也可以预读取下一个块，因为它们是连续的；但是在多个表中，MySQL/OS不能作为一个整体预加载。如果可以尝试生成更多的客户端线程来发出查询，则这两种情况的性能可能会更接近。
关于您最近对分区的更新，我想您可能是对的，按“类型”分区听起来很像是随机I/O，当您批量插入哪些SQL数据是按主键排序的，而不是按“类型”排序的，外加子分区表处理程序开关。