mysql的性能的一些测试

1. 测试平台mysql 8.0.31,2核心4线内存2G的虚拟机硬盘ssd，下面测试结果的瓶颈很多都来自这2G的内存。

2. char 比 verchar块？ 首先说结论,差不多,没区别,别信谣

   • 110W 数据，无索引，16字长条件下，varchar: 0.562秒，char: 0.567 秒 几乎没有区别

   • 610W 数据，无索引，16字长条件下，varchar: 4.24秒，char: 4.27 秒 ，几乎无差别误差范围内

   • 1110W 数据，无索引，16字长条件下，varchar: 7.862 秒，char: 8.013 秒 ,几乎无差别误差范围内,但是好像varchat 真的比 chat快一点点。

   • 2110W 数据，无索引，16字长条件下,varchar: 17.960 秒,char: 17.798 秒 ,几乎无差别误差范围内

   • 2110W 数据，有索引，16字长条件下,varchar: 0.024 秒,char: char: 0.024 秒

   • 所以结论就是目前来说性能几乎没区别。

3. select ( 星) 和 selec (id) 和 select (二级索引)的效率区别
   //SELECT count(*) 应该默选择的 SELECT count(id) ,而没有只能的选择到最优的索引
   SELECT count(星) from goods 13.224秒
   SELECT count(id) from goods 13.001秒
   //des是二级索引，比主键索引矮胖，统计数据条数，不用回表，比主键效率高很多
   SELECT count(des) from goods 3.265 秒

   备注:innodb的select count 是实时统计，效率比较低，所以查询的时候请务必带上查询条件并且命中索引，如果没有条件可以考虑时间上建立索引默认查询一定时间以内

4. 2000W级别数据对mysql插入数据的影响(多线程批量插入)
   0条二级索引,10W耗时3.6秒

   1条二级索引,10W耗时5秒
   2条二级索引,10W数据耗时7.8秒

5. 无查询条件的深分页对mysql的性能影响
   SELECT * from goods ORDER BY id limit 20000000,100 ，耗时 18秒
   SELECT * from goods ORDER BY id limit 2000000,100 ，耗时 2.16秒
   SELECT * from goods ORDER BY id limit 200000,100 ，耗时0.18秒
   SELECT * from goods ORDER BY id limit 20000,100 ，耗时0.050秒
   SELECT * from goods ORDER BY id limit 2000,100 ，0.026秒，区别已经不大了。

6. 我们看看上面的 2000W深分页怎么优化

   • SELECT * from goods g2 where g2.id in( SELECT id from goods g1 ORDER BY g1.id limit 20000000,100 ) ORDER BY g2.id ，这种子查询在mysql 8 中不准用了 语法错误，提示不支持

   • SELECT * from goods g2 where g2.id in( select * from (SELECT id from goods g1 ORDER BY g1.id limit 20000000,100 ) temp ) ，尽然执行了28秒，看下面的执行计划很奇怪，先执行内部嵌套子查询，这个没问题，但是外层查询尽然在中间的那个子查询之前执行了。mysql 的优化器觉得这样效率比较高？
     

   • SELECT * from goods g2 where g2.id in( select * from (SELECT id from goods g1 ORDER BY g1.id limit 20000000,100 ) temp ) ORDER BY g2.id,我们给它加上排序字段，而且本来就应该加，这时候mysql的优化器尽然改变了执行顺序，正常了最后执行g2的查询，也许mysql觉得 最后还要排序不如最后执行，执行时间5.4秒.块很多，走的索引覆盖，内存如果大会更加快。默认查询是18秒。
     

   • SELECT * from (SELECT id FROM goods ORDER BY id limit 20000000,100) t1 join goods t2 on t1.id = t2.id 我们走表关联，使用索引，效果 5.41秒 和子查询走我们期望的g2最后执行的时候一样。

   • SELECT id FROM goods ORDER BY id limit 20000000,100 我们试试走索引覆盖只查询id试试要多久，结果5.36秒

   • 结论慎用子查询，有时候它 不一定按照最优的结果走。可以看了程序索引覆盖然后二次查询，或者join 关联走索引覆盖，如果要用子查询，检查一下是否按照预期的执行了。不然效果差很多。

7. in的效率和id的数量关系 执行语句 SELECT 星 from goods where id in(ids），id取得2000W数据的中段连续id

   100个Id, 0.034秒
   1000个Id, 0.51秒
   1W个Id, 0.75秒
   10W个Id, 81秒 这明显是因为硬件限制，内存装不下，反复回盘了
   所以in 的效率很高，in上限1000个Id的说法是扯淡。