Embed Size (px)
DESCRIPTION
SQL Server 2000 튜닝. 이 정 무 의료정보연구소장 [email protected] MDSaver.net. Agenda. 튜닝에 대한 명확한 이해 인덱스에 대한 이해와 적용 RDBMS 에 대한 이해와 제대로 된 SQL 작성하기. 1. 튜닝에 대한 명확한 이해. A. 튜닝이란 ? 요청한 Data 관련 작업을 처리하기 위해 최적의 I/O 처리 및 프로세스 처리 환경을 만들어 주는 것이다 . B. 튜닝은 누가 하는 것인가 ? 옵티마이져 ? 사람 ? C. 튜닝의 영역 - PowerPoint PPT Presentation
Citation preview
Agenda
1. 튜닝에 대한 명확한 이해2. 인덱스에 대한 이해와 적용3. RDBMS 에 대한 이해와 제대로 된 SQL
작성하기
1. 튜닝에 대한 명확한 이해A. 튜닝이란 ?
요청한 Data 관련 작업을 처리하기 위해 최적의 I/O 처리 및 프로세스 처리 환경을 만들어 주는 것이다 .
B. 튜닝은 누가 하는 것인가 ? 옵티마이져 ? 사람 ?
C. 튜닝의 영역I. 프로그램 관련
처리 로직의 튜닝 관련 SQL 튜닝
II. 시스템 관련
10000 * 100byte
1000M
10000 10
10000 * 10 * 100byte
10000M
10000 * 10 10 * 10
10 * 100byte
1M
10 10
10 * 10 * 100byte
10M
10 * 10 10 * 10
처리 로직 수정을 통한 튜닝 예
DB Server Web Server
DB Server
DB Server
DB Server
Web Server
Web Server
Web Server
select m.m_id,m.name,salery + isnull(Totalbonus,0) as bonusfrom member mleft outer join (select m_id,sum( case l_id
when 1 then 10when 2 then 20when 3 then 30end ) as Totalbonus
from actwhere aday between '20011001' and '20011031'group by m_id) bonuson m.m_id = bonus.m_id
declare @member table(m_id varchar(10)
, name varchar(20), salery int)
declare @m_id varchar(10),@name varchar(20),@salery int,@total int DECLARE member_cursor CURSOR FOR SELECT m_id, name, saleryFROM member
OPEN member_cursor
FETCH NEXT FROM member_cursor INTO @m_id, @name, @salery
WHILE @@FETCH_STATUS = 0beginselect @total = sum( case l_id when 1 the
n 10 when 2 then 5 when 3 then 15 end) from actwhere m_id = @m_id
select @salery = @salery + isnull(@total,0)
insert @member values( @m_id,@name,@salery)
FETCH NEXT FROM member_cursor INTO @m_id, @name, @salery
endselect * from @memberCLOSE member_cursorDEALLOCATE member_cursor
SQL SQL 수정을 통한 튜닝 예수정을 통한 튜닝 예
OPTIMIZER 란 무엇인가 ?
Select colA, colB,count(colc)from TabAwhere colD = 'A01'group by colA,colB
SQL해석
실행계획수립
실행결과
OPTIMIZER
Table, IndexView, Function…
참조
가장 최소의 비용으로 처리하는 방법을 찾기 위해 사용할 수 있는 정보 (인덱스 , 클러스터 , 데이터 크기 , 각종 통계 자료 등 ) 를 참조하여 내부 알고리즘 규칙에 따라 최적의 방안을 찾아내는 역할 .
IPTIMEZER 는 주어진 조건에서 최적의 방안을 찾아낸다 . 주어진 조건을 만드는 것은 ? 사람
RDMS 의 이해
1960 년대 : 계층형 DBMS (HDB)
1970 년대 : 망형 DBMS (NDB)
1970 Dr. E. F. Codd. “A relational Model for Large Shared Data Banks”
1970 년대 중반 Inverted List DBMS 상품 : ADABAS, SYSTEM2000
1979 최초의 상용 RDBMS 출연
1986 ANSI SQL 표준 제정
1990 OLTP 사용가능
1994 분산 DB, 병렬처리 등 출현
1997 ORDBMS, OODBMS
DBMS DBMS 의 역사의 역사
DBMS 의 특징들메터데이터에 데이터의 관계나 특성들을 기록
- 모든 처리는 DBMS 를 통해야 한다
사용자 중심의 데이터 처리
- 데이터간의 복잡한 관계들을 DBMS 가 처리 . 데이터 처리가 용이
DBMS 가 시스템으로부터 구조적 종속과 데이터 종속을 제거
- 데이터베이스 파일에서 발생하는 변경 사항들은 데이터 사전에 자동적으로 기록됨으로써 , 변경된 파일에 관계된 모든 프로그램들을 수정해야 하는 부담을 줄임 .
동시성 제어 기능
장애가 발생했을 때 복구 시키는 복구 (Recovery) 기능
사용자의 질의를 효율적으로 처리하는 질의 처리 기능 (Query Processing) 기능
데이터베이스에 대한 접근의 통제 및 개인 정보를 보호하는 보안 (Security) 기능
A
B
F
C
D E G H
I J
Root Segment
Root 1 Segment
Root chilren
Root 2 Segment
Root 1 chilren
Root 3 Segment
Root 2 chilren계층형 경로로 접근 : A B E J
DBMS 종류 ( 계층형 데이터베이스 )- 예
장점일대다 (1:M) 관계의표현이용이 데이터무결성처리가용이
단점 데이터저장의물리적구조에대한지식을요구 데이터베이스 구조상의 변경은 이 구조를 참조했던 모든 응용프로그램들에 대한 수정을요구 계층형모델은일대다의기준에맞지않는일반적인관계는구현하기가매우어렵다 .
교수번호 이름 학과
학번 이름 학년 과목번호 과목명 학점수
학번 과목번호 성적
지도
교수
학생강의
과목
신청 개설수강
엔터티 교수 ( 교수번호 , 이름 , 학과 )
엔터티 학생 ( 학번 , 이름 , 학년 )
엔터티 과목 ( 과목번호 , 과목명 , 학점수 )
엔터티 수강 ( 학번 , 과목번호 , 성적 )
Relationship 지도
OWNER 교수
MEMBER 학생
… 강의 , 신청 , 개설
DBMS 종류 ( 망형 데이터베이스 )-예
장점
다대다 (m:n) 관계가 계층형 모델보다 더 쉽게 구현
데이터 접근에 대한 유연성이 계층형보다 우수
단점
계층형 모델과 거의 비슷 : 근본적인 문제 해결이 안 됨 .
회사는 직원들을 급여 , 주소 , 이름 등의 정보를 관리한다 . 회사에서는 선행 제도에 대한 보너스 제도가 있다 . 선행 리스트에 있는 일을 했을 때 그에 적용된 보너스를 한 달 단위로 합계를 내어서 기본 급여에 더해서 지급한다 .
선행한 일
사원* 사원번호이름주소본봉
선행리스트* 리스트번호선행내용보너스
선행한 일을 하다
DBMS 종류 ( 관계형 데이터베이스 ) - 예
ABC
xy
AABBCC
XYXYXY
a1a2a3
b1b1b2
b1b2b3
c1c2c3
a1a2a3
c1c1c2
aaabc
xz
axyzxy
Restrict Project
Product
Union Intersection
Difference
Join
Divide
관계형 대수관계형 대수
모델 자체가 간단하다 - 이차원 구조 , 엔터티와 관계 (Relationship) 을 이용한 논리적 구성…수학적인 이론의 바탕 위에서 설계 - 수학의 집합론의 ‘관계형 이론’ , 옵티마이져 , 인덱싱 ..SQL 의 존재 - 간단하고 효율적인 질의어 .. - 업계 표준화 (SQL/89,SQL/92,SQL/1999)90 년대 이후 정보 시스템의 요구 충족할 만큼 기술적인 발전 - 병렬 처리 ,C/S 등 )
관계형 데이터베이스의 장점관계형 데이터베이스의 장점
INDEX 의 이해와 활용
인덱스의 필요성
I. 관계형 모델은 동적 모델이다 . ( OPTIMIZER 의 역할은 ?)
II. 관계형 모델에서 특정 데이터에 바로 접근 할 수 없다 .- 포인터가 없다 .III. Set 단위 (Column 단위 ) 작업만 하고 싶다 .IV. 조인과 인덱스의 관계는 ?V. 인덱스는 RDB 의 접근의 한계를 극복할 수 있는 최고의 대안이다 .VI. 물리적 저장 구조는 테이블 구조가 아니다 . -> 파일
ConFunkWhiteRudd
...
...
...
...
470401470402470403470501
White ... 470502Barr ... 470503
AkhtarFunkSmithMartinSmith
...
...
...
...
...
470601470602470603470604470701
Ota ... 470702
MartinPhuaJonesSmithGanio
...
...
...
...
...
470801470802470803470804470901
Jones ... 470902
Where Index?
1. 특정 값에 접근 하고자 할 때 인덱스 알고리즘을 통해 해당 값의 위치를 알고 그 위치로 가서 바로 값을 가져오는 방식 .
2. 작업 단위를 테이블이 아닌 Column 단위로 하는 것이 효율적이다 ( Join, Column 단위 작업 )
Project Project
인덱스를 이용한 특정 값 접근인덱스를 이용한 특정 값 접근
Index Pages
Non-LeafLevel
Leaf Level(Key Value)Leaf Level
(Key Value)AkhtarAkhtarBarrBarrBarrBarrBormBormBuhlBuhl
…………………………
GanioGanioHallHallHartHart
JonesJonesJonesJones
…………………………
MorganMorganNashNashNayNayOtaOta
RuddRudd
…………………………
ChaiChaiConConConConCoxCoxDaleDale
…………………………
DunnDunnDunnDunnFineFineFortFort
……………………
FunkFunk ……
JordanJordanKimKimKimKimKochKochKochKoch
…………………………
LangLangMartinMartinMartinMartinMartinMartinMorisMoris
…………………………
SmithSmithSmithSmithSmithSmithSmithSmithSmithSmith
…………………………
Data Pages
SELECT lastname, firstname, age, sex FROM memberWHERE lastname = ‘Funk’
SELECT lastname, firstname, age, sex FROM memberWHERE lastname = ‘Funk’
AkhtarAkhtarChaiChaiDunnDunnGanioGanio
……………………
JordanJordanLangLangMorganMorganSmithSmith
……………………
AkhtarAkhtar
JordanJordan
……
……
……
……
Create index n_in on member(lastname, firsname)
인덱스를 이용한 인덱스를 이용한 Column Column 단위 작업단위 작업
Index Pages
Non-LeafLevel
Leaf Level(Key Value)Leaf Level
(Key Value)AkhtarAkhtarBarrBarrBarrBarrBormBormBuhlBuhl
…………………………
GanioGanioHallHallHartHart
JonesJonesJonesJones
…………………………
MorganMorganNashNashNayNayOtaOta
RuddRudd
…………………………
ChaiChaiConConConConCoxCoxDaleDale
…………………………
DunnDunnDunnDunnFineFineFortFortFunkFunk
…………………………
JordanJordanKimKimKimKimKochKochKochKoch
…………………………
LangLangMartinMartinMartinMartinMartinMartinMorisMoris
…………………………
SmithSmithSmithSmithSmithSmithSmithSmithSmithSmith
…………………………
Data Pages
USE creditSELECT lastname, firstname FROM memberWHERE lastname BETWEEN 'Funk' AND 'Lang'
USE creditSELECT lastname, firstname FROM memberWHERE lastname BETWEEN 'Funk' AND 'Lang'
AkhtarAkhtarChaiChaiDunnDunnGanioGanio
……………………
JordanJordanLangLangMorganMorganSmithSmith
……………………
AkhtarAkhtar
JordanJordan
……
……
……
……
Create index n_in on member(lastname, firsname)
Finding Rows in a Heap with a Nonclustered Index
Non-Leaf
Level
Page 12 - RootPage 37 Page 28
Leaf Level(Key Value)
Page 41 Page 51 Page 61 Page 71
AkhtarAkhtar......MartinMartin
AkhtarAkhtarBarrBarrConConFunkFunkFunkFunk
4:706:014:706:014:705:034:705:034:704:014:704:014:706:024:706:024:704:024:704:02
MartinMartinSmithSmith......
SmithSmithSmithSmithSmithSmithWhiteWhiteWhiteWhite
4:706:034:706:034:708:044:708:044:707:014:707:014:704:034:704:034:705:024:705:02
AkhtarAkhtarGanioGanio......
GanioGanioHallHall
JonesJonesJonesJonesJonesJones
4:709:014:709:014:709:044:709:044:709:024:709:024:708:034:708:034:707:034:707:03
HeapPage 707 Page 808 Page 709
0101020203030404......
......
......
......
......
......
AkhtarAkhtarFunkFunkSmithSmithMateyMatey......
Page 704 Page 705 Page 706 010102020303............
......
......
......
......
......
ConnConnFunkFunkWhiteWhite............
010102020303............
......
......
......
......
......
RuddRuddWhiteWhiteBarrBarr
......
......
010102020303............
......
......
......
......
......
SmithSmithOtaOta
JonesJones............
0101020203030404......
......
......
......
......
......
MartinMartinPhuaPhuaJonesJonesSmithSmith......
010102020303............
......
......
......
......
......
GanioGanioJonesJonesHallHall
......
......
MartinMartinMateyMateyOtaOta
PhuaPhuaRuddRudd
4:708:014:708:014:706:044:706:044:707:024:707:024:708:024:708:024:705:014:705:01
NonClustered
Index
File ID #4
idid indid = 2indid = 2 rootrootsysindexes
SELECT lastname, firstnameFROM memberWHERE lastnameBETWEEN 'Masters' AND 'Rudd'
SELECT lastname, firstnameFROM memberWHERE lastnameBETWEEN 'Masters' AND 'Rudd'
Non-Leaf
Level
Page 12 - RootPage 37 Page 28
Leaf Level(Key Value)
Page 41 Page 51 Page 61 Page 71
AkhtarAkhtar......MartinMartin
AkhtarAkhtarBarrBarrConConFunkFunkFunkFunk
4:706:014:706:014:705:034:705:034:704:014:704:014:706:024:706:024:704:024:704:02
MartinMartinSmithSmith......
SmithSmithSmithSmithSmithSmithWhiteWhiteWhiteWhite
4:706:034:706:034:708:044:708:044:707:014:707:014:704:034:704:034:705:024:705:02
AkhtarAkhtarGanioGanio......
GanioGanioHallHall
JonesJonesJonesJonesJonesJones
4:709:014:709:014:709:044:709:044:709:024:709:024:708:034:708:034:707:034:707:03
HeapPage 707 Page 808 Page 709
0101020203030404......
......
......
......
......
......
AkhtarAkhtarFunkFunkSmithSmithMateyMatey......
Page 704 Page 705 Page 706 010102020303............
......
......
......
......
......
ConnConnFunkFunkWhiteWhite............
010102020303............
......
......
......
......
......
RuddRuddWhiteWhiteBarrBarr
......
......
010102020303............
......
......
......
......
......
SmithSmithOtaOta
JonesJones............
0101020203030404......
......
......
......
......
......
MartinMartinPhuaPhuaJonesJonesSmithSmith......
010102020303............
......
......
......
......
......
GanioGanioJonesJonesHallHall
......
......
MartinMartinMateyMateyOtaOta
PhuaPhuaRuddRudd
4:708:014:708:014:706:044:706:044:707:024:707:024:708:024:708:024:705:014:705:01
Nonclustered
Index
File ID #4
MartinMartin
MartinMartin
0404 ...... MateyMatey
MateyMatey 4:706:044:706:04
0202 ...... PhuaPhua
PhuaPhua 4:708:024:708:02
0101 ...... RuddRudd
RuddRudd 4:705:014:705:01
0202 ...... OtaOta
OtaOta 4:707:024:707:02
Data PageData Page
Finding Rows in a Clustered Index
Clustered Index
Page 140 - Root
Page 100 Page 120 Page 130
Page 141 Page 145
AkhtarAkhtarBarrBarrConConFunkFunkFunkFunk......
2334233456785678253425341334133415341534......
......
......
......
......
......
......
MartinMartinMartinMartinOtaOtaPhuaPhuaRuddRudd......
1234123477787778587858787878787860786078......
......
......
......
......
......
......
SmithSmithSmithSmithSmithSmithWhiteWhiteWhiteWhite......
1434143457785778797879782234223416341634......
......
......
......
......
......
......
AkhtarAkhtarGanioGanio
…………
AkhtarAkhtar……
MartinMartin
MartinMartinSmithSmith
……
Page 110
GanioGanioHallHallJonesJonesJonesJonesJonesJones......
7678767880788078243424345978597826342634......
......
......
......
......
......
......
SELECT lastname, firstnameFROM memberWHERE lastname = 'Ota'
SELECT lastname, firstnameFROM memberWHERE lastname = 'Ota'
Clustered Index
Page 140 - Root
Page 100 Page 120 Page 130
Page 141 Page 145
AkhtarAkhtarBarrBarrConConFunkFunkFunkFunk......
2334233456785678253425341334133415341534......
......
......
......
......
......
......
MartinMartinMartinMartinOtaOtaPhuaPhuaRuddRudd......
1234123477787778587858787878787860786078......
......
......
......
......
......
......
SmithSmithSmithSmithSmithSmithWhiteWhiteWhiteWhite......
1434143457785778797879782234223416341634......
......
......
......
......
......
......
AkhtarAkhtarGanioGanio
…………
AkhtarAkhtar……
MartinMartin
MartinMartinSmithSmith
……
Page 110
GanioGanioHallHallJonesJonesJonesJonesJonesJones......
7678767880788078243424345978597826342634......
......
......
......
......
......
......
MartinMartinMartinMartin
OtaOtaOtaOta 5878587858785878 ............
MartinMartinMartinMartin
idid indid = 1indid = 1 rootrootsysindexes
Data Page
Leaf Leaf LevelLevel
Non-Leaf LevelNon-Leaf Level
Finding Rows in a Clustered Index with a Nonclustered Index
Clustered IndexOn Last Name
NonclusteredIndex onFirst Name
Non-LeafLevel
Leaf Level(Clustered
Key Value)
AaronAaronDeannaDeanna……
AaronAaron......JoseJose
JoseJoseNinaNina……
DeannaDeannaDonDonDougDoug
DaumDaumHallHallHamptonHampton
…… ……
AaronAaronAdamAdamAmieAmie
ConConBarrBarrBaldwinBaldwin
…… ……
JoseJoseJudyJudyMikeMike
LugoLugoKaethlerKaethlerNashNash
…… ……
BarrBarr AdamAdamCoxCoxDaumDaum
ArletteArletteDeannaDeanna
…… ……
……………………
KimKimKobaraKobaraLaBrieLaBrie
ShaneShaneLindaLindaRyanRyan
…… ……
……………………
NagataNagataNashNashNixonNixon
SusanneSusanneMikeMikeTobyToby
…… ……
……………………
BarrBarrKimKimNagataNagataO’MeliaO’Melia
idid indid = 2indid = 2 rootrootsysindexes
SELECT lastname, firstname, phoneFROM memberWHERE firstname = 'Mike'
SELECT lastname, firstname, phoneFROM memberWHERE firstname = 'Mike'
Clustered IndexOn Last Name
NonclusteredIndex onFirst Name
Non-LeafLevel
Leaf Level(ClusteredKey Value)
AaronAaronDeannaDeanna……
AaronAaron......JoseJose
JoseJoseNinaNina……
DeannaDeannaDonDonDougDoug
DaumDaumHallHallHamptonHampton
…… ……
AaronAaronAdamAdamAmieAmie
ConConBarrBarrBaldwinBaldwin
…… ……
JoseJoseJudyJudyMikeMike
LugoLugoKaethlerKaethlerNashNash
…… ……
BarrBarr AdamAdamCoxCoxDaumDaum
ArletteArletteDeannaDeanna
…… ……
……………………
KimKimKobaraKobaraLaBrieLaBrie
ShaneShaneLindaLindaRyanRyan
…… ……
……………………
NagataNagataNashNashNixonNixon
SusanneSusanneMikeMikeTobyToby
…… ……
……………………
BarrBarrKimKimNagataNagataO’MeliaO’Melia
MikeMikeMikeMike NashNashNashNash
NagataNagataNagataNagata
NashNashNashNash MikeMikeMikeMike …………
Data Page & Leaf LevelData Page & Leaf Level
Non Leaf Non Leaf LevelLevel
클러스터 (클러스터드 인덱스 ) 와 인덱스 비교
Data Page 를 특정 Column Sort 순서로 저장하자
클러스터는 인덱스 개념을 데이터 페이지에 적용한 개념
INDEXINDEX TABLETABLE
Rowid Columns Rowid Columns
1 AB 123 . .1 AB 123 . .. . . . . . . . .. . . . . . . . .
. . . . . . . . . . . . . . . . . .4 4 CA 354 CA 354 . . . .
12 BS 123 . .12 BS 123 . . 3 BB 217 . .3 BB 217 . .10 BD 123 . .10 BD 123 . . 9 CS 5 . .9 CS 5 . .. . . . . . . . .. . . . . . . . .
. . . . . . . . .. . . . . . . . .99 DD 123 . .99 DD 123 . .
• •
Index RowidIndex Rowidcolumncolumn
999 . . .999 . . .
111 3111 3 . . . .. . . . . . . .. . . .
123 1123 1123 10123 10123 12123 12 . . . . .. . . . .123 99123 99
. . . .. . . . . . . .. . . .
CLUSTERD INDEXCLUSTERD INDEX TABLETABLE
1 AB . . . . . 12 BS . . . . . 10 BD . . . . .
. . . . . . . . .
99 DD . . . . .
3 BB . . . . .. . . . . . . . .. . . . . . . . .
10 Cluster Header10 Cluster Header
. . . . . . . . .. . . . . . . . .
. . . . . . . . .. . . . . . . . .
Rowid Columns Rowid Columns
111 1 . . . .
. . . .999 . .
Cluster ClusterCluster ClusterKey HeaderKey Header
123 10123 10
INDEX CLUSTER
엑세스 기법이 아닌 물리적인 저장 기법넓은 범위의 엑세스와 조인의 수행 속도를 높임Insert, Update, Delete 시에는 많은 과부하적절한 클러스터링은 저장 공간을 절약
Indexing Guidelines
인덱스 고려 Column - Primary and Foreign Key - 자주 범위를 주고 검색 하는 컬럼 - 자주 Sort 된 순서로 검색을 하는 경우 - 자주 집계 동안 그룹 형식으로 작업하는 컬럼 인덱스를 피해야 하는 Column - 거의 쿼리에 사용되지 않은 컬럼 - 유일 값들이 거의 없는 경우 - Text..
인덱스는 전략은 단순 규칙에 의해서 결정할 수 없다 . 해당 테이블과 해당 테이블에 요청하는 SQL 를 종합적으로 판단하여 최적의 전략 수립을 해야 한다 .
그러기 위해서 인덱스에 대한 명확한 이해와 유연한 사고가 필요하다 .
잘 만들어진 인덱스는 열 메모리 안 부럽다 (?)
다량의 범위를 자주 엑세스해야 하는 경우인덱스를 사용한 처리가 부담이 되는 넓은 분포도여러 개의 테이블이 빈번한 조인을 일으킬 때반복 컬럼이 정규화 작업에 어쩔 수 없이 분할 된 경우Union, Distinct, Order by, Group by수정이 자주 일어 나지 않는 컬럼처리 범위가 넓어 문제가 발생한 경우는 단일 테이블 클러스터링조인이 많아 문제가 발생되는 경우는 다중 테이블 클러스터링 !!!!! 클러스터는 꼭 필요한 경우에만 !!!!
클러스터 (클러스터드 인덱스 ) 의 선정 기준
데이터 처리 (Insert, Update,Delete) 에 오버헤드 발생 주의
인덱스로도 충분한 범위는 클러스터링 효과가 없슴 – 오히려 악재
클러스터링 키는 수정이 빈번하지 않아야 한다 .
인덱스와 상호 협조적인 결합
클러스터 구성 시 인덱스 수 감소 요인 (감소 해야 )
클러스터 고려 시 Column 길이도 중요한 고려 사항
클러스터는 분포도 고를 것
주의 사항 : SQL Server 2000 의 경우 Primary Key 선택 시 자동적으로 해당 컬럼에 클러스터드 인덱스가 설정이 되는데 이 경우 클러스터 선정 기준을 고려해야 꼭 필요한 상황이 아니라면 Unique Index를 설정하여 클러스터드 인덱스가 남발이 되지 않도록 해야 한다 .
클러스터의 고려 사항
Access methodAccess methodAccess methodAccess method
Table scanTable scan
Clustered index on the charge_amt columnClustered index on the charge_amt column
Nonclustered index on the charge_amt columnNonclustered index on the charge_amt column
Composite index on charge_amt, charge_nocolumns
Composite index on charge_amt, charge_nocolumns
Page I/OPage I/OPage I/OPage I/O
10,41710,417
1042 1042
100,273100,273
273 273
인덱스 전략에 따른 성능 차이
SELECT charge_noFROM chargeWHERE charge_amt BETWEEN 20 AND 30
SELECT charge_noFROM chargeWHERE charge_amt BETWEEN 20 AND 30
인덱스를 이용한 인덱스를 이용한 Data Fragmentation Data Fragmentation 해결해결
• How Fragmentation Occurs– SQL Server reorganizes index pages when
data is modified– Reorganization causes index pages to split
• Methods of Managing Fragmentation– Drop and recreate an index and specify a
fillfactor value– Rebuild an index and specify a fillfactor
value• Business Environment
– Data fragmentation can be good for OLTP environment
– Data fragmentation can be bad for Analysis Services environment
제대로 된 SQL 작성하기
SQL 이 무엇인가 ?SQL 의 존재 - 간단하고 효율적인 Query Language - 관계형 모델을 구현 - 개발자나 사용자가 쉽게 익힐 수 있다 : 대중화 - 업계 표준화 (SQL/89,SQL/92,SQL/1999) - ISO 는 그냥 SQL
수학적인 이론의 바탕 위에서 설계 - 수학의 집합론의 ‘관계형 이론’ - 이차원의 행렬 (Matrix) 구조를 수학적으로 정의 - 명확한 이론적 기반을 제공 - 다양한 수학적 이론을 통한 기술 개발 가능 : 옵티마이져 , 인덱스 ..
제대로 된 SQL 를 작성하려면 ?
I. 항상 I/O 를 생각하라II. 결과만 중요한 것이 아니라 처리 과정 역시
중요하다 .III. RDBMS 는 집합 이론에서 출발한 것이다 . 즉
데이터 처리는 집합 단위로 처리가 되어야 한다 .IV. SP, View, Trigger, Cursor 등의 명확한 정의와 사용
목적을 이해하라 . 그리고 해당 로직 구현에 왜 필요한 것인지 판단하라 .
V. OPTIMIZER 는 주어진 조건에서 최선의 처리 방안을 찾는 것이다 . 주어진 조건은 결국 사람이 만드는 것이다 .
SQL 작성 예 - Cursor 와 Case
select m.m_id,m.name,salery + isnull(Totalbonus,0) as bonusfrom member mleft outer join (select m_id,sum( case l_id
when 1 then 10when 2 then 20when 3 then 30end ) as Totalbonus
from actwhere aday between '20011001' and '20011031'group by m_id) bonuson m.m_id = bonus.m_id
declare @member table(m_id varchar(10)
, name varchar(20), salery int)
declare @m_id varchar(10),@name varchar(20),@salery int,@total int DECLARE member_cursor CURSOR FOR SELECT m_id, name, saleryFROM member
OPEN member_cursor
FETCH NEXT FROM member_cursor INTO @m_id, @name, @salery
WHILE @@FETCH_STATUS = 0beginselect @total = sum( case l_id when 1 the
n 10 when 2 then 5 when 3 then 15 end) from actwhere m_id = @m_id
select @salery = @salery + isnull(@total,0)
insert @member values( @m_id,@name,@salery)
FETCH NEXT FROM member_cursor INTO @m_id, @name, @salery
endselect * from @memberCLOSE member_cursorDEALLOCATE member_cursor
SQL 작성 예 - Distinct 와 group by
아래 Query 문에 어떤 문제가 있는가 ?
Select distict colA, colB,count(colc)from TabAwhere colD = 'A01'group by colA,colB
![(무)ABL무해지환급형종신보험 순수 · 2019. 2. 13. · [ 목 차] (무)abl무해지환급형종신보험 순수 안내4 (무)abl무해지환급형종신보험 순수 190417](https://img.pdfslide.tips/doc/110x75/5fcc17028f89e90d5d233f5c/eableee-oe-2019-2-13-e-eableee.jpg)
