-
测试平台mysql 8.0.31,2核心4线内存2G的虚拟机硬盘ssd，下面测试结果的瓶颈很多都来自这2G的内存。
-
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 秒
-
所以结论就是目前来说性能几乎没区别。
-
-
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 是实时统计，效率比较低，所以查询的时候请务必带上查询条件并且命中索引，如果没有条件可以考虑时间上建立索引默认查询一定时间以内
-
2000W级别数据对mysql插入数据的影响(多线程批量插入)
0条二级索引,10W耗时3.6秒1条二级索引,10W耗时5秒
2条二级索引,10W数据耗时7.8秒 -
无查询条件的深分页对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秒，区别已经不大了。 -
我们看看上面的 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 关联走索引覆盖，如果要用子查询，检查一下是否按照预期的执行了。不然效果差很多。
-
-
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的说法是扯淡。