일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Pitest
- 객체지향
- ruby
- InnoDB
- 돌연변이 테스팅
- 자바
- JPA
- 코틀린
- 개인블로그 hugo
- 코틀린 in
- resizer 구현
- https 실습
- MySQL
- output stream
- https implement
- Java
- Convariance
- Mutation testing
- standard output
- Test
- 코틀린 out
- kotlin
- resize image with go
- IntelliJ
- standard input
- cli 만들기
- https 서버 구현
- 공짜블로그
- image resizer with go
- https go
- Today
- Total
목록DB (2)
Rlog
최근 팀에 SlowQuery 개선으로 인덱스를 추가하면서 쓸모없는 인덱스가 겹치는 인덱스들이 있겠다는 생각이 들었다. 그래서 팀원들과 같이 얘기해보고 DBA 분과도 얘기해봤지만 마땅한 방법을 찾지 못했었다. 그래서 처음에는 General log 떨어지는 것들을 조사해보는 프로그램 이런걸 만들어볼까? 하다가 이건 미친짓이다 싶어서 분명히 방법이 있을거야 하고 검색을 해보게 됬다. MySQL 을 공부하다보면 알게 되는것이 성능 분석을 위해서는 performance_schema 를 확인하는 것이 가장 좋다. 일단 MySQL 공식문서에도 나와 있듯이, performance_schema 테이블은 information_schema 보다 좀 더 low 한 level 에서의 측정을 기반으로 성능측정을 하게 된다. 성능..
MySQL 에서 Hint 란 옵티마이저의 실행계획을 바꾸는 것을 뜻한다. 대부분의 MySQL 책에서 왠만해서 Hint 를 사용하는 일은 없을 것이라고 말했고, 오히려 내가 주는 Hint 가 "훈수" 느낌으로 될 수 있어서 오히려 성능을 악화시킬 수도 있다고 알고 있었다. 그리고 옵티마이저 자체가 대부분 똑똑한 의사결정을 해서 필요하다고 생각하지 않았는데, 오늘 신규프로젝트를 구성하던 도중 잘못사용하는걸 파악했다. 현재 쿼리를 날렸을때 실행계획은 아래와 같다. test1 은 현재 자주사용하는 쿼리에 맞게 인덱스를 구성했는데, PRIMARY 인덱스를 사용해서 현재 filtered 가 10 밖에 나오지 않는다. 인덱스를 구성할때 test1 인덱스를 사용하여 filtered 가 100 이 되는게 내 목표였다. ..