邓 != 邓。 这种数据是咋来的

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 OB or 其他组件 】
【 使用版本 】4.2.1-10BP
查询下面的sql。发现 邓 !=邓
第一对邓， 是我从数据库表中copy出来的。显示不相等
第二对邓，是我手打的 deng。显示相等
select ‘邓’= ‘邓​’ ,
‘邓’ = ‘邓’

image

1 个赞
#3

导致业务看起来，这种数据违反了唯一键规则。

1 个赞
#4

:+1: :+1: :+1:

1 个赞
#6

你通过哪个客户端查询的 数据库服务器上obclien客户端链接查询过么？把查询的sql文本放到文本里 发一下

#7

新建 文本文档 (2).txt (42 字节)

navicat查询的

#8

使用ob的odc查询也是一样的结果

就好像这俩字符底层是 utf8mb4编码里面，不同的编码一样。

image

#10

根据图片中显示的核心内容“旧式列别名通过等号符号”以及文本片段中的示例，可以推断用户是在处理 SQL查询中的列别名定义问题，尤其是旧式语法（使用等号=）导致的错误或兼容性问题。以下是详细解答：

问题分析

  1. 旧式列别名语法：
    • 在旧版本的SQL Server（或其他数据库系统）中，部分开发者可能使用等号（=）直接定义列别名，例如：

    SELECT '非' = 列1, '那' = 列2 FROM 表名;

    • 这种写法不符合标准SQL语法，且在新版本中可能被废弃或引发歧义。

  2. 标准列别名语法：
    • 标准SQL要求使用AS关键字定义列别名：

    SELECT 列1 AS '非', 列2 AS '那' FROM 表名;

  3. 错误示例中的问题：
    • 文本片段中的内容（如非' = ‘ 邓' = ， 那' = ， 邓' = ， 邓'）显示用户尝试用等号定义多个别名，但语法混乱且缺少AS关键字，导致解析失败。

解决方案

1. 修正列别名语法

• 错误写法（旧式等号语法）：
sql SELECT '非' = 列1, '那' = 列2 FROM 表名;
• 正确写法（使用AS关键字）：
sql SELECT 列1 AS '非', 列2 AS '那' FROM 表名;

2. 处理特殊字符和动态SQL

• 如果别名包含特殊字符（如单引号'），需用方括号或双引号包裹：
sql SELECT 列1 AS [非'], 列2 AS "那'" FROM 表名;
• 在动态SQL中拼接别名时，注意转义字符：
sql DECLARE @alias NVARCHAR(50) = '邓'; EXEC('SELECT 列1 AS ''' + @alias + ''' FROM 表名');

3. 结合索引优化查询性能

• 如果查询涉及日期字段筛选（如WHERE OrderDate > '2023-01-01'），确保已按之前讨论的方法为日期字段创建索引：
sql CREATE NONCLUSTERED INDEX IX_表名_日期字段 ON 表名 (日期字段);
• 通过正确的别名和索引设计，避免执行计划中的全表扫描，提升性能（如解决“119%”性能问题）。

错误排查与优化建议

  1. 检查执行计划：
    • 使用SQL Server Management Studio (SSMS) 查看查询的执行计划，确认是否命中索引。
    • 若出现全表扫描，检查索引是否有效或是否需要覆盖列（INCLUDE）。

  2. 更新统计信息：
    • 运行以下命令更新统计信息，确保优化器能正确选择索引：

    UPDATE STATISTICS 表名;

  3. 避免旧式语法兼容性问题：
    • 在数据库兼容性模式设置为较高版本（如SQL Server 2019+）时，旧式等号别名语法可能直接报错，需统一改用AS。

总结

• 核心问题：用户使用了旧式的等号（=）定义列别名，导致语法错误或兼容性问题。
• 解决方案：
• 改用标准AS关键字定义别名。
• 对特殊字符使用方括号或双引号包裹。
• 结合日期字段索引优化查询性能。
• 优化方向：通过语法修正和索引设计，解决性能下降（如“119%”执行时间增加）问题。

如果需要进一步分析具体查询或性能问题，请提供完整的SQL语句和表结构！

#11 
 啥乱七八糟的回答
#12

不是OB的问题，你放到其他数据库 一样的查询结果，问了一下deepseek,部分开发使用了旧式语法！！！可以问问你们开发。

#13

放到sqlserver 执行 这个查询 结果和ob里执行是一样的结果。

#14

image
确实。mysql执行也是这结果~~

#15

deepseek的回答我也没太懂，毕竟不是开发！大意就是说是使用了旧式语法导致的。

#16

应该是业务，不知道从哪copy了个邓字过来。 结果这个邓， 是个妖怪吧。

#17

image
image781×927 118 KB

#18

应该是从别的数据库移过来的时候 没注意语法问题。

#19

这种问题deepseek也能提示啊,哈哈

1 个赞
#20

obclient直连测或者obproxy链接试了么？

1 个赞
#21

感觉像是编码的问题 你这个从ob库里拷贝的么？

#22

是的。应该就是编码的问题。。 我连其他类型数据库。执行结果也是一样的。。
但是这种妖怪是咋来的···

我这直接测试了其他 汉字。 即使输入的 hang = xing。 查询结果也会是 1.
select ‘行’ = ‘行’

1 个赞
#23

image
我测试没有问题 你看看库的编码 是什么样编码