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 로 확인..등) 해 봤는데, 원인을 찾을 수가 없어 강사님께 도움 청합니다.이 전까지 잘 진행되고 있었고, 현재 진행하는 강좌도 반복해 확인 해 봤는데...위와 같은 이미지 내용만 봐서 찾기 힘드시겠지만, 혹시 하는 심정으로~~도움 부탁 드립니다. 꾸~벅.

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

nestjs 자료 다운로드 받을 수 있다고 하는데, 찾아봐도 도저히 못찾겠네요 어디서 찾을 수 있나요?

typeORM은 0.3.17 입니다. 말 그대로 UserModel 에서 OneToOne 의 relation option "'onDelete: CASCADE'" 로 profile entity 를 삭제했을때 UserModel 이 삭제되지 않고, profile 이 null 로 표기되는 현상입니다.

이미지가 작게 보인다면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 으로 해야 하지 않을까요???? 갑자기 이런 의문이 들어서 질문 드립니다.