오늘 알게된것

 약 한달 전 조회 조건을 추가해달라는 요청이 왔고 대수롭지 않게 추가했던 적이 있다. LEFT JOIN tb_review re ON re.care_no = ca.care_no AND re.delete_yn = 'N' AND re.reg_type = '0' 이게 전체 조회량을 늘리고 늘려서 화면을 다운시킨다는 것을 알게 되었는데, 일반적으로는 join에 and조건을 걸으면 이런 현상이 일어난다고 한다. 그래서 사수님은 이걸 1차적으로 분리해서 작성했고, 시간이 12초에서 1초 내로 줄어드는 효과를 보았다.  LEFT JOIN tb_review re ON re.care_no = ca.care_no  WHERE 1=1  AND re.delete_yn = 'N' AND re.reg_type = '0' 아니 근데 이건 다시 확인하니까 조회 대상이 바뀌는 변화인 것. 전과 같은 결과를 위해 다시 쿼리를 돌려야 했고 EXPLAIN 명령어로 해당 쿼리를 조사해보자 review 테이블에서 care_no를 인덱싱 없이 ALL로 조회하고 있음이 나왔다. 여기에 인덱스를 추가해줘서 결국 같은 결과를 1/10 이하의 시간으로 조회가 가능케 했는데 이에 너무 신기해서 인덱스에 대해 살짝 정리해볼까 한다. 

 해시 > 위장 스파이가 여러 종류의 옷을 가지고 총 몇가지의 위장을 할 수 있냐는 문제다. 이건 수학문제중에 경우의 수에서 자주 볼 수 있는 문제인데 중간까지 그걸 파악못하고 혼란을 겪었다.  map 에 중복되는 요소들을 넣기 위해 이전 테스트에서 배운 getOrDefault 메소드를 사용했고, entrySet으로 모든 요소들을 가져와서 경우의 수 공식에 대입했다.  스택/큐 > 다리를 지나는 트럭 이 문제는 시간이 정말 오래걸렸다.. 실제 테스트에 나왔으면 이거 하나 풀고 다른거는 건들지도 못하거나 이문제를 건들지도 못하거나 ... 생각 할 요소가 많은게 처음에는 가장 효율 적인 시간을 구해야 하는 지 알았다. 예를 들어 8, 3, 1, 7 무게 10 이렇게 있으면 8다음 3은 들어갈 수 없으니 뒤에 들어갈 수 있는 1을 찾아서 들어가서 시간을 단축내는 ? 이렇게 풀다보니 너무 어려워져서 다시금 그냥 주어진 순서만 지키면 된다는걸 알게 되었다. 해서 나온게 아래의 경우 while 조건에서 요구하는 sum과 다리위에 들어가기 위한 sum이 달라서 afterSum/beforeSum으로 나눴는데, 이걸 구하는 과정이 너무 반복이라 효율성에서 실패 하였다. 마지막 추가 되는 상황에서만 sum에 해당 요소를 더해주니 간신히 통과...! 

완주하지 못한 자 map 부분에서 가장 낮은 난이도에 있는 문제다. 입출력 예 participant completion return ["leo", "kiki", "eden"] ["eden", "kiki"] "leo" ["marina", "josipa", "nikola", "vinko", "filipa"] ["josipa", "filipa", "marina", "nikola"] "vinko" ["mislav", "stanko", "mislav", "ana"] ["stanko", "ana", "mislav"] "mislav" 배열 두개를 비교해서 단 하나의 차이점 데이터를 찾으라는 건데, 처음 드는 생각은 물론 이중 for문 이었다. 하지만 "1명 이상 100,000명 이하입니다." 라는 조건에 걸려 최대 100억번의 반복 비교를 해보는건 너무 비효율이라고 생각. 두번째로 든 생각은 현재 문제의 특수성, 참가자와 완주자는 무조건 한명의 차이점 외에 다른점은 없다. 그래서 두개의 배열을 정렬 시키고 다른 데이터가 있으면 그냥 그대로 반환 시켜 주기로 하였다.  for문을 한번만 사용하기 때문에 최대 10만번 이내에서 연산을 끝낼 수 있어서 그런지 일단 정확도와 효율성 둘다 테스트는 통과 했지만, 다른 답안지를 보고 아차 했던 것은 이건 hash(map)에 관련된 알고리즘 문제였다. 해시 맵에 참가자 데이터를 넣으며 getOrDefault 메소드를 통해 +1을 넣어주고 완주자 목록을 이용해서 -1을