docs(sql-query-index.md): 오타 수정

spring-jpa/doc/sql-query-index.md

@@ -205,11 +205,11 @@ LIMIT 15 -- no offset
 
 테이블에 데이터가 많을 수록 인덱스 저장 비용도 고려해야한다.
 
-기본적으로 MySQL innodb 스토리지엔진 인덱스 구조는 B-Tree 구조로 되어 있기 때문에, 트리의 깊이가 깊을 수록 별도의 저장 비용이 든다. 특히 Replication DB 구조라면 불필요하게 추가된
-인덱스는 복제 지연을 유발할 수 있음으로, 인덱스 최적화에 있어 백분위, 분포도를 따져 인덱스를 선정해야 한다. 쿼리를 개선한다고 인덱스를 무작정 다 설정하는 것은 답이 아니다.
+기본적으로 MySQL innodb 스토리지엔진의 인덱스 구조는 B+Tree 구조로 되어 있기 때문에, 트리의 깊이가 깊을 수록 별도의 저장 비용이 든다. 특히 Replication DB 구조라면 불필요하게 추가된
+인덱스는 복제 지연을 유발할 수 있다. 인덱스 최적화에 있어 데이터 분포도를 따져 신중히 선정해야 하고, 조회 성능을 개선한다고 무작정 인덱스를 설정하는 것은 답이 아니다.
 
-또한, MySQL 8 버전 옵티마이저는 CBO 기반으로 동작하고 있기 때문에, Join 절의 테이블의 데이터 양과 인덱스 구성에 따라 실행 계획이 예상과 다르게 슬로우 쿼리가 발생할 수 있다. 인덱스 추가 후 실행
-계획을 기반으로 조회 성능을 비교 검증하는 습관을 가져야 한다.
+마지막으로 MySQL 8 버전 옵티마이저는 CBO 기반으로 동작하고 있기 때문에, Join 절의 테이블의 데이터 양과 인덱스 구성에 따라 실행 계획이 예상과 다르게 슬로우 쿼리가 발생할 수 있다. 인덱스 추가 후
+실행 계획을 기반으로 조회 성능을 비교 검증하는 습관을 가져야 한다.
 
 ### Reference