Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- Spring
- aws
- RabbitMQ
- scala
- 카프카
- spring-batch
- Kafka
- confluent
- enablekafkastreams
- kafka streams
- 한빛미디어
- springboot
- coursera
- Logstash
- gradle
- Elasticsearch
- Elk
- spring-cloud-stream
- Slick
- kafka interactive query
- kafkastreams
- play framework
- schema registry
- spring-kafka
- reactive
- scala 2.10
- statestore
- kafkastream
- 플레이 프레임워크
- avo
Archives
- Today
- Total
목록페이징조인 (1)
b
7.4.6. JOIN
7.4.6 JOIN * JOIN의 순서와 인덱스인덱스 탐색(Index seek) => 인덱스 스캔(Index scan) => 최종 레코드 Read (일반적으로 가장 먼저 읽히는 테이블을 '드라이빙 테이블'이라 하고 가끔은 아우터 테이블을 드라이빙 테이블이라 하기도 한다) - 드라이빙 테이블을 읽을 때는 '인덱스 탐색'1번 -> 스캔만 계속 실행- 드리븐 테이블은 '탐색', '스캔'을 레코드 건수만큼 반복한다.-- 그래서 1:1로 조인되더라도 드리븐 테이블을 읽는것이 훨씬 부하가 크다.-- 그래서 옵티마이저는 '드리븐 테이블'을 최적으로 읽을 수 있게 최적화한다. * JOIN 칼럼의 데이터 타입- JOIN 에서도 각 칼럼의 타입이 일치하지 않으면 인덱스가 효율적이지 않다. * OUTER JOIN의 주의사항..
RealMysql
2013. 1. 4. 20:07