• 网站首页
• 网站建设
• 短视频
• 网站推广
• 网站模板
• 客户案例
• 资讯动态
• 关于我们

mysql联合查询 效率,分表查询和索引查询哪个更快_数据库

当前位置：网站建设 > 技术支持

分表和索引并不是二选一的问题

通常使用MySQL时（其余的数据库也一样），大多数时候索引是必须要增加的，好处是查询速度提升非常大，数据量越多越明显；缺点是会对新增、修改、删除的速度造成一定程度的影响，不过这个影响和查询效率的提升相比，不值一提。

当单表中的数据量进一步增多，例如到了大几千万、几亿这个级别，单台MySQL已经不足以支撑这么多的数据了，这时候就要考虑分区、分表或分库了；当然分表之后，每一个子表中仍然可以有索引。

如果非要说分表查询和索引查询哪个快，当数据量没达到需要分表的程度时，比如只有一百万的数据量，我觉得还是索引查询快，毕竟分表查询还需要程序路由到数据所在的分区上，这个也是需要消耗时间的。

MySQL单表数据量在一千万以内的时候，性能是比较好的，超过千万性能会有下降，到了五六千万以上，性能下降就比较明显了，这是就要考虑分表了。

分表另外一个好处是，单个服务器的性能毕竟是有限的，例如磁盘的IO，分表后将子表部署在不同的磁盘上（也可以直接分库），可以利用多台服务器的资源，更好地支持高并发。

RANGE分区：根据某一个字段的区间，进行分区。比如按照id分区，1到10万一个分区，10万零1到20万一个分区。

HASH分区：定义一个表达式，对表达式的结果进行分区选择。例如把id和某个整数进行取模运算，结果为1的是一个分区，结果是2的一个分区。

业务字段分区：这个就容易理解了，在业务数据中选择一个合适的字段，作为分区字段。比如按照公司码分区，companyCode=1（北京）为一个分区，companyCode=2（天津）为一个分区；当然，一般不会选择companyName=北京/天津这样的字段；不过这种分表策略，不能保证数据平均，比如北京有五千万数据，天津有五百万数据。

分表/分库虽然看起来很美好，但是问题也不少：跨库关联、分布式事务、结果集合并/排序等问题，都是需要考虑解决的。

版权说明：
本网站凡注明“广州京杭 原创”的皆为本站原创文章，如需转载请注明出处！
本网转载皆注明出处，遵循行业规范，如发现作品内容版权或其它问题的，请与我们联系处理！
欢迎扫描右侧微信二维码与我们联系。