Teradata查询与导出行数不一致及迁移BigQuery数据差异问题

示例建表语句：create multiset table Test(a int,b varchar,c varchar,d timestamp(6)) primary index (b);

Teradata 主索引（PI）的核心逻辑是通过对PI列值做哈希计算，将数据分配到对应AMP节点存储，查询时也会对查询条件的PI值做相同哈希计算，直接命中对应AMP检索数据。你遇到的查询不到但导出可见的问题，本质是PI列插入时的隐式类型转换导致哈希分布异常：

• 你的表PI列b为VARCHAR类型，插入该异常行时传入的是DATE类型的输入值，Teradata自动触发隐式转换：计算哈希值分配存储节点时，直接用原始DATE类型的值计算哈希，写入磁盘时才将值转为VARCHAR格式存储。
• 执行SELECT查询时，你传入的PI查询条件是字符串类型，系统会按VARCHAR类型计算哈希值，去对应AMP检索，但该行实际存储在DATE值哈希命中的AMP上，因此查询不到。
• 全表导出/导出Excel的操作会遍历所有AMP的全部数据块，不需要通过PI哈希检索，因此可以识别到该行。

针对大表场景，可以通过以下几种方式快速定位异常行，无需全表导出排查：

• 隐式转换可能性校验：通过TD_TRY_CAST函数筛选出PI列中可被隐式转为DATE的异常值，参考查询：

SELECT * FROM Test
WHERE TD_TRY_CAST(b AS DATE) IS NOT NULL;

• 哈希一致性校验：对比每行基于VARCHAR计算的预期存储AMP和实际存储的AMP，直接定位哈希不匹配的异常行，参考查询：

SELECT a,b,c,d,
       HASHAMP(HASHBUCKET(HASHROW(b))) AS expected_varchar_amp,
       HASHAMP(HASHBUCKET(HASHROW(TD_TRY_CAST(b AS DATE)))) AS actual_date_amp
FROM Test
WHERE expected_varchar_amp <> actual_date_amp;

• 会话级禁用隐式转换排查：关闭会话的隐式类型转换开关后执行全表扫描，类型不匹配的行直接触发报错，即可定位问题数据：

SET SESSION PARAMETER IMPLICIT_DATA_CONVERSION = OFF;
SELECT * FROM Test;

定位到异常行后，先备份该行原始数据，删除原异常行，将PI列值显式转为VARCHAR类型后重新插入，确保插入时输入值类型和PI列定义完全一致，避免再次出现哈希分布异常。

内容的提问来源于stack exchange，提问作者prathap chowdary