1. 애초에 설계 잘못입니다.
  - 가변길이 항목에 CHAR 를 사용한것이 문제입니다.
  - VARCHAR 로 바꿀 수 있는지 검토해 보세요.
2. 뷰를 사용할 때 속도가 안나온다면?
  - 뷰만 개선하는게 아니라
  - 뷰를 사용하는 쿼리도 함께 개선해야 합니다.
  - 뷰를 사용하는 쿼리를 보여주세요.
3. 인덱스는
  - 뷰와 뷰를 사용하는 쿼리 관련된 테이블 전체를 확인해야 합니다.
  - 실행계획은 적절한지?
  - 인덱스는 적절한지?
  - FBI 도 고려해볼 만한 대상입니다.

안녕하세요 마농님 답변 감사드립니다.

1. 애초에 설계 잘못입니다.

--> 저희쪽 테이블이 아니라 타 시스템 테이블이라서 수정이 불가능합니다. 왜 저렇게 해놓았는지 저도 의문입니다.

2. 뷰를 사용할때 속도가 안나온다면?

--> 이건 저희쪽 프로그램에서 user_id 를 가지고 조인하는데 이 user_id 가 view에서 function을 사용하고 있기 때문에 느린것 같습니다. trim(user_id)

3. 인덱스는

--> 뷰를 사용하는 테이블이 크게 많지 않기에(이용자 관련) trim(user_id)로 생성된 뷰 부분만 처리가 가능하면 좋을것 같습니다.

v_user 뷰를 사용하는 쪽 쿼리는 매우 간단합니다.

select * from v_user a, table b where a.user_id=b.user_id 정도 수준입니다.

보여주신 쿼리에 아무런 검색 조건이 없네요? 진짜인지? 질문하면서 누락하신건지?
검색 조건이 없다면? 전체 검색 쿼리입니다. 건수가 많으면 느릴 수 있구요.
조인 조건이 있는데 연결고리 한쪽이 가공(TRIM)되어 인덱스를 이용하지 못하는 상황입니다.
한쪽 인덱스를 사용하지 못하더리도 다른 쪽 인덱스를 사용할 수 있다면?
최선은 아니더라도 차선은 됩니다.
즉, 가공하지 않은 쪽에 인덱스가 있다면 큰 무리가 없을 듯 한데요?
인덱스가 있는지 확인해 보시구요.
조인 집합 양쪽의 데이터량이 얼마나 되는지?
정말 다른 검색조건은 없는지?
실행계획은 어떻게 되는지 ?
여러가지를 확인해 보셔야 합니다.
정 안되면 가공된 컬럼에 FBI 생성도 고려해야 하구요.