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

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

29-Jun-2024 16:47:09.258 INFO [mysql-cj-abandoned-connection-cleanup] org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading 불허되는 접근: 이 웹 애플리케이션 인스턴스는 이미 중지되었습니다. []을(를) 로드할 수 없습니다. 디버그 목적 및 불허되는 접근을 발생시킨 해당 쓰레드를 종료시키기 위한 시도로서, 다음 스택 트레이스가 생성됩니다. java.lang.IllegalStateException: 불허되는 접근: 이 웹 애플리케이션 인스턴스는 이미 중지되었습니다. []을(를) 로드할 수 없습니다. 디버그 목적 및 불허되는 접근을 발생시킨 해당 쓰레드를 종료시키기 위한 시도로서, 다음 스택 트레이스가 생성됩니다. at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading(WebappClassLoaderBase.java:1328) at org.apache.catalina.loader.WebappClassLoaderBase.getResource(WebappClassLoaderBase.java:960) at com.mysql.cj.jdbc.AbandonedConnectionCleanupThread.checkThreadContextClassLoader(AbandonedConnectionCleanupThread.java:123) at com.mysql.cj.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:90) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833)이런 메시지가 나오면서 404 에러가 뜹니다.

안녕하세요, 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 일때보다 시간이 오래걸릴거 같은데 맞을까요?

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

고객코드에 대해서 NN에는 Yes의 Y가 들어와야하는 것 아닌가요??

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과 스칼라 서브쿼리 중 어떤게 더 효율적일까요?.? (만약 스칼라 서브쿼리 반환 레코드 값이 한개일 경우) 감사합니다

혹시 언제쯤 강의로 볼 수 있을까요 ㅠㅠpart1 내용이 너무 좋아요

https://algoalgo.notion.site/Payment-Service-88c97b1300cd4224b5790b328ab0e9dc페이지에 Payment Order 테이블 스키마 내용중 order_id 컬럼이 UNIQUE 로 작성되어 있습니다. 강의 내용과 맞지 않는 부분이라 수정이 필요해 보입니다.

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

안녕하세요 강의 들으려고 구매했습니다!혹시 CURS에 대한 내용은 이 강의에서 다루지 않나요??

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

interface를 class로 인식하는 것 같아요 

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

강의 잘 듣고 있습니다.아래 이미지와 같은 오류가 뜨면서 여러가지(db 삭제, Docker 재 시작, 서버 재 구동, debugger 로 확인..등) 해 봤는데, 원인을 찾을 수가 없어 강사님께 도움 청합니다.이 전까지 잘 진행되고 있었고, 현재 진행하는 강좌도 반복해 확인 해 봤는데...위와 같은 이미지 내용만 봐서 찾기 힘드시겠지만, 혹시 하는 심정으로~~도움 부탁 드립니다. 꾸~벅.