You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

Teradata查询Join Index主键列时未使用该索引问题咨询

Why Your Teradata Join Index Isn't Being Used for the Query

Let's break down why your EMP_JI Join Index isn't being picked up by the optimizer for your select * from customerservice.employee where last_name = 'Brown' query:

1. Your Query Requests All Columns, But the Join Index Doesn't Cover Them

Your Join Index only includes employee_number, department_number, last_name, manager_employee_number—but your query uses select *, which asks for every column in the employee table.

Teradata's optimizer won't use an index that doesn't cover all the data needed for the query, because it would have to go back to the base table to fetch the missing columns. This "bookmark lookup" adds extra overhead, so the optimizer decides it's more efficient to just read the base table directly instead of using the incomplete Join Index.

2. Single-Table Join Indexes Aren't Optimized for Non-Join Queries

Join Indexes are primarily designed to speed up multi-table join operations. While you can create a single-table Join Index, Teradata's optimizer often prioritizes other index types (like secondary indexes) or direct base table access for simple single-table queries—especially when the index doesn't add clear value (like covering all needed columns).

3. Statistics Might Be Outdated

If you haven't collected statistics on either the base employee table or the EMP_JI Join Index, the optimizer doesn't have accurate data to compare the cost of using the index vs. reading the base table.

Try running these commands to update statistics:

COLLECT STATISTICS ON customerservice.employee;
COLLECT STATISTICS ON a.EMP_JI;

After updating, re-run the explain to see if the optimizer changes its plan.

4. The Base Table's Primary Index Might Be More Efficient

If the base employee table's Primary Index (PI) is already aligned with your filter (last_name), the optimizer might determine that accessing the base table directly is just as fast (or faster) than accessing the Join Index. Even if the base table's PI isn't last_name, if the table is small enough, a full table scan could be cheaper than navigating the index.


How to Fix This

If you want the optimizer to use the Join Index, you have two main options:

  • Restrict your query to only the columns in the index:
    EXPLAIN SELECT employee_number, department_number, last_name, manager_employee_number 
    FROM customerservice.employee 
    WHERE last_name = 'Brown';
    
  • Modify the Join Index to cover all columns (note: this increases storage overhead):
    CREATE JOIN INDEX a.EMP_JI AS 
    SELECT a.* 
    FROM customerservice.employee a 
    PRIMARY INDEX (last_name);
    

内容的提问来源于stack exchange,提问作者tonyibm

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.27 03:29:18