为什么这些SQL语句逻辑相同，性能却差异巨大？
SQL逻辑相同,性能差异较大的,通过老师所讲学习到的,和平时碰到的,大概有以下几类:
一.字段发生了转换,导致本该使用索引而没有用到索引
1.条件字段函数操作
2.隐式类型转换
3.隐式字符编码转换
(如果驱动表的字符集比被驱动表得字符集小，关联列就能用到索引,如果更大,需要发生隐式编码转换,则不能用到索引,latin<gbk<utf8<utf8mb4)
二.嵌套循环,驱动表与被驱动表选择错误
1.连接列上没有索引,导致大表驱动小表,或者小表驱动大表(但是大表走的是全表扫描) --连接列上建立索引
2.连接列上虽然有索引,但是驱动表任然选择错误。--通过straight_join强制选择关联表顺序
3.子查询导致先执行外表在执行子查询,也是驱动表与被驱动表选择错误。
--可以考虑把子查询改写为内连接,或者改写内联视图(子查询放在from后组成一个临时表,在于其他表进行关联)
4.只需要内连接的语句,但是写成了左连接或者右连接。比如select * from t left join b on t.id=b.id where b.name='abc'驱动表被固定,大概率会扫描更多的行,导致效率降低.
--根据业务情况或sql情况,把左连接或者右连接改写为内连接
三.索引选择不同,造成性能差异较大
1.select * from t where aid= and create_name>'' order by id limit 1;
选择走id索引或者选择走(aid,create_time)索引,性能差异较大.结果集都有可能不一致
--这个可以通过where条件过滤的值多少来大概判断,该走哪个索引
四.其它一些因素
1.比如之前学习到的是否有MDL X锁
2.innodb_buffer_pool设置得太小,innodb_io_capacity设置得太小,刷脏速度跟不上
3.是否是对表做了DML语句之后,马上做select,导致change buffer收益不高
4.是否有数据空洞
5.select选取的数据是否在buffer_pool中
6.硬件原因,资源抢占
原因多种多样,还需要慢慢补充。
