안녕하세요 하얀까마귀 입니다..



음.. 2차키가 뭘 말씀하시는건지 정확히 잘 모르겠네요...



인덱스의 제약을 말씀하시는건지.. 테이블 생성시 테이블의 참조키 같은걸 말씀하시는



건지요...



그런데.. 아마 제목이나 마지막에 order by에 대한 언급이 있으신걸로 보아 그냥



2차키가 인텍스라고 생각하겠습니다... (인덱스를 2차키라고 하나?? 잘모르겠당 처음



듣는것 같은데.. 아직 경험이 짧아놔서..)



인덱스에 대한 설명...



MS-SQL도 인덱스의 종류는 2가지 밖에 없죠???



클러스터 하고 넌클러스터 인덱스 하고요... 7.0에서는 넌클러스터 인덱스의 동작이



좀 변경된걸로 알고 있습니다..



음.... 이런건 넘어가고요.....



인덱스는 아주 중요합니다.. 무지무지무지..... 테이블의 설계를 하고 프로젝트를



설계할때 당연히 인덱스도 설계를 해야 합니다... 그래야 프로젝트를 수행하실때



적절한 쿼리를 사용할수 있습니다. 아무렇게나 남용한 쿼리는 프로그램 전반에



막대한 속도저하를 가져 옵니다... 테이블의 양이나 레코드 수 사용빈도와 용도를



고려해서 어떤 인덱스를 어떻게 만들지를 아주 심각하게 고려 해야 합니다...



이런 디비의 설계에 있어서 가장 중요한것이 테이블의 설계죠 하지만 이놈을 제대로된



성능으로 끌어올리는 건 인덱스가 제대로 되어야 합니다. 물론 뷰나 다른 기능들을



이용하기도 하지만 이런 복합적인 설계가 다 고려 되어 져야 합니다....



.. 쓸데없는 얘기는 이정도에서 접어두고... 더하면 재미 없겠죠? ^^;



인덱스는 그냥 목차라고 생각 하세요... 클러스터냐 아니냐에 따라서 조금 다르고



오라클의 경우에는 훨씬더 다양한 인덱스를 제공하죠...



클러스터 인덱스는 이렇게 생각하시면 되겠네요... 클러서터 인덱스는 키 인덱스라



생각하세요... 키를 생성하면 이놈이 자동으로 생성 되죠..



이놈의 순서와 테이블의 순서가 동일합니다.. ..



한번 생각해보세요.. 이렇게 순서대로 1 - 1000 까지 쭉 나열해놓고



'300을 찾아라' 라고 한다면 이놈의 서버가 얼마나 쉽게 찾겠는지..



'흥 그정도 쯤이야!!! 자! 여기있어' 하겠죠...



그리고 여러건이다.. 그것도 마찬가지겠죠??? 순서대로니까... '



'200 - 500을 보여줘'



'흥 이것도 별거 아니구만!! 짜자잔 여기있지롱!! '



그러겟죠... 어!! 그럼 클러스터가 좋은거네??? 넌클러스터는 그럼 뭐하는거야...?



라는 의문이 생가죠?? 넌 클러스터는 디비의 실제 순서와 인덱스의 순서가 다릅니다.



클러스터 인덱스는 200 하면 그냥 순서대로니 200을 가져다주고 다음다음 하면서

500까지 가져오면 되겠죠///



'RowID' 아세요??? 인덱스는 실제로 하드의 물리적 주소를 가지고 있죠.. 이것으로



참조해 들어 가게 됩니다.. 실제로 어떠한 where 조건 문보다 이놈의 값을 where문으



로 넘겨주면 가장 빠른 결과를 볼수 있습니다..



하지만 넌클러스터는 그렇지 못합니다...



100-200까지 가져와라.. 하면 이놈은 자신의 목록에서 100 - 200을 찾아 옵니다..



하지만 이것과 실제 디비의 위치와는 같다고 할수 없죠..



'값이 100인 놈의 주소는 A동 21호구나' -> A동 21호를 찾아 갑니다..



'A동 21호 너 이리와' <- 데이타를 데리고 옵니다..



이 작업을 조건내의 모든 데이타에 대해 이런 동작을 합니다...



그래서 인덱스의 속도는 인반적인 상황에서 클러스터가 빠릅니다..



하지만.. 문제가 있죠.. 수정이나 새로운 대이타의 저장의 경우... 이놈이 클러스터의



입장에서 볼때 중간에 끼어드는 놈이면 물리적 주소또한 중간에 끼워 넣어야 합니다..



수정을 생각해보세요.. 이놈 어떻게 될지 모르게되죠...



그래서 수정이나 신규 데이타 저장시 이놈은 무척 느린동작을 보여 줍니다..



하지만 이런 부분에 대해서 넌클러스터는 아무 걱정이 없죠...



단지 순서를 지켜야 하는건 넌클러스터 인덱스이지 실제 데이타가 아니거든요..



데이타는 맨 마지막에 있더라도 인덱스의 순서만 맞으면 되니까....



- 조금 쉽게 설명을 하자면



종종 클러스터 인덱스는 책의 앞부분에 있는 목차에 비교 되고



그리고 넌클러스터 인덱스는 책의 제일 마지막에 있는 찾아보기에 비교 됩니다...



목차는 목차의 순서와 책의 실제 페이지 순서와 동일 합니다.. 중간에 1페이지를



넣으려면 이 인덱스를 수정하는건 당연하고 책또한 찢어서 중간에 이 페이지를 끼워



넣는 겁니다... ( 실제로는 훨신 더 복잡하게 동작합니다.)



넌 클러스터 인덱스는 찾아보기니까 그럴필요 없겠죠..?? 그냥 책의 제일 마지막에



넣어 버리고 그놈의 페이지를 1001이라고 넣고 인덱스는 다시 정렬을 해야 겠죠...



테이블은 두고 인덱스만 다시 정렬하면 되니까 책을 찢어가면서 중각에 끼워넣는건



안해도 되죠....



------------------------------------------------------------------------------



그럼 이러한 인덱스를 만드는게 왜 중요한가.....



당연하겠지만... 목차가 없는 책을 생각해 보세요.. 찾아보기가 없는 책을 상상해



보세요.. 으앙....



프로그래머 :'야 너 107번하고 같은 번호 찾아와'



서버 :'잉??? 107이 어디쯤 있는데???? 난 모르는데???? 안되겠구만 다 뒤져야지..?'



이렇게 얘기하고 서버는 테이블의 처음부터 그러니까 책의 첫페이지 부터 마지막 페이지



까지 다 읽을때까지 107이란 놈을 찾고 있는 겁니다....



이건 서버에게 똥개 훈련 시키는 겁니다...



책의 페이지가 뒤죽박죽인지 차례대로 되어있는지 서버는 모르는 겁니다..



클러서터 인덱스는 차례대로 정렬을 해놓으면서 그것의 목차를 만드는 거고



넌 클러스터는 그냥 페이지는 차례대로 그냥 임의로 붙여 버리고 자신의 순서에 맞추는



겁니다...



헉헉.. 조금 힘들다....



이런 저런 잡다하고 쓸데 없는 이유들로 서버에게 똥개 훈련을 시키지 않기 위해...



왜?? 서버는 놀고 싶어 하니까... ( 늘 유유자적하길 원하는 자유인이니까 )



이러한 인덱스를 만드는 겁니다... 그런데 문제가 또 남았어요..



으악??? 또 뭐야.......



아무리 인덱스를 잘 만들고 아무리 테이블 설계를 잘 했다 하더라도 프로그래머가



SQL문 하나를 잘 못써서 서버의 속도가 저하되는 경우가 많습니다...



from 절의 테이블 순서.. where절의 조건 순서와 where절에 있는 필드의 종류



테이블의 조인 , 연산자의 사용방법, in, not,like 기타 등드의 예약의 사용밥법



등에 의해 이놈의 결과가 천차 만별 입니다...



( 이부분은 책을 참고 하시길.. 이거 분량이 장난이 아니거든요 )



하지만.. 그냥 넘어갈수 있는가... 맞배기라도 봐야지...



아주 기본적인 ( 이건 내가 생각나는 몇가지 이다 왜 내맘이니까 ) 몇가지만을



기술 할께요..



'like' 이놈은 아주아주아주아주아주(아무리 강조해도 지나치지 않습니다)



정말 꼭 필요하다고 생각되는 부분에만 사용해야 합니다.. 이놈은 테이블에 클러스터가



있든 넌 클러스터 인덱스가 있든 없든 무조건 무시해 버립니다...



like는 테이블 full scan의 대표적인 예라고 볼수 있습니다...



'or' 보다는 in을 사용하라.. 이것 또한 잘 알려진 사항입니다... where문에



or 문을 여러개 사용하는것 보다 in이 훨씬 나은 퍼포먼스를 보여줍니다...



남용되는 함수들....( 함수를 남용하지 말라.. 프로그램에서 할수 있는건 프로그램에서



하고 꼭 sql에서 함수를 써서 해야 되는건 사용하되.. 어느쪽에 있어도 상관이



없는건 프로그램에서 함.. ( 프로그램에서 전체 결과에 대해 어떤 함수를 사용해야



되는 경우는 극히 드물다 ( 이걸 써야 한다면 테이블 설계에 대해 내가 잘한 짓인지



한번쯤.. 가볍게 생각해 볼 필요가 있다.. 이부분으로는 sub Query가 있는데...



이놈을 극히 부분적이 아닌 가끔 또는 종종이란 단어가 들어간 말을 하게 끔 테이블을



설계 했다면.. 내 설계능력을 심각하게 의심해 볼 필요가 있다... 극히 부분적으로는

어쩔수 없이 하는 경우가 있다... 이놈들 나중에 가서 딴소리 하니까.. 그렇다고



다시 만들수 없잖아.... 흑흑 //



조건의 필드에 함수를 사용하는건 피해야 합니다.



where substr(SaBun,1,2) = '50'



이렇게 쓰는것 보다는



where Sabun >= 50 이것의 결과가 낫습니다...



그리고 서브쿼리는 정말 불가피한 상황이 아니라면... (머리쥐어뜯고 담배를 피며



난 왜이럴까를 마음속으로 수십번을 되뇌이면서도 해결방법이 서브쿼리 밖에 없다면



그때 서브쿼리를 사용하라) 사용해서는 안됩니다... 이건 무척 심각해 지거든요..



sql문을 사용할때 어떤 인덱스를 사용해서 쿼리를 할지에 대해 먼저 생각을 하고



만들어야 합니다.. 그래야 정확히 원하는 속도를 얻을수 있을겁니다...



튜닝이라는걸 보면 하드웨어나 구조적인 튜닝은 무척 힘이 듭니다.. 개발기간이라던지



비용적인 측면이 따라다니고 구조적 재설계는 개발비용에 인력과 시간이 투자되어야



하기에 정말 어렵습니다.. 그래서 일반적으로 튜닝이라함은 그러한 것은 좀 제외하고



그외적인 부분에서 속도향상을 올리는걸 말합니다...



수시간 짜리를 단지 몇분에 만들수도 있습니다..



(제가 처음 디비를 공부할때 수백만개의 테이블 두개가 master/detail로 돌아가는데



처음엔 데이타가 이렇게 많은줄 몰랐고... (처음 배울때라 업무분석은 제가 안했거든



요) 또 그렇게 까지 느릴것이라고는 생각을 못했죠...



그런데.. 이놈이 좀 복잡한 리포트는 거의 1시간을 기다려야 결과가 나오는 겁니다..



그래서 이놈들을 점부 뜯어 고치기 시작했죠... 프로젝트에 포함된 pas만 300개에



달하는 결코 작지는 않은 일이었죠... 하나하나 고치면서 단축되는 시간을 보니 거의



혁명적이더라구요... 처음 조회시 10-30초 사이 이던 속도가 1초 미만으로 줄어 들었고



1시간을 기다려야 겨우 결과가 나오던 리포트는 30여초면 해결이 되었죠...



얼마나 쿼리를 막썼는지에 대한 단적이 예라고 볼수 있겠죠.. 흑흑....



( 그래 나 무식하게 만들었다.. ... ^^; )



--------------------------------------------------------------



인덱스는 어떤 조회를 할꺼고 또 어떤순서로 보여줄건지에 대해 먼저 프로젝트 전반에



대한 생각이 있어야 합니다... .. 인덱스의 순서도 조금 중요한데.. 이걸 결과의



순서와 맞추어 주면.. 이 인덱스를 사용했을경우 order by를 주지 않아도 정렬이 됩



니다... 이건 속도향샹에 크게 기여하죠..



쿼리 한번할때마다 하나의 인덱스를 만든다면 조회속도는 빨라질수도 있겠지만..



결과적으로 insert, Update, Delete의 동작이 무지 느릴겁니다..... 수많은 인덱스



도 함께 유지해야 하니까...



--------------------------------------------------------------



조금 도움이 되셧나 모르겠네요... ms_SQL의 인덱스에 대해 아는건 이정도네요...



이것 밖에 몰라서인지는 모르겠지만. 전 개인적으로 오라클을 더 좋아하죠...



오라클의 익덱스는 종류가 무지 많거든요?///????



-------------------------------------------



이반적으로 인덱스와 Full Scan의 경우 사람마다 의견이 조금씩 다르지만...



전체 테이블의 15- 20( 이게 사람마다 다르거든요? 15% 정도라고 말하는 사람도 있고



20%나 그것 20여%라고 이야기 하는 사람도 있죠.. 하지만 대충 이정도 라고 알아 두시



면 되겠네요.. 이상의 결과를 쿼리하길 원할때는 index를 사용하는 것 보다 Full Scan



하는게 빠르다고 알려져 있다.



--> 이건 인덱스를 참조해서 결과를 얻기위해 서버의 똥개 훈련이 장난의 수준은 아니라



는 단적이 증거라고 볼수 있겠네요...



--> 아!!! 마지막으로 한거지더.. SQL 7.0에서 달라진게 조금 있는데 그중에서...



넌 클러스터 인덱스는 다른 디비도 마찬가지고 이놈은 하드의 물리적 주소를 가지고



있습니다... 정렬된 값들과 함께.. 이값으로 실제의 테이블을 찾아 가게 됩니다..



그런데.. 6.5까지는 이렇게 했는데... 7.0 에서는 클러스터 인덱스가 없는경우에는



이런식으로 동작을 하고 클러스터 인덱스가 있는경우에는 이 넌클러스터 인덱스가 가르



키는 곳이 실제 테이블이 아닌 넌클러스터 인덱스 입니다...



아직 왜 이렇게 했고 장점이 무엇인지까지는 잘 모르겠습니다만.. 뭔가 좋은 장점이



있으니 이렇게 만들었겠죠???



헉헉.. 여기까지 오느라고 많이 지치셧죠.. 이제 다 오셧으니 좀 쉬시죠...



에구 나도좀 누워야 겠당...



그럼.. 즐거운 시간 되세요...



- 하얀까마귀 -







상아 wrote:

> 안녕하십니까? 궁금한게 있어서...이렇게 도움 청할까 합니다...

> 제가 sql 7.0 을 쓰는 완전 초보입니다..

> 여기서도 테이블 구조 생성시...주키(우선키) 와 2차키를 설정할수 있는데...

> 제가 써보니깐...주키는 필요한데....

> 2차키는 전혀 필요없는게 아닌가 하는 생각이 들었습니다..

> 왜냐 하면...제가 조회하는 부분는 모두 Query 를 이용하면서 order by 문으로

> 원하는 순서대로 모두 처리 했기 때문입니다...

> 그래서 그런데... 2차키가 어떤 경우에 필요한지, 유용하게 쓸려면 어떤 경우인지...

> 알고 싶습니다....

> 어떤 경우가 있을까요 ?

> 도움 부탁 바랍니다...

> 그리고 감사합니다.

>