ep11) Prepared Statement에서 질문

도현님, 안녕하세요. Client side preparedstatement에서도, 바이딩되는 값에 대해서 따옴표나 특수 문자들에 대해서 필요한경우, 자동으로 Escape 처리를 해주기 때문에 SQL Injection을 막을 수 있다는 의미입니다. 감사합니다.

12강 FULL GROUP BY

조혜륜님, 안녕하세요.GROUP BY 절에 명시되지 않은 컬럼에 대해서 집합 함수(Aggregation func)을 사용하면 FULL-GROUPBY 규칙에 위배되지 않습니다. 그래서 ppt에서 SUM 함수를 사용했기 때문에, 이는 문법상 문제 없는 쿼리가 되는 것입니다. 감사합니다.

7)select for update 강의에서 질문

도현님 안녕하세요. 넵, AI가 알려준 내용은 잘못된 것입니다. 격리 수준에 관계없이 트랜잭션내에서 FOR UPDATE로 잠겨진 레코드는 트랜잭션이 완료되어야 잠금 해제됩니다. 감사합니다.

deternmistic 질문

안녕하세요.결론적으로 , 모든 함수를 전부 deterministic 으로 명시를 해줄경우 단점이 무엇인가요??함수가 NOT-DETERMISTIC이어야 하는 경우가 있지 않을까 싶긴 한데요. 왠만한 서비스 요건에서는 이런 경우를 거의 보지 못했었어요. 그래서 서비스별로 요건을 검토해서 NOT-DETERMINISTIC일 필요가 없다면, 반드시 Stored Function에 DETERMINISTIC 키워드를 명시해서 사용하는 방법을 권장드린 것입니다.이건 서비스의 특성에 따른 요건이기 때문에, 단정적으로 모두 DETERMINISTIC으로 정의해서 사용해도 된다고 제가 말씀드리긴 어려운 부분인 듯 합니다. 감사합니다.

5강에서 사례로 언급하신 DETERMINISTIC 예제에 대해 질문있습니다.

안녕하세요.넵, 제가 설명드린 의도를 정확히 이해하신 것으로 보입니다.감사합니다.

시퀸셜하게 증가하지 않는 PK의 insert성능도 문제가 있을까요?

안녕하세요. 정렬되지 않은 랜덤한 값을 PK로 사용하시면, 성능상 2가지 이슈가 될만한 부분이 있어요.매번 INSERT할 때마다 저장할 위치의 데이터 파일 영역(block)을 디스크에서 메모리로 가져와야 함매번 INSERT되는 위치가 랜덤이기 때문에, 데이터 페이지가 꽉 채워지지 않고 파편화될 가능성 높음 이런 경우, 만약 테이블이 커진다면 많은 성능 저하가 발생할 수 있고,이를 해결하기 위해서 많은 메모리가 필요해질 수 있어요. 이에 대한 설명을 UUID 에피소드에서 설명드린 것이었어요. 감사합니다.

EXPLAIN ANALYZE 수행 시 쿼리 실행 계획이 예상과 다릅니다.

bada.kang님 안녕하세요. 네, 말씀하신 내용이 맞습니다. 하지만 책에서 소개하고 있는 내용은 대략적으로 쿼리의 실행 순서를 이해할 때의 규칙 정도로 이해해주시면 좋을 것 같아요. 실제로는 쿼리의 모양과 실행 특성들을 조금씩 같이 Mix해서 실행 계획을 읽어야 정확한 순서를 확인할 수 있습니다. 책의 쿼리에서 D 작업은 독립적으로 실행(조인의 드라이빙 테이블 읽기)될 수 있는 작업이지만, F 작업(조인의 드리븐 테이블 읽기)은 후속으로 실행되는 작업입니다. 그래서 들여쓰기가 더 깊이 들어간 것은 F 작업이지만, D가 먼저 실행되는 구조인 것입니다. 그렇다고 해서, 들여쓰기가 많이 들어간 작업이 먼저 실행되는 작업이라고 단정지을수도 없습니다. 이 실행 계획의 바로 위에 보시면 D~F 작업이 완료되어야, 비로소 상위에 있는 B (그룹핑 작업) 작업이 실행되기 때문입니다. 사실 실행 계획의 들여쓰기는 작업의 묶음 개념 의미가 크기 때문에 ... 들여쓰기만으로 쿼리의 실행 순서를 단정하기에는 한계가 있긴 한 것입니다. 다음 인쇄판에서는 조금 더 이해도를 높이기 위해서, 여기에서 말씀드린 부분까지 같이 포함하도록 책 내용을 보완해보겠습니다. 감사합니다.

조건 없는 COUNT(*)에 대한 궁금증

Bemelon님, 안녕하세요.인프런 질의 응답 시스템이 문제인지, 질문을 놓치는 경우가 많네요. 2~3일에 한번씩 질문 답변을 달고 있는데... 요 질문은 놓치고 있었네요. Real MySQL 8.0 2권의 내용을 다시 확인해시면, 말씀하신 부분은 "MyISAM" 테이블에 대한 부분이었다는 것을 확인하실 수 있을거에요. 그 문장 뒤에 이어서 나오는 문장을 보시면 "InnoDB"에서는 레코드 카운트가 필요하다는 이야기가 보이실 거에요. 그리고, 동영상 강의에서는 InnoDB를 기본으로 설명드린 것이어서, 조금 혼란을 드린 듯 합니다.최신 MySQL 서버에서는 MyISAM 스토리지 엔진이 거의 사용되지 않고, InnoDB 스토리지 엔진이 대부분이어서... 동영상 강의에서는 InnoDB 스토리지 엔진을 기본으로 설명이 되고 있다고 보시면 될듯 합니다. 다시 한번 늦어진 답변 죄송합니다.감사합니다.

Select for update locking

경수님, 안녕하세요.요거 질문을 제가 놓치고 있었네요. 말씀주신 것처럼, 동시에 여러 세션이 특정 레코드에 접근하는 것이 아니고,한 시점에 반드시 하나의 세션에서만 특정 레코드를 변경한다면, 말씀하신 것처럼 SELECT FOR UPDATE는 필요치 않을 듯 합니다. (그런데 이런 보장이 쉽지 않아 보이긴 합니다만...) 다시 한번 늦어진 답변 죄송합니다.

없는데이터에 select ... for update 쿼리시에 Lock

안녕하세요. SELECT .. WHERE ... FOR UPDATE 쿼리에서 WHERE 절에 일치하는 레코드가 없으면,MySQL 서버는 다른 세션에서 WHERE 절에 일치하는 레코드가 INSERT되지 못하도록 Gap Lock을 걸게 됩니다. 그게 첫번째 그림의 Supremum pseudo-record - X lock 이에요. 근데 Gap lock은 X-lock과 S-Lock으로 구분되긴 하지만 사실 둘 모두 S-lock으로 작동합니다. 즉, Gap lock은 X-lock끼리도 호환이 되어서, 두 세션에서 SELECT .. WHERE .. FOR UPDATE 문장이 아무런 잠금 경합없이 동시에 실행 가능하게 되는 것입니다. 감사합니다.