目录
1测试环境以及测试用例设计
1.1测试环境
1.2测试用例设计
2 千万级数据量性能测试对比
2.1 MemSQL时间范围分页查询
2.1.1 性能测试数据
2.2任务信息查询
2.2.1 性能测试数据
2.3 执行批次范围查询
2.3.1 性能测试数据
2.4 批次任务查询
2.4.1 性能测试数据
2.5 聚合查询
2.5.1 性能测试数据
2.5 系统资源监控数据
2.6总结
2.7 图表性能分析
2.7.1查询时间对比
2.7.2吞吐量对比
3 稳定性测试
3.1 docker重启以后
3.2 Linux系统重启
3.3 数据加载的过程中资源使用情况
Mysql 和MemSQL都是 4C/8G，测试接口都是通过Spring boot 微服务rest接口测试,MySQL 数据中和MemSQL的表都创建了相同的索引,其中create_time 都使用了降序索引(MYSQL8.0是倒排索引)。
1.1.1 Mysql 索引
1.1.1 MemSql 索引
1.2.1时间范围分页查询参数
/result/{page}/{size}/{startTime}/{endTime}
1.2.2根据任务信息查询参数：
/conditionOne/{page}/{size}/{powerDeviceId}/{taskId}
1.2.3执行批次范围查询参数：
/conditionTwo/{page}/{size}/{batchIdList}
1.2.4执行任务与批次范围查询参数：
/conditionThree/{page}/{size}/{batchIdList}/{taskIdList}
1.2.5聚合查询，采集计划前10个批次数据聚合：
/aggregate/{planId}
会使用group by 和 order by 以及limit。
memsql数据总量：
MemSQL是兼容Mysql的，这里完全使用Mysql8.0的测试用例。
/mysql/result/20/20/2019-09-01/2019-09-30
2.1.1 性能测试数据
50 并发
100并发
200并发
/mysql/conditionOne/20/20/611607718939246592/611680047597752372
2.2.1 性能测试数据
/mysql/conditionTwo/10/20/1001,1002,1003,1004,1005,1027
2.3.1 性能测试数据
2.4.1 性能测试数据
/mysql/aggregate/620656410385203201
2.5.1 性能测试数据
50并发：
100并发：
200并发：
CPU
内存
磁盘读写
在性能测试的过程中，系统的CPU 和磁盘I/O 占用率都比较低，基本不读磁盘，是从内存中查询数据，所以相对效率比较高。但是内存的占用率太高了，1千万的数据（加上索引）需要差不多8G的内存。之前我设置为6G,导入数据的时候一直报错，后来设置为8G才没有问题。
依据上面的测试数据给出对比图，这里使用性能测试结果中的平均值的极大值。
相对于TiDB 和CockroachDB ，MemSQL的性能要好的多，但是在并发量增加的时候，读的效率突然降低很多，说明MemSQL也是无法很好的处理高并发读的场景。但是MemSQL 总是在使用内存来处理I/O，所以它的写的效率很高。下面是我测试过程中同步数据的截图，这里都没有使用mysqldump，只是使用navicat，大概 需要11分钟可以同步1千万（3G）的数据量。相对于其他的NewSQL数据库，可以说就像兔子一样，跑的飞快。
2.7.1查询时间对比
以50%为分割线,占比少的说明效率高。MemSQL 使用多次测试结果中平均响应时间的极大值，Mysql使用极小值。参考 :Mysql.8.0 与 MongoDB.4.2大数据量查询性能对比. 中 mysql50并发的测试数据。
2.7.2吞吐量对比
以50%为分割线,占比多的说明吞吐量高。MemSQL 使用多次测试结果中平均响应时间的极大值，Mysql使用极小值。参考 :Mysql.8.0 与 MongoDB.4.2大数据量查询性能对比. 中 mysql50并发的测试数据.
无论是读写的效率，还是并发吞吐量， MemSQL 明显优于Mysql。
这里侧重MemSQL系统恢复时间测试.
docker重启以后：leaf 节点的数据仍然在内存中，不需要重新加载。这也是使用Dockers的好处
但是Linux系统重启以后 ，MemSQL会重新加载数据(1个leaf节点，1千万条数据)到内存，这个过程很快,大概2分钟左右，前提是SDD 硬盘。
内存利用率变化
CPU变化
磁盘I/O读写变化