br/Lightning之后索引出问题了

[TiDBer_yangxi]

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

从7.1.1，br 到7.5.1的数据，没发生变化
SELECT * from rel_user_organization where org_id =‘1ce8c8c12ac24a57bb07734df5ec5120’;查不出数据
SELECT * from rel_user_organization where trim(org_id) =‘1ce8c8c12ac24a57bb07734df5ec5120’; 能查到数据
select length(org_id) from rel_user_organization; 结果是32
很奇怪

mysql> select distinct length(org_id) from rel_user_organization;
±---------------+
| length(org_id) |
±---------------+
| 32 |
±---------------+
1 row in set (0.00 sec)

建库语句都是create database xxx DEFAULT CHARSET utf8 COLLATE utf8_general_ci;

[tidb狂热爱好者]

br不能垮版本搞物理数据

[TiDBer_yangxi]

全用7.1.1的br处理可以吗，数据我看都写进去了，也都能查出来，就是这个字符串很奇怪

[tidb狂热爱好者]

你用sql还原吧 lighting

[TiDBer_QYr0vohO]

br要保证上下游TiDB版本一致

[h5n1]

[DBAER (66666)]

物理备份恢复都要版本一致

[TiDBer_yangxi]

我刚才把7.5.1销毁了，重建了7.1.1还是有一样的问题，这下两个集群一致了，我试了是字符串查询有问题，数字没问题

[WalterWj (王军 - PingCAP)]

两个集群的 new collation 配置一样么

[TiDBer_yangxi]

一样的，都是true，这玩意br的时候有检查，必须一致的

[TiDBer_yangxi]

我发现create table ** like *; 再insert 就能查出来了

[TiDBer_yangxi]

我把两个集群都搞成了7.1.1然后用lightning 同步的数据，还是出现了问题

感觉是有什么参数在影响着字符串比较
两个集群new_collation_enabled 都是False
mysql> SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME=‘new_collation_enabled’;
±---------------+
| VARIABLE_VALUE |
±---------------+
| False |
±---------------+

[TiDB_C罗]

计算一下md5值呢

[TiDBer_yangxi]

一致的

[TiDB_C罗]

导到mysql上试试

[erwadba]

admin check table <table_name> 看看是否有报错。
另外看看两个sql走的执行计划是否一致。

[zhanggame1 (Ti D Ber G I13ecx U)]

hex函数看看16进制的字符串是否一样，如果不一样那就是存储的值有问题，如果一样字符集和排序有问题

[zhaokede]

上下游的字符串完全一致吗。
字符集还是用utf8mb4

[TiDBer_yangxi]

check没问题，两个集群的执行计划一样，两个sql执行计划不一样，

一个走索引是range，一个是eq

[TiDBer_yangxi]

lighting过来的，字符集肯定一样的，建表语句都是一样的