2023년 11월 13일 알고리즘 문제풀이 문제 신고 결과 받기 난이도 Lv.1 코드 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 def solution(id_list, report, k): n = len(id_list) answer = [0 for _ in range(n)] table = [[0 for _ in range(n)] for _ in range(n)] for x in report: sender, receiver = x.split() a = id_list.index(sender) b = id_list.index(receiver) table[b][a] = 1 for i in table: if sum(i) >= k: for j in range(len(i)): if i[j]: answer[j] += 1 return answer 어떤 배열들을 만들어야 하는지 헷갈렸지만 크게 어려운 문제는 아니었다.
2023년 11월 10일 알고리즘 문제풀이 문제 게임 맵 최단 거리 난이도 Lv.2 코드 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 from collections import deque def solution(maps): answer = -1 n = len(maps) m = len(maps[0]) da = [1,-1,0,0] db = [0,0,1,-1] maps[0][0] = 0 q = deque() q.append([0,0,0]) while q: a,b,cnt = q.popleft() if a == n-1 and b == m-1: answer = cnt+1 print(a,b) return answer for i in range(4): na = a + da[i] nb = b + db[i] if na < 0 or na >= n or nb < 0 or nb >= m or not maps[na][nb]: continue q.append([na,nb,cnt+1]) maps[na][nb] = 0 return answer BFS를 이용해서 특정 조건(맵 상 벽이라던가, 맵 범위 밖이라던가, 방문한 곳이라던가)을 제외하여 최단 거리를 구하는 문제는 이제 충분히 적응됐다.
2023년 11월 9일 알고리즘 문제풀이 문제 링크 난이도 Lv.1 코드 1 2 3 def solution(arr): answer = sum(arr)/len(arr) return answer
책너두 6기 48일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.485 ~ p.490 내용정리 10 실행계획 10.3 실행계획분석 10.3.12 Extra 칼럼 10.3.12.27 Using MRR MRR(Multi Range Read) 최적화는 여러 개의 키 값을 한 번에 스토리지 엔진으로 전달하고, 스토리지 엔진은 넘겨받은 키 값들을 정렬해서 최소한의 페이지 접근만으로 필요한 레코드를 읽을 수 있게 한다. 10.3.12.28 Using sort_union(…), Using union(…), Using intersect(…) 쿼리가 index_merge 접근 방법으로 실행되는 경우에는 2개 이상의 인덱스가 동시에 사용될 수 있다. 이 때 두 인덱스로부터 읽은 결과를 어떻게 병합했는지 조금 더상세하기 설명하기 위해 3개 중에서 하나의 메시지를 출력한다. ...
책너두 6기 47일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.480 ~ p.484 내용정리 10 실행계획 10.3 실행계획분석 10.3.12 Extra 칼럼 10.3.12.13 Using index condition 인덱스 컨디션 푸시 다운(Index condition pushdown) 최적화를 사용하면 표시된다. 10.3.12.14 Using index for group-by GROUP BY 처리가 인덱스를 이용할 때 표시 10.3.12.14.1 타이트 인덱스 스캔(인덱스 스캔)을 통한 GROUP BY 처리 AVG(), SUM(), COUNT() 처럼 조회하려는 값이 모든 인덱스를 다 읽어야 할 때는 필요한 레코드만 듬성듬성 읽을 수가 없다. 이럴 떄는 메시지가 출력되지 않는다. ...
책너두 6기 46일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.473 ~ p.479 내용정리 10 실행계획 10.3 실행계획분석 10.3.12 Extra 칼럼 10.3.12.19 Start temporary, End temporary 세미 조인 최적화 중에서 Duplicate Weed-out 최적화 전략이 사용되면 표시된다. 10.3.12.20 unique row not found 두 개의 테이블이 각각 유니크(프라이머리키 포함) 칼럼으로 아우터 조인을 수행하는 쿼리에서 아우터 테이블에 일치하는 레코드가 존재하지 않을 때 10.3.12.21 Using filesort ORDER BY를 처리하기 위해 인덱스를 이용할 수도 있지만 적절한 인덱스를 사용하지 못할 때는 MySQL 서버가 조회된 레코드를 다시 한번 정렬해야 한다. ORDER BY 처리가 인데스를 사용하지 못할 때만 표시된다. ...
책너두 6기 45일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.466 ~ p.472 내용정리 10 실행계획 10.3 실행계획분석 10.3.12 Extra 칼럼 10.3.12.14 Plan isn’t ready yet EXPLAIN FOR CONNECTION 명령은 MySQL 옵티마이저가 의도된 인덱스를 사용하지 못해서 풀 스캔을 한다거나 잘못된 실행 계획을 선탣한 것이 아닌지 확인할 떄 유용하게 사용할 수 있는 명령이다. 이 명령을 실행했을 때 Extra 칼럼에 “Plan is not ready yet"이라는 메시지가 표시되면, 해당 커넥션에서 아직 쿼리의 실행 계획을 수립하지 모 ㅅ한 상태에서 EXPLAIN FOR CONNECTION 명령이 실행된 것을 의미한다. 따라서, 잠시 후 실행하면 된다. ...
책너두 6기 44일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.458 ~ p.465 내용정리 10 실행계획 10.3 실행계획분석 10.3.12 Extra 칼럼 10.3.12.4 FirstMatch FirstMatch 전략이 사용되면 출력된다. 10.3.12.5 Full scan on NULL key SQL 표준에서는 NULL을 “알 수 없는 값"으로 정의하고 있으며, NULL에 대한 연산의 규칙까지 정의하고 있다. 연산을 수행하기 위해 이 조건은 다음과 같이 비교돼야 한다. 서브쿼리가 1건이라도 결과 레코드를 가진다면 최종 비교 결과는 NULL 서브쿼리가 1건도 결과 레코드를 가지지 않는다면 최종 비교 결과는 FALSE 10.3.12.6 Impossible HAVING 쿼리에 사용된 HAVING 절의 조건을 만족하는 레코드가 없을 때 실행 계획의 Extra칼럼에는 “Impossible HAVING” 키워드가 표시된다. ...
책너두 6기 43일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.449 ~ p.457 내용정리 10 실행계획 10.3 실행계획분석 10.3.6 possible_keys 칼럼 MySQL 옵티마이저는 쿼리를 처리하기 위해 여러 가지 처리 방법을 고려하고 그중에서 비용이 가장 낮을 것으로 예상하는 실행 계획을 선택해 쿼리를 실행한다. 그런데 possible_keys 칼럼에 있는 내용은 옵티마이저가 최적의 실행 계획을 만들기 위해 후보로 선정했던 접근 방법에서 사용되는 인덱스의 목록일 뿐이다. 즉, 말 그대로 “사용될 법했던 인덱스의 목록"이다. 10.3.7 key 칼럼 최종 선택된 실행 계획에서 사용하는 인덱스를 의미 ...
책너두 6기 42일차 백은빈, 이성욱의 Real MySQL 8.0 1권 p.442 ~ p.448 내용정리 10 실행계획 10.3 실행계획분석 10.3.5 type 칼럼 10.3.5.6 ref_or_null ref 접근 방법과 같은데, NULL 비교가 추가된 형태 10.3.5.7 unique_subquery WHERE 조건절에서 사용될 수 있는 IN(subquery) 형태의 쿼리를 위한 접근 방법 10.3.5.8 index_subquery IN 연산자의 특성상 IN(subquery) 또는 IN(상수 나열) 형태의 조건은 괄호 안에 있는 값의 목록에서 중복된 값이 먼저 제거된다. unique_subquery는 중복된 값을 만들어내지 않지만, IN(subquery)에서 subquery가 중복된 값을 반환할 때, 인덱스를 이용해서 제거할 수 있으면 이 접근 방법이 사용된다. ...