本次对mysql做了单表亿级数据量的压测。
表的关系简单，只有两个int字段，user_id和company_id，且都增加了索引。
通过python脚本，随机向同一个表随机插入100W、500W、1000W-1E数据，并且记录了每次插入数据所耗时间。
先来看下写入数据的情况吧：
python脚本空转：
空转100W：0.14s
空转1000W：1.74s
单次插入1000W条数据：295.11s
1000W基础上再插入1000W，轮询，直到写入1E数据，记录每次插入所耗的时间。
可以看到，随着数据量的不断增大，每次插入1000W条数据的时间还是比较稳定，上下浮动不大。
我们最终关心的是单表乙级数据量下，查询速度能有多快。
下面是用python客户端脚本模拟对1E条数据进行随机查询，随机用的是python的随机函数；机器资源有限，开发机是公用的，
所以也没太敢占用太大资源来做压测，并发用的Python的线程模块。
本次查询测试采用三种方法：
1、单进程对数据库执行随机查询1000次操作，执行100次，记录每次时间
2、并发1000、2000线程对数据库进行随机查询1000次操作，记录每次时间
3、用mysql官方软件mysqlslap 对数据库进行操作
第一种：单次查询1000次的结果，跑100次，发现时间浮动还是比较大，这可能跟插入的数据散列情况有关，
user_id相同的数据还是有不少，20-100之间，线上业务出现这种数据的情况不大，所以，这些数据不影响最终结果。
第二种：并发1000线程对数据库进行随机1000次查询，
1000线程：最慢时间8s，处理能力 125/s ；
2000线程：最慢时间10s，处理能力 100/s；
第三种：mysqlslap进行测试
开启2000个线程，执行SELECT * FROM user_company_test_5000 WHERE user_id=7432查询
平均处理时间8.76s，每秒能处理229个查询。
用官方的mysqlslap进行测试，跟python脚本的测试结果偏差较大，
猜测原因有两个：
1：mysqlslap 直接采用socket对Mysql进行连接，所以它除了 mysql处理时间和网络请求时间没有其他影响结果的操作
2：mysqlslap只能指定sql，没有办法随机查询数据，而测试表里面的数据分散不均匀，这也是一个原因。
mysqlslap的数据只能视为最好情况，但第二个python脚本则更接近生产环境，1000次查询数据也是随机查询，
所以第二种能作为生产环境的依据。
再来看看批量查询，IN 语句最多50个值
好吧，我只开了200个线程，最慢时间93s，最快时间46s，简直可以用惨不忍睹来讲。。如果是批量查询，
那就拆成多条语句来查吧。如果用IN ，必然会影响服务。
结论：跟dba沟通过，理论上每秒能够支持5000次的查询量是比较正常的，但我用mysqlslap对单表100W的数据量进行了
测试，2000个client 每秒处理能力也只有700左右，
从第二种数据上看，当单机client达到2000时，每秒还能处理100次左右的查询，还是不错的。
转载自：w3cstudy学习网