MySQL 中 varcher类型比较大小 mysql varchar 比较

转载

IT剑客风云 2024-05-16 21:36:10

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 in( SELECT id from goods g1 ORDER BY limit 20000000,100 ) ORDER BY ，这种子查询在mysql 8 中不准用了语法错误，提示不支持
SELECT * from goods g2 where in( select * from (SELECT id from goods g1 ORDER BY limit 20000000,100 ) temp ) ，尽然执行了28秒，看下面的执行计划很奇怪，先执行内部嵌套子查询，这个没问题，但是外层查询尽然在中间的那个子查询之前执行了。mysql 的优化器觉得这样效率比较高？

MySQL 中 varcher类型比较大小 mysql varchar 比较_数据

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

MySQL 中 varcher类型比较大小 mysql varchar 比较_数据_02

SELECT * from (SELECT id FROM goods ORDER BY id limit 20000000,100) t1 join goods t2 on = 我们走表关联，使用索引，效果 5.41秒和子查询走我们期望的g2最后执行的时候一样。
SELECT id FROM goods ORDER BY id limit 20000000,100 我们试试走索引覆盖只查询id试试要多久，结果5.36秒
结论慎用子查询，有时候它不一定按照最优的结果走。可以看了程序索引覆盖然后二次查询，或者join 关联走索引覆盖，如果要用子查询，检查一下是否按照预期的执行了。不然效果差很多。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。