配置大小写不敏感字符集引起的性能下降

Hacker007 · 2022 年6 月 27 日 09:56

图一是大小写敏感的字符集，图二配置的是大小写不敏感的字符集，两边的查询时间想差有点大？这怎么回事

tidb狂热爱好者 · 2022 年6 月 27 日 10:01

你能把sql发出来看看吗我们也配置了大小写不敏感

Hacker007 · 2022 年6 月 27 日 10:03

SELECT os.id as telemarketId, oi.orderNo as orderNo, rr.backTime as backTime, IF(os.id is null,0,1) as flag
FROM test_info oi
LEFT JOIN rent_test rr on rr.rentRecordNo = oi.orderNo
LEFT JOIN test_snapshot os on oi.orderNo = os.orderNo
where rr.state > -6 and IFNULL(rr.backTime,‘0000-00-00 00:00:00’) != IFNULL(os.backTime,‘0000-00-00 00:00:00’)
limit 10; 配置了大小写不敏感后，日期还要格式化

Hacker007 · 2022 年6 月 27 日 10:03

你们的查询性能怎么样？

xfworld · 2022 年6 月 27 日 14:20

看下执行计划吧，透过执行计划很容易判断出问题的

我猜测可能是：

隐式转换导致的索引被跳过了
不走索引，全表扫描就会慢很多

tidb狂热爱好者 · 2022 年6 月 27 日 16:44

SELECT os.id as telemarketId, oi.orderNo as orderNo, rr.backTime as backTime, IF(os.id is null,0,1) as flag
FROM test_info oi
LEFT JOIN rent_test rr on rr.rentRecordNo = oi.orderNo
LEFT JOIN test_snapshot os on oi.orderNo = os.orderNo
where rr.state > -6 and IFNULL(rr.backTime,‘0000-00-00 00:00:00’) != IFNULL(os.backTime,‘0000-00-00 00:00:00’)
limit 10;

where不等式的左边不能用函数
会走全表扫描

西伯利亚狼 · 2022 年6 月 28 日 00:36

1、你把sql转成全小写的试试，估计也一样。
2、看下执行计划。

ddhe9527 · 2022 年6 月 28 日 01:13

检查一下test_info、rent_test和test_snapshot这三张表的字符集和排序规则是否一致

我是咖啡哥 · 2022 年6 月 28 日 01:23

只改了部分表的部分字段吧？确认下你关联的字段字段类型、排序规则是否都一致。

Hacker007 · 2022 年6 月 28 日 01:38

都一致，都是同步于上游mysql

Hacker007 · 2022 年6 月 28 日 01:38

都一样的

ddhe9527 · 2022 年6 月 28 日 02:52

同一个SQL这两种场景下的执行计划发一下看看呢

xuexiaogang · 2022 年6 月 28 日 03:46

应该是一个用索引了，另外一个全表。

Hacker007 · 2022 年6 月 28 日 03:49

性能是个问题，还有一个最大的问题是日期格式的转换，

Hacker007 · 2022 年6 月 28 日 03:52

有的查询执行计划是不一样的

首先可以肯定数据和表结构两边都一样

caiyfc · 2022 年6 月 28 日 03:58

右边这么多空白，你就把每一列稍微拉宽一点呀，第一列都被遮住了，其他信息也被遮住好多。你这属于无效回复了

xfworld · 2022 年6 月 28 日 07:36

我们关注的东西，你都不放出来
这样子帮不了你…

Hacker007 · 2022 年6 月 28 日 08:58

现在不只是性能问题，而是语法执行失败

Hacker007 · 2022 年6 月 28 日 08:58

你看上面回复你的，是执行失败，似乎是个bug

xfworld · 2022 年6 月 28 日 09:20

你的用的什么版本呢