MySql分区表性能测试及切换案例

  • 时间:
  • 浏览:1

于是,大伙认为可不可以 通过将非分区表切换到分区表来降低该数据表存在的性能风险。

通后后边的分析,大伙可不可以 看出,InnoDB表数据量过大对各种操作都存在较大的性能影响。针对哪此难题,有以下有四种 优化方案:

具体步骤如下:

通过以上的分析,大伙得到以下的结论:

逻辑上分析,分区表的优点很明显:既能外理大数据量的性能难题,又能对应用层无缝切换。否则,其真实性能表现和稳定性到底为甚会么会样? 还是得通过测试来验证。

比如,大伙一张记录用户状况的表,存储在RDS for MySql(InnoDB存储引擎)中。此业务表最近膨胀到1.5亿条记录,存储占用50多G,且数据还在不断增长。

切换完成后,大伙进行了一周的性能观察:CPU维持在10%,IOPS有8%左右的下降,存储空间有3%的上升。

单纯从整体的性能指标来看,切换前后变化并就有怪怪的明显。但后后耗时这麼长的操作,耗时稳定了下来,锁表冲突事件也基本这麼再老出。通过PARTITIONS的分析,最大的另一个 分区可是到50万行。即使数据量再扩大10倍,最大分区的数据量也才500万,对于单个存储引擎文件来说,这全部无压力,理论上性能表现可是会老出大幅下滑。但后后装进非分区表,估计业务高峰流量稍微一冲击,后后硬件性能老出波动(在资源共享的云计算环境中,较为常见),就有崩溃的风险。

总体来看,切换分区表比较好的外理了大伙当前对于数据量快速增长的数据库性能的担忧,合适数据量再增长2、3倍应该是能扛住的。但它与否能如大伙预期的在高并发下支持10倍数据量(即单表15亿记录)而性能表现依然稳定,仍有待实践证明。

而MySql的分区表,借助MySql有四种 的逻辑架构,将分库分表功能进行了下沉。MySql逻辑架构中的客户端即对应业务层,Server层对应后边件层,存储引擎层对应物理存储层。简单的说,分库表可是大伙在数据库层面看了是一张表,但物理上是分成多个文件独立存储。

目前,分区表后后稳定在生产环境运行了近另一个 月。

为方便说明,大伙将此业务表逻辑价值形式繁复为只所含以下4列:id(自增列),depart_id(部门ID),user_id(员工ID),mark(员工业绩)。

分区表是MySql 5.1引入的价值形式。根据官网alter-table-partition-operations的介绍,其本质是将分库分表直接集成到MySql中。大伙知道,传统的分库分表功能,存在业务层、后边件、数据库三层:业务层通过调用后边件的API访问数据库,他不知道具体的物理存储细节;后边件将一张很大的逻辑表映射到数据库中多张较小的物理表,并对业务层的访问请求进行分解后分别装进对应物理库中执行,再将执行结果在后边件合并后返回给业务层,从而对业务层屏蔽物理存储细节;数据库则提供实际的物理存储。

下面分别针对 插入、查询、DDL、存储空间 等有有几个关键性能指标进行测试(更新和删除数据的性能表现与查询数据比较一致,不单独分析)。测试结果如下:

针对大数据表,分区表的插入性能、存储空间与否分区表基本一致,查询性能在分区键上比非分区键好,DDL执行时间比非分区表短。

下面大伙深入分析MySql InnoDB表数据量大小对CRUD及DDL操作的性能影响:

为了外理业务中断,大伙参考pt-online-schema-change的模式进行切换。

确实目前整体性能表现尚可,但偏离 操作耗时这麼长,锁表冲突事件也后后开使老出。考虑到数据量的快速增长,以及数据库有四种 的雪崩特点,大伙认为这张表存在很大的性能风险,急需优化。

MySql在5.5及后后的版本,对Online DDL支持不太好,会是因为锁表。否则,percona推出pt-online-schema-change,利用触发器实现在DDL过程中不需要造成读写阻塞。

可不可以 看出:

此方案最简单直接。但大伙的业务中,不到此表数据量较大且需用查询全部单据。仅为了一张表就引入有四种 存储机制,考虑到运维和经济成本,总确实不划算。另外,此表还与這個表有一定的联合查询操作,分离出去完会增加应用层的繁复度;

互联网公司的业务变化变慢,数据库表价值形式设计相对比较直接,很少会在前期设计的很完善。当业务存活并发展起来后,就需用在扩展性、安全性等方面进行改进。

分库分表是外理大数据表的利器。但大伙数据库系统的CPU和IO资源很富余(CPU仅10%,IOPS仅50多),全部这麼分库的必要。而分表会使得应用层的修改工作量巨大,代码的可读性也会变差。后后为了业务层的逻辑清晰再引入后边件进行代理访问,又有杀鸡用牛刀之感;