안녕하세요.강의 내용 중에"커넥션 풀을 사용하기 때문에 Parse-tree 를 캐시하고 재활용하는 부분이 매우 비효율적으로 바뀔 가능성이 높다"라고 언급하신 부분이 있는데 이 부분이 잘 이해가 안되서 질문드리고 싶습니다. 히카리같은 커넥션 풀을 사용하면 커넥션이 닫히지 않고 계속 재활용하게 되서 이미 캐시된 Parse-tree를 재활용 할 수 있기 때문에 오히려 이점이 있는 것이 아닌가 단순하게 생각이 되는데요, 예를 들어 1번 커넥션에서 A쿼리 패턴으로 PreparedStatement 객체를 생성하여 mysql 서버에 캐시가 되었다면, 다시 동일한 1번 커넥션을 사용하여 A쿼리 패턴을 쓰게 된다면 이미 캐시된 Parse-tree를 재활용하는 것이 아닐까? 이렇게 생각했거든요.어떤 점에서 비효율적으로 동작할 가능성이 있다는 것인지 궁금합니다. 바쁘신데 읽어주셔서 감사합니다.

안녕하세요 좋은 강의 감사합니다.다름이 아니오라 VARCHAR 타입의 경우 자리수가 변경되면 이를 저장하기 위한 여유 데이터 블록(페이지)을 찾고 거기로 이동한다고 하셨는데요Innodb 같은 경우 클러스터드 인덱스다 보니 물리적 블록도 인덱스 기준으로 차곡차곡 쌓이는 것으로 이해하고 있습니다. 그런데 VARCHAR 자리수 변경으로 물리적 블록의 이동이 생긴다면 클러스터드 인덱스 구조를 유지하기 어려워 보이는데 어떻게 유지를 할 수 있는 것인지 혹은 위에 서술한 부분에 잘못 이해한 부분이 있는건지 문의드립니다.

안녕하세요, TEXT 타입 데이터가 저장되는 위치에 대해 궁금한 점이 있습니다.The internal representation of a MySQL table has a maximum row size limit of 65,535 bytes, even if the storage engine is capable of supporting larger rows. BLOB and TEXT columns only contribute 9 to 12 bytes toward the row size limit because their contents are stored separately from the rest of the row.https://dev.mysql.com/doc/refman/8.4/en/column-count-limit.html#row-size-limitsTEXT 컬럼은 레코드가 저장될 때 외부에 저장된 뒤, 해당 위치를 가리키는 포인터 (?) 가 저장되는 것으로 이해가 되는데요. Q. 여기서 말하는 다른 row의 컬럼과 별도로 저장된다는 것이 Off-Page와는 별개의 개념인가요? 연속적으로 저장되는 것이 아닐 뿐 같은 페이지에 저장을 하게 되나요?항상 감사합니다.

ix_fd1, ix_fd2 가 인덱스가 있는 경우인데 아래 쿼리가 어떻게 커버링 인덱스로 사용될 수 있나요?select count(ix_col2) where ix_fd1=?; 오타일까요? (ix_col2 -> ix_fd1 이려나요?)근데 오타라고 가정하고, ix_fd1 이 nullable 이면 해당 칼럼들의 null 여부 확인으로 not null 일때보다 시간이 오래걸릴거 같은데 맞을까요?

강의 자료가 별도로 제공되지 않아서, 책과 함께 복습하려고 하는데 정확히 어디인지 알 수 있으면 좋을거같습니다.

https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-generated-column-operations직접 입력하기 번거로우시면 여기서 보시면 됩니다

https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html직접 입력하기 번거로우시면 여기서 보시면 됩니당

일단 이 강의를 통해서 너무나 좋은 정보를 많이 얻어가서 감사할 따름입니다. Ep.17 강의 마지막의 정리 부분에서 "SKIP LOCKED는 데이터 큐잉 후 배치잡 처리"에 유용하게 사용 가능하다고 하셨는데, 이해가 잘 되지 않아서요. 사례를 조금만 더 설명해주시면 감사하겠습니다.

11강 Prepared Statment 강의를 듣다가 제일 마지막에 server-side preparedstatment는 메모리 부작용이 많으니 client-sid preparestatment를 권장한다고 하셨는데.. client-sid preparestatment를 사용하면 mysql 서버측에서는 statement로 받아들이잖아요. 그러면 바인드 변수값이 아니라 상수값으로 인식하니까동일한 컨넥션 내에서 파싱트리도 공유가 안될테고.. 그런 단점이 있는데도 client-sid preparestatment가 유리한건가요?? 계속 오라클 기준으로 생각해서 그런지 해깔리네요..오라클은 oltp에서 바인딩 변수가 아니라 상수로 사용하면 literal sql로 인식해 커서 공유가 안되니까 항상 바인드 변수를 사용하라고 권장하니까 statment 보다 preparestatment를 자주사용하잖아요.. 두설없이 말씀드려서 죄송합니다. ㅠㅠ 해깔리네요 너무 

질문1오라클에서는 인라인뷰가 복잡해서 pushdown 기능이 작동 잘 안할때 Lateral Derived Table를 쓰는 것으로 알고 있는데, mysql에서는 Lateral Derived Table 자주 사용하나요?? 질문2Lateral Derived Table가 결국 메인 테이블의 조인 조건을 ㅇ인라인뷰 안으로 넣는 것이잖아요. 스칼라 서브쿼리도 마찬가지 인데, Lateral Derived Table과 스칼라 서브쿼리 중 어떤게 더 효율적일까요?.? (만약 스칼라 서브쿼리 반환 레코드 값이 한개일 경우) 감사합니다

멀티컬럼인덱스 개념 5:53분 경부터 설명해주신 내용이 이해가 가지 않는데요,EXPLAIN SELECT hash_email, one_field, two_field FROM test1 WHERE two_field = 3;여기서 idx_col1_col2 인덱스를 타서 two_field = 3인 데이터들의 primary key 목록을 가져올 수 있으니 그를 통해 실제 데이터를 조회하면 hash_email 값도 가져올 수 있는 것 아닌가요?왜 풀스캔을 하는 건지 이해가 가지 않아 질문드립니다.실행 계획 type의 종류를 찾아보니 이런 동작 자체가 없는 것 같기도 하고..아리송하네요

RATERAL 사용할 때 마지막에 ON TRUE 가 있는 것도 있고 없는 것도 있는데 차이가 어떤 것인가요?

안녕하세요. 좋은 강의 감사 드립니다.PrepareStatement 사용 시 메모리 사용률이 증가하는 단점에 대해 다루어주셨는데, 혹시 이 부분을 실제로 확인할 수 있는 메트릭이있다면 공유 부탁 드립니다. 실제로 이 이슈를 재현해보고 싶습니다.

안녕하세요 먼저 좋은 강의 감사드립니다. CHAR vs VARCHAR를 수강하던 중 궁금한 점이 생겨 질문 남깁니다!1. CHAR의 경우 미리 공간을 할당해두기 때문에 update 시 파편화되는 부분이 없지만, VARHAR의 경우 길이가 더 길게 update 시 처음 레코드가 저장되었던 공간은 delete marking 후에 새롭게 빈 공간에 레코드를 저장하는 것으로 이해했습니다. 그렇다면 VARCHAR에서 길이가 더 짧거나 길이가 같게 update를 하는 경우는 어떻게 동작하는걸까요? UTF8MB4 CHAR 경우 미리 할당된 데이터 보다 더 큰 데이터를 업데이트 하게 된다면 VARCHAR 처럼 처음 레코드가 저장되었던 공간은 delete marking후 새롭게 빈 공간에 레코드를 저장하게 되는걸까요? 예시 : CHAR(10)에 '한글'을 저장했다가, '한글 연습'을 업데이트 하는 경우 VARCHAR 처럼 동작하는지가 궁금합니다.   

안녕하세요.강의 잘 보고 있습니다.(너무 감사합니다.)일단 char와 varchar에 대해서는 저는 이전부터 고민이 많았는데요. 이번 강의를 보면서 기존 인터넷에서 보던 자료와 상충하는 내용이 발생하여 질문을 드리고 싶습니다.(물론 '누구의 자료가 잘못됐다'라는 것이 아니라 초보자인 제 입장에서 정말 궁금해서 질문을 드린다는 말씀을 드리고 싶습니다!)사실 내용을 여럿 찾아봤는데 결과적으로 char를 써야 할 경우 TRIM을 통해 공백을 지워야 하기 때문에 그러한 연산이 더 들어가므로 varchar를 쓰는 것이 귀찮음도 없고 좋다라는 글을 보았던 것 같습니다.(백엔드 개발자의 입장에서도 편리하다고 생각합니다.)하지만 varchar를 쓸 경우 말씀해주신 것처럼 데이터의 길이가 기존보다 클 경우 기존 데이터를 삭제하고 새로 옮겨야 하는 비효율적인 작업이 증가할 뿐더러 데이터 페이지의 파편화가 발생할 수 있다는 생각도 정말 충분히 납득이 가는 설명이었습니다.실제로 웬만해서는 char보다는 varchar를 쓰는 편일까요? 아니면 trim의 연산을 하는 것을 감안하고 char를 쓰는 편일까요?

이미지가 작게 보인다면https://cdn.inflearn.com/public/files/posts/2722bc2b-12a3-4512-a5b7-35227283e6ec/aaaa.png여기로 부탁드립니다! 우선 좋은 강의 배포해주셔서 정말 감사드립니다 :) 우선 설명 하기전에왼쪽: A 트랜젝션오른쪽: B 트랜젝션 으로 예시 하겠습니다. 순서를 말씀드리자면 A 트랜젝션 "SELECT * FROM account WHERE id=1;" 구문 실행B 트랜젝션 "SELECT * FROM account WHERE id=1;" 구문 실행B 트랜젝션 "UPDATE account SET balance=balance-150, version=2 WHERE id=1 AND version=1;" 업데이트 실행A트랜젝션 "UPDATE account SET balance=balance-200, version=2 WHERE id=1 AND version=1;" 업데이트 실행B트랜젝션 Commit 실행A트랜젝션 Commit 실행영상에서는 B 트랜젝션을 먼저 Update 문 실행하고 그리고 Commit 을 실행 하고나서 A 트랜젝션을 Update을 하였으니 version 정보가 불일치로 정상적으로 A 트랜젝션은 업데이트가 일어나지 않겠지만 제가 업로드한 이미지 순서대로 하게된다면 즉 A, B 트랜젝션이 동시에 Update를 실행하고이후 동시에 A, B 트랜젝션이 동시에 Commit 을 실행하면 balance 가 0 으로 되지 않을까요? (A 트랜젝션이 맨 나중에 Commit을 했으니깐)반대로 B 트랜젝션이 맨 마지막에 Commit을 하게 된다면 balance 값은 50으로 설정되겠지만 정상적으로 업데이트가 된다고 가정시 balance 값은 -150 이 일어나야 하는데요.이런 케이스 때문에 optimistic Lock 보다 Pessimistic Lock 으로 해야 하지 않을까요???? 갑자기 이런 의문이 들어서 질문 드립니다.

안녕하세요. 우선 좋은 강의 감사드립니다.1강에서 UTF8MB4 셋을 사용하면서 CHAR(10) 을 선언했을 때 기본적으로 할당되는 크기에 대해서 궁금한 부분이 있는데요.UTF8MB4 의 경우 글자당 최대 4 바이트 까지니까, CHAR(10) 이 최초에 10글자 만큼의 공간을 할당받는다고 하면 최대 40바이트가 할당되는 것이 아닌가요??예를 들어 '안녕' 이라는 문자열을 저장한다고 하면 안 (4바이트) 녕(4바이트) 에 문자열 길이를 저장하는 부분 까지 한다고 해도 낭비되는 공간이 있다고 생각했는데, 저장되는 기준이 궁금합니다.

우선 좋은 강의 기회를 주셔서 너무 감사드립니다 :) 출근길 아니면 퇴근길에 영상에 나오는 자료 보면서 공부 할려고 하는데요. 영상에 나오는 자료 공유 해주시면 정말 감사드리겠습니다! 앞으로 좋은 강의 부탁드리고 다시 한번 좋은 강의 기회 주셔서 정말 감사합니다 :)

우선 좋은 강의 기회를 주셔서 너무 감사드립니다 :) 출근길 아니면 퇴근길에 영상에 나오는 자료 보면서 공부 할려고 하는데요. 영상에 나오는 자료 공유 해주시면 정말 감사드리겠습니다! 앞으로 좋은 강의 부탁드리고 다시 한번 좋은 강의 기회 주셔서 정말 감사합니다 :)

강의 영상에 나오는 실습 코드도 공유해주시면 정말 감사드리겠습니다 :)