일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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
- Mutation testing
- standard input
- 개인블로그 hugo
- hugo 로 블로그
- standard output
- 공짜블로그
- IntelliJ
- 돌연변이 테스팅
- 자바
- 코틀린
- cli 만들기
- Java
- 의존성역전원칙
- Test
- resizer 구현
- resize image with go
- image resizer with go
- 코틀린 out
- change refresh rate
- output stream
- Convariance
- ruby
- InnoDB
- kotlin
- 코틀린 in
- JPA
- 객체지향
- Pitest
- 코틀린 노트북
- MySQL
Archives
- Today
- Total
목록index (1)
Rlog
인덱스 컬럼의 가공(연산)은 예상치 못한 결과를 초래한다.
MySQL 2판을 보던 중 한가지 사실을 알았다. 바로 WHERE 조건문에 INDEX 를 통해서 검색하려고 할때 INDEX 에 변환 또는 연산을 가하게 될 경우 인덱스 조건을 안타게 된다는 사실이다. 아래 쿼리를 한번 보자. 지금 위의 쿼리를 한번 살펴보면 첫번째 쿼리는 age 라는 INDEX 컬럼에 2를 곱한 뒤 age=20 인 컬럼의 데이터를 가져오는 쿼리이다. 두번째 쿼리는 반대로 age = 40/2 인 즉 age = 20 인 쿼리를 가져오는 것이므로 두 쿼리의 결과는 아래처럼 똑같다. 하지만 결과는 같은데 MySQL 의 옵티마이저가 내린 판단은 다르다. 그 이유는 무엇일까? MySQL 에서는 기본적으로 정렬에 B-Tree 자료구조를 이용하는데 이때 사용자가 설정한 Index 의 값으로 정렬이 되어..
데이터베이스
2022. 2. 13. 23:33