为何分表后mysql效率会更低?

发布网友发布时间：2022-04-24 15:07

共1个回答

热心网友时间：2022-04-10 00:08

我们在上面分别进行了分表和不分表的性能测试，只有一个表，和把这个表拆为32个的情况，两种情况都为innoDB,表内有text字段。padding数据为2亿，做了25个进程的每个进程20W的操作。我们发现如果仅有select,update的时候，分表的情况比不分表的情况快10%，insert的情况就差太远了：分表比不分表慢20%多。可以确定的是，select，update后的where子句有索引，都为单条的查询和更新，insert也只是插入一条。如果查看机器负载，发现不分表，CPU12%~20%和磁盘busy不是100%。分表后磁盘busy100%，而CPU15%~25%。我觉得很郁闷，不是一般来说，分表应该效率更高吗？还是说innoDB已经优化的很好了？我的猜想是：innoDB是行级锁的，所以select,update,insert不会锁住其他的进程，所以效率提升不大。如果你业务上只对单一record操作，你也没有必要分表了。但是，这肯定不是实际情况，实际情况是你有很多批量的update, 很多select。可能有很多select会和update,insert争抢table锁。把这些情况都考虑进去，加一些查询。相信分表的优势立马就有了。明白了，我的实际情况是根本没有证锁的情况，看来没必要了……问题补充：<div class="quote_title">polymorph 写道</div><div class="quote_div">这种压力测试如果脱离开具体的业务意义就不大了。 <br /> <br />就比如一个查询，可能一下查询出1万条记录。这种查询很正常，也很普遍。但是，当系统真正上线以后，有可能出现一下子插入1万条记录的情况吗？所以查询出1万条的查询，速度的提高对系统的性能是很有帮助的，而插入1万条记录速度的降低未必会很大的影响系统的性能。 <br /> <br />再比如数据仓库中的高耦合度，要是论插入的速度，那简直惨目人睹。但是这相当于将时间的消耗平坦到每一次的插入里面了。当你要查询时，会非常快的查询出结果。 <br /> <br />像你现在这个数据量级的话，说句实话，还用MYSQL真是一种冒险。排除这个，将表分开是正确的。当系统真正运行起来，插入时资源消耗的增加不会对系统增加多大压力，但是会极大的降低查询时对系统的压力，而这部分压力，才是属于能让系统DOWN掉的那部分。 <br /> <br />系统资源就是这样，用20%的资源做80%的事情，用剩下的80%的资源做20%的事情。插入就是那80%的事情里面的。就让那20%的消耗增加为25%吧，你会发现那80%的消耗可能一下子就减了一半。