1.老师好
2.如果在用一个 MySQL 关键字做字段,并且字段上索引,当我用这个索引作为唯一查询条件的时候 ,会 造 成隐式的转换吗?
例如:SELECT * FROM b_side_order WHERE CODE = 332924 ; (code 上有索引)
3. mysql5.6 code 上有索引 intime 上没有索引
语句一:
SELECT * FROM b_side_order WHERE CODE = 332924 ;
语句二;
  UPDATE b_side_order SET in_time = '2018-08-04 08:34:44' WHERE 1=2 or CODE = 332924;

这两个语句 执行计划走 select 走了索引,update 没有走索引 是执行计划的bug 吗??

 

老师您好，有个问题恳请指教。背景如下，我长话短说：

mysql>select @@version;
5.6.30-log

 CREATE TABLE `t1` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL, `plan_id` int(11) NOT NULL DEFAULT '0' , PRIMARY KEY (`id`),
  KEY `userid` (`user_id`) USING BTREE, KEY `idx_planid` (`plan_id`)
) ENGINE=InnoDB DEFAULT CHARSET=gb2312;

 CREATE TABLE `t3` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `status` int(4) NOT NULL DEFAULT '0',
  `ootime` varchar(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_xxoo` (`status`,`ootime`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

t1 和 t3 表的字符集不一样

sql 执行计划如下：
explain
SELECT t1.id, t1.user_id
  FROM t1, t3
 WHERE t1.plan_id = t3.id
   AND t3.ootime < UNIX_TIMESTAMP('2022-01-18')
+----+-------------+-------+-------+---------------+--------------+---------+--------------+-------+----------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+--------------+---------+--------------+-------+----------------------------------------+
| 1 | SIMPLE | t3 | index | PRIMARY | idx_xxoo | 51 | NULL | 39106 | Using where; Using index |
| 1 | SIMPLE | t1 | ref | idx_planid | idx_planid | 4 | t3.id | 401 | Using join buffer (Batched Key Access) |
+----+-------------+-------+-------+---------------+--------------+---------+--------------+-------+----------------------------------------+

我的疑惑是
1)t3 的 status 没出现在 where 条件中，但执行计划为什么用到了 idex_xxoo 索引？
2)为什么 t3.ootime 也用到索引了，从 key_len 看出。t3.ootime 是 varchar 类型的，而 UNIX_TIMESTAMP('2022-01-18') 是数值，不是发生了隐式转换吗？

请老师指点。

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.硬件原因,资源抢占
原因多种多样,还需要慢慢补充。

老师我问一个问题:
连接列上一个是int一个是bigint或者一个是char一个varchar,为什么被驱动表上会出现(using index condition)?