인덱스를 거론하면서 어떻게 * 를 설렉트해 오셨는지

그게 제일 궁금하구요

만약에 변수로 안된다면

exec(@sql) 로 하면 안될까요?

proc_dt 칼럼은 datetime이겠죠..

그리고, 인덱스 걸려있다면 위 두 경우 모두 인덱스를 탈 것 같은데요..

다시 한 번 확인해 보세요..

그럼..

p.s. 칼럼명을 전부 표기하면 질문내용이 보기 어려워질 수 있어서 독자를 위해서 간단히 * 했을 가능성이 높지 않을까요? ^^*

(참고로, *와 인덱스와의 관계는 별로 없지 않나여~.. ^^;;

물론 covered index query는 제외함돠~)

전 커버드 쿼리나 데이터의 출력량을 생각해서 드린말이구요

시간이네요 전 그냥 변수로 하면 안된다 하길레 그럼

동적 sql 로 하면 그냥 하는거랑 같으니 되지 않겠나 하는 견해 였습니다.

나그네님 넘 날카로워요 ^^;

[박은희님의 code중에서..]

declare @eDate varchar(8)

select @eDate = '20050701'

==> set @eDate = '20050701'

으로..

참고로, 이하 샘플 코드입니다..

create table tmp (
  proc_dt datetime
, dmy char(200)
)
go

set nocount on
declare @dt datetime
set @dt = '2005/01/01'
while (@dt <= '2005/07/26')
begin
  insert into tmp values (@dt, '')
  set @dt = dateadd(day, 1, @dt)
end
set nocount off
go

select top 10 * from tmp
go

create index idx_tmp on tmp (proc_dt)
go

set statistics io on
set statistics profile on
go

select * from tmp
  where proc_dt = '20050701'
 
declare @eDate varchar(8)
set @eDate = '20050701'

select * from tmp
  where proc_dt = @eDate
go

set statistics io off
set statistics profile off
go

drop table tmp

위의것은 예를 들어서 한경우입니다.^^;;

보통은 커리나 프로시져에서

변수에 담았다구 해서

인덱스를 안타거나 하지 않는데,

가끔 복잡한 커리라서 그런지 그런일이 실제 발생하더라구요.

현재 운영하고 있는데

속도 개선을 위해 보는중에 발생한 문제 입니다.

프로시져를 안쓰고 asp로 다 커리를 빼낼까 생각중입니다.

여러분들은 그런 경우가 없으셨나보네요.

답변 감사 드립니다..^^

자세한 상황은 잘 이해할 수 없습니다만..

일반적으로,

여러 잇점을 위해서 query는 sp형태를 가져가는 것이 좋습니다..

물론 performance 향상을 위해서도요..

많은 분들이 sp로 구현하는 것을 절대적으로 추천하고 있는 것으로 알고 있습니다..

다만, sp내에서 구현되어 있는 query 문 자체로 인해 performance가 떨어지는 경우가 대부분입니다.. 이 경우는 asp로 뺀다고 해서 향상될 수 있는 부분은 아니겠죠..

저는 DBA가 아닙니다만(그렇다고 해서 app개발자도 아니지만.. -_-;;), asp에 query가 구현되어진다면 나중에 DBA분께서 엄청 고생하는 상황이 발생할 수 있으리라 봅니다.. app개발자가 구현하는 query문과 dba가 구사하는 query는 결과set은 같을 지 몰라도 내용은 전혀 다를 것이기 때문입니다..

그럼..

p.s. app 개발자의 db에 대한 이해 혹은 능력을 비하할 뜻은 전혀 없음을 밝힙니다.. 고수분들도 상당 수 계시지만, 상당히 비효율적인 query를 구사하는 개발자가 다수인 것으로 듣고, 알고 있습니다.. 어쨌던 개발자도 db 공부해야 하는데.. ^^*

될수 있다면 꼭 sp 를 쓰길 바랍니다.

sql injection 등의 보안 헛점도 있고,

sp 가 나중에 유지보수가 훨 쉽습니다.

전 능력이 된다면 다 sp 로 빼라고 추천하고 싶습니다.

똑같은 기능 델파이 c# 으로 구현해라 하면

일일이 쿼리문 짜고 있지 않아두 되니 말입니다. ^^;

박은희님께

전 그런경우를 못 봐서 이렇게 질문 올립니다.

과연 ad-hoc 쿼리로는 인덱스를 타는데 stored procedure 로 했을때

인덱스를 못타는 경우를 한번 직접 예를 보여주세요

그럼 제가 꼭 찾아 보겠습니다.

^^;

프로시져에서 리컴파일 문제가 일어나는지 쓸때없는 형변환이 일어나지 않나 조사해 보고 실제 프로필러의 io 까지 뒤져서 함 찾아 보겠습니다. 좋은 공부가 될거 같은데요 ^^;

create table tmp (
  proc_dt datetime
, dmy char(200)
)
go

set nocount on
declare @dt datetime
set @dt = '2005/01/01'
while (@dt <= '2005/07/26')
begin
  insert into tmp values (@dt, '')
  set @dt = dateadd(day, 1, @dt)
end
set nocount off
go

select top 10 * from tmp
go

create index idx_tmp on tmp (proc_dt)
go

set statistics io on
set statistics profile on
go

 
select * from tmp
  where proc_dt = '20050701'
 
declare @eDate varchar(8)
select @eDate = '20050701'

select * from tmp
  where proc_dt = @eDate
go

set statistics io off
set statistics profile off
go

drop table tmp

위 코드는 나그네님 코드에서 은희님의 코드에서 지적하신 select -> set 으로 바꿔라 라는 대목에서 의심이 나서 실행해 보았습니다.

용도에 따라 틀릴 뿐이지 같다라고 알고 있었거든요

제가 실제 테스트 해보니 같은데요 뭘 지적한지 잘 모르겠습니다.

실행 계획 및 결과 모두 일치하는데요  무엇을 설명하실려고 한건지 잘모르겠습니다. 그냥 단순히 값을 할당 할때 set 으로 하는게 좋지 않겠냐 하는 견해 인지 아니면 index 를 타고 안타고 에서 저게 문제가 있는건지 ^^; 한수 부탁드립니다. 심오한 차이가 있을까요 ??

죄송..

select => set은 실수했네요..

제 습관이라서.. 그만.. ^^;;

특별한 경우가 아니면, 일반적으로 set을 사용합니다..

읽기가 쉬워서요..

그외 별다른 이유는 없습니다.. (죄송.. ^^;;)

^-^