Hyowon's Archive

• Network 의 역할
  • 어플리케이션의 목적에 맞는 통신 방법 제공
  • 신뢰할 수 있는 데이터 전송 방법 제공
  • 네트워크 간 최적의 통신경로 결정
  • 목적지로 데이터 전송
  • 각 노드 사이의 데이터 전송
• 통신 기능이 제대로 이루어지기 위해선 참여자들 사이에 약속된 통신 방법이 있어야 한다. => 형식, 절차, 규약이 있어야 한다. 이러한 통신 규약을 네트워크 Protocol 이라고 한다.
• 네트워크의 역할이 여러 개이므로 Protocol 또한 여러 종류가 있어야 한다. 즉 각 역할별로 Protocl이 모듈화 되어 있다.

• 각 기능별로 나눈 계층 구조(Layered Architecture)가 필요하다. 각 레이어 별로 역할에 따라 모듈화되어 있는 것이다. 
  • OSI model (7 layer) : 범용적인 네트워크 계층 구조 
  • TCP/IP model (4 layer) : 인터넷에 특화된 네트워크 계층 구분법
• 각 Layer의 Protocol은 하위 Layer의 Protocol이 제공하는 기능을 사용하여 동작한다.

• L7 - Application Layer : HTTP, DNS, SMTP, FTP 등 application 목적에 맞는 통신방법제공
  • 실제로 데이터가 어떻게 전송될지는 관심없음
• L6 - Presentation Layer : APP간 통신에서 메시지 format 관리
  • 인코딩 <=> 디코딩
  • 암호화 <=> 복호화
  • 압축 <=> 압축풀기
• L5 - Session Layer : App 간 통신에서 session 관리, RPC(Remote Procedure Call) 동작이 이 위에서 이루어짐.
• *L5 ~ L7 : Application과 관련된 기능 담당
• L4 - Transport Layer : App간 통신담당 => 목적지 App으로 데이터 전송, 어떤 방법 (TCP,UDP)으로 보낼지 결정
  • TCP : 안정적, 신뢰성있는 데이터 전송 보장
  • UDP : 필수 기능만 제공
• L3 - Network Layer
  • Host간 통신담당(IP)
  • 목적지 호스트로 데이터 전송
  • 네트워크간 최적 경로 결정
• L2 - Data Link Layer 
  • 직접 연결된 노드 간 통신담당
  • MAC 주소 기반 통신(ARP)
• L1 - Physical Layer : 물리적인 매개체(케이블, 무선 등)를 통해 bit 단위로 데이터 전송(전기신호)

• 각 계층을 거치면서 데이터에 각각의 계층에 해당하는 Header 정보를 담는다.(L2 데이터 링크 계층에서는 Header뿐만 아니라 꼬리 부분에 Trailer 정보를 붙인다, 또한 L1의 헤더는 없다, 그냥 보내는 역할을 칭하는 것)

• 라우터를 거치면서 Encapulation과 Decapsulation을 거치면서 목적지에 도달하게 된다.
• TCP/IP 모델과는 아래와 같이 대응된다.

네트워크 기초 시리즈는 유튜버 '쉬운코드'의 네트워크 강의를 정리함

https://youtu.be/oFKYzp6gGfc?si=pMc1aOUFQ_Y2y4qo

• IP address : 인터넷에 연결되기 위한 필요한 인터넷상의 주소
• 모뎀(modem)
  • 네트워크 통신에 필요한 신호변환장치
  • 디지털 정보를 아날로그 신호로 변조(modulation)하여 송신하고, 수신된 아날로그 신호를 디지털 신호로 복조(demodulation)
• 공유기(Home Router)
  • 여러 기기들이 인터넷에 연결될 수 있도록 하는 장치(LAN, wifi를 통해 기기들을 공유기에 연결)
  • 하나의 IP 주소로 동시에 여러기기들이 인터넷을 사용하게 하는 것이 가능.
  • 공유기에 연결된 기기들은 같은 네트워크 소속

• 스위치(switch)
  • 같은 네트워크에 있는 기기들이 서로 통신할 수 있도록 하는 장치
  • 보통 공유기의 LAN 포트가 부족할 때 사용
  • '스위칭 허브' 혹은 '허브'라고 불림

• Network : 컴퓨터나 기기들이 리소스를 공유하거나 데이터를 주고 받기 위해 유무선으로 연결된 통신 체계
• LAN(Local Area Network) : 집, 회사, 건물 등 제한된 범위의 네트워크
  • LAN 구성 기술
    • Ethernet : 유선 통신
    • wireless LAN : 무선 통신(=wifi)
• WAN(Wide Area Network) : 여러 LAN이나 다른 종류의 네트워크를 하나로 묶어서 통신이 되도록 만든 네트워크
  • Ex) 은행 ATM, wireless WAN, Internet(=> 4G, 5G)
• Internet : 네트워크들의 네트워크, the World's Largest WAN, Global network
• ISP(Internet Service Provider) : 일반 사용자, 회사 등이 인터넷을 사용하도록 인터넷 연결 서비스를 제공하는 업체
  • ex) AT&T , NTT, SKT, KT, LG 등
• 서로 다른 ISP의 네트워크들이 서로 연결되어 있기 때문에 서로 다른 ISP의 사용자들이 통신할 수 있다.

• ISP는 역할과 규모에 따라 tier가 나뉜다.
  • Tier 1 
    • 국제 범위의 네트워크 보유
    • 인터넷의 모든 네트워크 접근 가능
    • 인터넷의 중축, Backbone
    • Tier 1 간 트래픽 전송 비용 없음 - 청구해봤자 서로 상계되기 때문에
    • 그래서 인프라 자체로 수익을 얻음
  • Tier 2
    • 국가/지방 범위 네트워크 보유
    • Ex) SKT, KT, LG 등
    • 일반 사용자나 기업대상 서비스 제공
    • Tier 2간의 트래픽은 비용 없음
  • Tier 3
    • 작은 지역 범위 제공
    • 상위 ISP에게 비용을 내고 인터넷 트래픽 구매하여 서비스
    • Tier 2가 모든 지역을 커버하지 못하는 미국같은 넓은 지역에서 존재하는 서비스

• ISP 네트워크 간에는 Router를 이용하여 연결한다.
  • Router : 목적하는 네트워크에 데이터를 보내는 장치
• 네트워크를 이루는 각각의 장치들을 Node라고 부른다. PC, 공유기, 모뎀, 라우터 등이 모두 Node이다.
• 네트워크의 끝에 있는 노드(핸드폰, PC 등) : End system, Host
  • 네트워크를 사용하기 위한 목적
  • Client(요청하는 host)와 Server(제공하는 host)로 역할이 나뉨

(IMG) Define Excise Duty Group 

- Table OIH2, OIH2T

- ED Group은 material 개별 마스터 정보를 변경하지 않고 ED Group 레벨에서 Excise duty 비율(세율)을 관리하게 한다.

- Tax가 특정 단위로 측정되는 자재에 부과되기 때문에 Unit of Measure Group(UoMG)가 ED group에 할당되어야 한다.

- 같은 excise duty(한국에선 개별소비세 같은 물품세) 비율을 가진 자재에 같은 ED Group을 할당하여 관리하는 것이 좋다.

(IMG) Define Excise Duty Status 

- Table OIH4, OIH4T

- material valuation record(accounting view)에 할당되는 값이다.

- 과세/비과세 여부를 판단하는 기준이 되는 상태값을 나타낸다.

- 기본적으로 Handling Type으로부터 도출되는 값이다.

(IMG) Define Combinations of Excise Duty, Tax Status, Account determination

 - Table OIH3

- material이 서로 다른 Tax status를 옮겨다닐 수 있는 지 여부를 판단하는 결정 과정.

- Company code, ED group, From Tax status, To Tax Status, Event type, Movement type의 조합으로 결정된다.

- 추측) From TA(tax), To UT(untax)인 경우 261로 판매오더 GI하면, 상대는 유류세 비과세, 파는 회사(본인)은 과세이므로 Excise duty를 Claim할 권리(채권)을 갖게 된다. 반대면 Excise Duty를 판매처에 부채로 잡게 됨. 둘다 과세면 청구할 필요없음.(어차피 판매처에서 Excise Duty 납부하게 될 테니)  --- 추측임

(IMG) Define Handling Type

-  Excise Duty rate을 찾기 위한 값.

- 구매 할 때는 vendor의 ED status에 대해 handling type이 자재에 적용되는 excise duty rate 참조하게 된다.

- 판매 할 때는 Customer의 ED Status에 대해 handling type이 자재에 적용되는 excise duty rate 참조하게 된다.

- ED Status를 Handling Type에 할당하는 IMG가 있어 Tax, Untax를 Handling type을 통해 결정 가능.

-  Table OIH01를 보면 ED Group, Handling Type 등을 이용해 ED rate를 찾는 것을 알 수 있다.

- SD의 경우 Customer Sales Area view에서 확인할 수 있다.

- Material의 Valuation Type은 Valuation category로부터 도출되고 Valuation Type은 Material의 ED status를 나타내는 데 사용된다.

- ED를 지불한 재고에 대해서는 Accounting 2 view에서 확인할 수 있다.

Define Excise Duty Defaults for Sales

- handling type이 없을 때 default 값으로 입력될 값들 결정 절차

- Company Code, plant, sales document type, -> handling type(meterial)  , Valuation Type 결정

Loading confirmation

1. 집에 있는 안 쓰는 노트북을 개인 프로젝트 서버로 사용하기로 결정

2. 리눅스 연습 겸 우분투로 서버 실행하고 싶지만 노트북 OS는 윈도우로 그대로 두고 싶어서 VMware 사용

3.1 노트북으로 포트포워딩

3.2 노트북으로 들어온 요청을 다시 노트북 윈도우에서 실행중인 VMware의 우분투 리눅스로 보내줘야함

3.3 3.2의 VMware 포트포워딩 설정은 Vmnetcfg를 설치해서 진행

4. 추가로 VMware의 우분투 리눅스 서버 방화벽(UFW) 설정에서 WAS가 사용하는 포트도 해제해줘야함 <- 이것땜에 해맸음..

*포트 포워딩은 외부 아이피 : 포트번호와 내부 아이피 : 포트번호를 연결해주는 기능

- 공인IP로 들어온 요청이 해당 IP에 연결된 전자기기 시스템 중 어느 곳으로 갈지 내부IP와 포트번호를 이용하여 미리 정해주는 기능

정리하면

1. 공유기 포트포워딩 설정 후 노트북 윈도우 방화벽 해제로 외부 요청(port:8080)을 노트북 윈도우로 유도

2. 노트북 윈도우로 요청오면 Vmnetcfg로 포트포워딩 설정하여 VMware의 우분투 리눅스(이것도 방화벽해제해야함)로 포트포워딩

3. 우분투에서 실행중인 Springboot WAS가 요청 처리

참고 URL

https://positivemh.tistory.com/1020

https://blog.naver.com/seoamo/223498511231

Enterpise Structure - Definition - Sales and Distribution

Define, copy, delete, check sales organization

- 법적으로 Sales Organization은 하나의 Company Code에 포함되어야 한다.

- 하나 이상의 plant를 하나의 sales organization에 할당할 수 있다.

- 하나의 주소를 가질 수 있다.

- Sales Organization 안에 고유의 마스터 데이터를 정의할 수 있다. customer, material master, conditions , pricing 등

- Sales Organization 안에 고유의 Sales Document Types들을 정의할 수 있다.

- Sales Office와 Employee들을 Sales Organization에 할당할 수 있다.

- 모든 Sales and Distribution documents들의 Item들은, 즉 , 모든 Sales Order, Delivery, Billing Documents의 Item은 하나의 Sales Organization에 속한다.

- Sales Organization은 영업 통계에서 (Client 다음으로) 가장 높은수준의 요약 레벨이다.

- Sales Documents와 Delivery, Billing due list 등을 검색하는데 조회 조건(Selection Criterion)으로 사용된다.

- 각각의 Sales Organization에, 출력물을 위한 프린터를 각각 지정할 수 있다.

- Sales Organization는 마스터 데이터를 다른 Sales Organization 와 공유할 수 없다. 따로따로 마스터 데이터를 생성해야 한다. Distribution Channel과 division은 여러개의 Distribution Channel과 Division을 위한 마스터 데이터를 만들 수 있다.(공유할 수 있다는 뜻 = Common하다)

Define, copy, delete, check distribution channel

- Wholesale, retail, direct sales 등의 material과 service가 customer에게 도달하는 방식을 정의한다.

- 하나 이상의 Sales Organization에 할당할 수 있다.

- 하나 이상의 plant를 하나의 Distribution Channel에 할당할 수 있다.

- Distribution Channel 안에 고유의 customer, material master data, condition, pricing 를 정의할 수 있다.

- 대표 Distribution Channel master data를 만들어 다른 Distribution Channel 가 사용하도록 공유할 수 있다. master data를 공유하기 위해서는 대표 Distribution Channel 를 다른 Distribution Channel 에 매핑해야 한다. (Define common distribution channels 항목에서 지정)

- Distribution Channel 에 대해서 고유의 sales document types를 지정할 수 있다.

- Sales Office 할당할 수 있다.

- 모든 Sales Document의 아이템은 하나의 Distribution Channel 에 속한다.

- Delivery의 아이템들은 다른 Distribution Channel에 속할 수 있다.

- billing document의 모든 item은 하나의 Distribution Channel에 속한다.

- 조회 조건으로 사용될 수 있다.

- Distribution Channel은 고유의 주소를 가지지 않는다.

- Distribution Channel에 employee를 할당할 수 없다.

Maintain sales office

- Sales Organization의 지리적 영역으로 구분하는 조직 단위 (중부, 동부, 서부, 북부, 경기, 충북 등등)

- 회사(Firm)와 지역 시장(Local market) 사이의 연결(contact)을 담당하는 조직단위라고 볼 수 있다. 

- 필수 정의 항목은 아니다.

- 하나 이상의 Sales Area(Sales Organization, Distribution Channel, Division 의 조합)에 할당될 수 있다.

- 여러 개의 Sales Group으로 나뉠 수 있다.

- 직원들을 Sales Office에 할당할 수 있다.

- 하나의 주소를 가진다.

- 모든 Sales document의 아이템은 하나의 Sales Office에 속한다. (Header Level 이다.)

- Delivery나 Invoice의 아이템들은 서로 다른 Sales Office를 가질 수 있다.

- 조회 조건으로 사용될 수 있다.

Maintain Sales Group

- Sales Group은 Sales Transaction을 일으키고 책임을 지는 조직 단위이다.

- 필수 정의 항목은 아니다.

- 하나 이상의 Sales Office에 할당할 수 있다.

- 직원을 sales group에 할당할 수 있다.

- Sales document item의 책임을 진다.

- Sales Doc의 조회 조건

- Ex) Sales Office 중부사업부 - Sales Group 인천/경기/서울/강원지사

Enterpise Structure - Definition - Logistics Execution

Define, copy, delete, check shipping point

- 회사의 mail depot(상품을 패킹하고 출고하는 장소), plnat railway station(공장에서 물품 납품하는 기차역) 등 shipping 처리를 담당하는 조직 단위.

- shipping type, necessary shipping materials, means of transport(운송수단) 등을 책임지는 조직 단위.

- 주로 plant와 같은 코드를 입력하여 plant=shipping point가 될 수 있도록 지정하는 편이다.

Maintain Loading Point

- shipping point에 속하는 상품을 싣는 장소

- 선택 사항

- Delivery header 에 입력됨

Maintain transportation planning point

- shipment를 계획하는 데 책임을 지는 단위

- shipment는 tpp에 할당된다.

- 회사는 기차나 배로 shipment를 계획하는데 다양한 그룹의 shipping personnel들을 가지고 있다. 이 shipping 인력들을 나누는 단위로 활용 가능.

인덱스를 사용할 때는 인덱스 컬럼을 가공하지 않아야 인덱스를 정상적으로 사용할 수 있다.

- 정상적으로 사용한다는 것은 인덱스의 리프 블록에서 스캔 시작 지점을 찾아 거기서부터 스캔하다가 중간에 멈추는 것(Range Scan)을 의미한다.

- 인덱스를 full scan 하는 것은 인덱스를 제대로 사용하는 것이 아니다. 인덱스 컬럼을 가공하게 되면 full scan 방식으로 인덱스를 사용하기 때문에 좋지 않다.

- 인덱스 컬럼을 가공하지 않았을 대는 INDEX RANGE SCAN을 사용한다.

- 인덱스 컬럼 가공 시 인덱스를 사용하지 못하고 TABLE FULL SCAN 한다.

OR Expansion - 옵티마이저의 실행계획 선택 예시

- or 조건을 union all 조건으로 바꾸는 방법

- USE_CONCAT HINT 를 사용하면 OR 조건을 UNION ALL 로 확장하게 된다.(보통의 경우에는 UNION ALL로 확장하는 게 더 비용적으로 나을 때 채택된다.

- 옵티마이저가 알아서 했을 때 CONCAT이 작동하지 않았다. 아마 CONCAT을 사용했을 때 COST가 더 높기 때문일 것이다. 5행과 6행에서 ACCESS가 각각 동작하고 이를 OR 로 엮었다. 그 이후 BATCH I/O를 한 번 실행함.

- ACCESS predicates for an index are used to fetch the relevant blocks by applying search criteria to the appropriate columns. (조회 조건을 적용하여 리프 블록을 검색하는 동작)

- FILTER predicates are evaluated after the blocks have been fetched. (검색된 블럭들을 조회 조건으로 필터링하는 동작)

- table access by local index rowid batched : 인덱스 리프블록을 버퍼 캐시에서 찾지 못했을 때 바로 디스크 I/O 하지 않고 일정량 모아서 BATCH로 디스크 I/O 하는 방식.

- USE_CONCAT을 사용하여 강제로 UNION ALL을 적용한 모습. 총 COST가 1804로 힌트가 없는 SQL의 COST인 1794 보다 크다. 그러므로 채택되지 않은 실행계획 중 하나이다.

- OR 조건이 없어지고 table access by local index rowid batched 가 2번 실행되었다.

- INDEX BATCH IO가 두번 실행되는 건 UNION ALL을 사이에 두고 SQL이 나누어졌기 때문인 듯함.

- 5과 7행 9행 ACCESS, FILTER, ACCESS가 동작

- 7행에서 LNNVL 함수는 내부 조건이 FALSE 거나 NULL이면 TRUE 를 반환한다.

- PROD_ID = 20이면서 CUST_ID = '5163'가 아닌 것과 NULL인 것, 즉, PROD_ID AND (CUST_ID IS NULL OR CUST_ID != 5163) 을 찾았다.

- 이와 같이 변환된 것이다.

- 첫 번째 SQL은

1. 인덱스 검색

2. 인덱스 검색

3. OR 연산

4. Table Access

- 두 번째 SQL은 

1. 인덱스 검색

2. Table Access

3. 인덱스 검색

4. Table Access

5. Concatenation 연산

- IN 은 OR의 다른 표현일 뿐이므로 OR과 마찬가지로 생각하면 된다.

- 결론은 옵티마이저는 OR과 IN 조건의 경우 쿼리변환을 통해 index range scan으로 처리하기도 한다는 것이다.

결합인덱스는 Range Scan을 위해서 인덱스 선두 컬럼이 가공되지 않은 상태로 조건절에 있어야 한다.

- (PROD_ID, CUST_ID) 가 인덱스로 구성되어 있다면 PROD_ID가 가공되지 않은 상태로 조건절에 있어야 INDEX RANGE SCAN이 가능하다.

- 선두 컬럼이 가공되지 않은 상태로 있다고 무조건 효율적인 인덱스 사용이 이루어지는 것은 아니다.

결합 인덱스는 SORT(정렬)이 생략될 수 있다.

- PROD_ID 와 CUST_ID의 결합인덱스를 사용한 검색 후 ORDER BY에 CUST_ID를 넣으면 SORT 연산이 실행되지 않는다. 이미 인덱스를 검색하는 과정에서 같은 값의 PROD_ID 내에서는 CUST_ID가 ASCENDING 으로 정렬되어 있기 때문이다.

- 마찬가지로 MAX와 MIN 같이 양 끝단에 있는 값을 찾을 때 이미 CUST_ID가 정렬되어 있기 때문에 왼쪽 끝 혹은 오른쪽 끝의 값 하나만 읽으면 되어서 ROWS를 보면 레코드 1개만 찾은 것을 볼 수 있다. 

- 하지만 아래와 같이 숫자인 CUST_ID를 문자로 바꾸어 최대 최소를 구하면 문자 형식으로 정렬을 해야 값을 구할 수 있어 모든 레코드를 다 읽게 된다.

자동 형변환의 위험성

- 두 SQL의 결과가 다르다. 의도한 결과는 2번째 SQL일 것이다. 하지만 DECODE 절에서 NULL과 AMOUNT_SOLD 를 비교할 대 NULL에 맞춰 AMOUNT_SOLD를 CHAR로 바꾼 후 MAX 함수를 사용했기 때문에 999.99가 출력되었다.

- 이 때는 NULL에 TO_NUMBER를 씌워 자동 형변환을 방지하는 방법이 있다(물론 이 SQL에서는 NULL이 아니라 0을 넣으면 형변환이 일어나지 않아 의도대로 출력된다).

옵티마이저가 알아서 하는 역할을 미리 알고 있어야 SQL 튜닝을 더 잘할 수 있다는 교훈을 얻었다.

매번 하다가 포기했던 개인 블로그 프로젝트를 다시 해보려고 한다. 

그만두게 되었던 이유 분석과 앞으로 만들 블로그 계획을 간단히 잡고자 한다.

1. 실패했던 이유

- 모르는 기술을 쓰는 계획을 세웠음. 예를 들어 나만 쓸 기능인데 로그인 기능을 내가 접해보지 않은 토큰 방식으로 한다든지..

- 화면설계서나 기능설계를 하지 않고 생각만 하면서 프로그래밍을 해서 중구난방이 되다 보니 시간이 지나고 들어간 뒤에 어디서부터 해야 하는지 알 수가 없어 의욕이 떨어지게 됐음.

2. 개선해야 할 점

- 내가 할 수 있는 간단한 기능부터 개발하고 클라우드 서비스를 통해 배포해볼 것.

- WBS나 주석 등을 상세히 달아 사정이 생겨 한참 후에 들어왔어도 바로 작업을 이어갈 수 있게 환경을 만들어 둘 것.

구현할 기능

1. 블로그 글쓰기 기능 - 제일 마지막에 할 것.

2. TO DO 리스트 기능 - 집안일, 운동 계획 같은 매일 할 일 적고 체크하는 기능

3. 외국어 문장 연습 기능 - 단순히 한국어-영어 문장 번갈아 보여주며 외국어-뜻 맞춰보는 기능

2번,3번 먼저 만들고 CRUD 기능을 만들것이기 때문에 비밀번호로 로그인하는 기능 만들 것.

앞으로 할 일

1. 화면설계서 만들기

2. 개발환경 정하고 세팅하기

- 인덱스 탐색 과정은 수직적 탐색과 수평적 탐색 2단계로 이루어진다.

- OLTP(Online Transaction Processing)은 소량 데이터를 주로 검색하므로 인덱스 튜닝으로 속도를 빠르게 하는 것이 중요하다.

인덱스 튜닝의 핵심 요소

1. 인덱스 스캔 과정에서 발생하는 비효율 줄이는 것. 즉, 인덱스 스캔 효율화 튜닝

2. 테이블 엑세스 회수 최소화. 인덱스 스캔 후 테이블 레코드를 엑세스할 때 랜덤 I/O를 사용하므로 랜덤 엑세스 최소화 튜닝

- 랜덤 I/O를 줄여야 하는 것이 인덱스 튜닝의 핵심이다.

- B*Tree Index 구조(B = Balanced)

- Root와 Branch 블록에 있는 각 레코드는 하위 블록에 대한 주소값을 갖는다.

- Root와 Branch 블록에는 키값을 갖지 않는 특별한 레코드, LMC(Leftmost Child)가 있다.

- LMC는 자식 노드 중 맨 왼쪽 자식 노드를 가리킨다.

- Leaf 블록에는 테이블의 각 레코드를 가리키는 주소값(ROWID)를 갑는다. 인덱스 키값이 같은 경우 ROWID순으로 정렬된다.

- 인덱스 스캔의 목적은 검색 조건을 만족하는 소량의 데이터의 ROWID를 빠르게 얻는 것이다.

- ROWID = 데이터 블록 주소(DBA; Data Block Address) + 로우 번호

인덱스 탐색 과정

1. 수직적 탐색 : 인덱스 스캔 시작 지점 찾는 과정 = 조건을 만족하는 첫 번째 레코드를 찾는 과정  

2. 수평적 탐색 : 데이터를 찾는 과정

- Leaf 블록끼리 Double Linked List 구조(서로 앞뒤 블록에 대한 주소를 가지고 있는 구조)로 되어 있어 수평적 탐색이가능하다.

- 결합 인덱스의 경우는 '성별 + 고객명'을 하나의 컬럼으로 여긴다고 보면 된다. 즉, 성별로 먼저 대상을 찾고 그 필터링된 대상에서 고객명으로 레코드를 찾는 것이 아니다.

- 인덱스 자체가 2개의 컬럼을 기준으로 이미 정렬되어 있기 때문에 컬럼 개수 만큼 탐색 단계가 존재한다고 착각해서는 안된다.

- 성별로 먼저 필터링하고 그 다음 고객명으로 대상을 찾는다는 의미는 수직적 스캔을 2번한다는 말과 같다. 즉, 결합 인덱스가 아니라 개별 인덱스를 2번 타는 것이라고 볼 수 있다.