用Python测试MySQL分区

在Oracle辉煌的时候就接触到了分区技术，在分区技术的加持下，单表的容量上限得到极大的扩展，其性能表现更加的优异

MySQL在5.1版本推出分区，到现在完善了list/range columns模式，加强了对其他数据类型分区键的支持，基于业务模式和应用系统的现状，打算先应用分区技术解决短期内的单表过大而导致的性能问题，在未来遇到瓶颈的时候则考虑采取分表技术。

1. 环境简介

全表数据量在412w

(准备了两张表分别用于不同场景，分区表采取list columns分区，数据量、参数及索引均一致)

服务器配置是4C/32G

服务器参数

截取排名前25位，可以看到top10的gcid数据量在10w+，后面普遍在3-7w不等

2. 测试场景

下面我将分为四个测试场景，分别是

非分区表，顺序递归

在非分区表下，顺序依次调用10个id执行查询

非分区表，并发随机

在非分区表下，设置并发度为10执行查询

分区表，顺序递归

在分区表下，顺序依次调用10个id执行查询

分区表，并发随机

在分区表下，设置并发度为10执行查询

下面是部分的源码，可自定义sql脚本，提供递归和并发两种模式，可自定义并发度

https://github.com/didi909/parallelWorker

3. 测试结果

响应时间见下图

非分区表执行计划

分区表执行计划

4. 测试结论

从执行计划来看，分区表的执行计划在rows和filtered两项参数上均有明显提升

递归和并发两种方式下，随着相关g_c_id_数据量的减少，查询的响应时间递减

在递归方式下，分区表的响应时间提升不稳定，有增有减

在并发方式下，分区表的响应时间均有小幅提升

之所以没有出现期望的明显提升，分析原因有：

查询的字段太多,有90个字段(别问我为什么有这么多，业务就是这样，系统已经在运行了)

测试服务器配置较低，单个sql的消耗已不低，在10个并发的情况下，无法有更好的表现

分区表的优势在不同分区分布在不同磁盘上时体现的最明显，而本次的测试环境只有一块磁盘，IO会有瓶颈