안녕하세요. 우선 이렇게 좋은 강의 해주셔서 감사합니다. 강의를 듣다가 궁금한 부분이 있어 질문드립니다.Q1) 10:00분 경에 "CHAR여도 utf8mb4같은 가변길이 캐릭터 셋을 사용하면 때로는 예약된 빈 공간이 없을 수 있다"라고 말씀해 주셨는데요. 제가 강의를 듣고 이해하기로는 '1~4byte값을 가질 수 있다는 가변길이 캐릭터 셋' 성질 때문이 아니라 '문자 하나당 크기가 1byte를 초과했기 때문에' 예약된 빈 공간이 없어지는 걸로 생각했습니다. 즉, 가변길이 캐릭터 셋인 utf8mb4가 아닌 하나당 크기가 3byte인 어떤 고정길이 캐릭터 셋을 이용하더라도 동일하게 예약된 빈 공간이 없을꺼 같은데 혹시 제가 이해한게 맞을까요?Q2) 마지막 내용 정리하시는 부분에서 "인덱스된 컬럼이라면 CHAR가 효율적일 가능성이 더 높다"고 말씀해 주셨는데 어떤 이유로 인덱스된 컬럼에 CHAR가 더 좋을 가능성이 높은건지 알려주실 수 있으실까요? 

좋은 강의 제공해주셔서 감사합니다!강의를 듣다보니 의문점이 하나 생겼는데요. 에피소드 14의 시퀸셜하지 않은 UUID사용시 범위 검색의 조회 효율성 문제를 언급해주셨는데요 데이터 삽입시 인덱스가 리밸런싱되거나 리프노드의 실제 데이터 위치가 이동하는 문제가 발생할수도 있을까요?  

먼저 강의 내용이 아닌 책내용을 질문하게 되서 죄송합니다. 하지만 여기 말고 질문할 곳이 마땅치 않아 부득이하게 이곳에 적게 되었습니다. 부디 사정을 봐주시길 부탁드립니다. Real MySQL 1권의 10.2 실행 계획 확인(415pg)에서는 EXPLAIN ANALYZE 실행 시 나타나는 결과에서는 다음과 같은 규칙이 적용된다고 설명되어 있습니다. 들여쓰기가 같은 레벨에서는 상단에 위치한 라인이 먼저 실행들여쓰기가 다른 레벨에서는 가장 안쪽에 위치한 라인이 먼저 실행 이 말대로라면 아래 그림에서의 실행순서는 F, D, E, C, B, A 가 됩니다. 하지만 책에서는 실행순서가 D, F, E, C, B, A 로 된다고 적혀있습니다. 들여쓰기가 다른 레벨에서는 가장 안쪽에 위치한 라인이 먼저 실행된다고 하여 F 가 가장 먼저 실행될 줄 알았는데 D 부터 시작된다고 적혀있어서 혼동이 왔습니다. 혹시 왜 D 부터 시작하는지 설명을 부탁드릴 수 있을까요?감사합니다.  

안녕하세요. 현재 JPA를 사용하고있는데 말씀해주신대로 varchar(255)를 기본 string 값으로 잡고있더라고요 이부분을 필요한만큼 테이블수정을 기하는것이 좋은 설계인것인가요? 아니면 jpa 기본권장스펙대로 가는게좋은건가요?

안녕하세요. 강의를 잘 듣고 있는 수강생입니다.강의를 듣다가 좀 다른 결일 수도 있는 궁금증이 있습니다.범위기반 데이터 조회에 아래 예시에서 order by finished_at, id 부분에서 finished_at이 범위검색 쿼리로 들어가는데 이런 경우 뒤에 있는 id는 인덱스를 타지 않는 것으로 알고 있습니다. 그럼 id로 범위 검색하려고 하면 finished_at으로 검색된 범위 안 전체 데이터를 전부 스캔하게 되나요?select * from payments where finished_at ≥ ‘시작날짜’ and finished_at < ‘종료날짜’ and id > 8 order by finished_at, id limit 30

안녕하세요. Deadlock Case 4분 45초 예제가 어떤 상황을 말씀하시는건지 잘 이해가 안돼 질문남깁니다.다음과 같이 설명해 주셨는데요```1. 테이블 A/B, 트랜잭션 X/Y가 존재2. 트랜잭션 X는 A테이블을 수정, 트랜잭션 Y는 B테이블을 수정3. 2번의 두 요청은 멀티스레드 환경에서 거의 동시에 요청이 들어옴4. 이후 A테이블에서는 세션으로서 전송이 되어서 한 번에 처리를 하려 함5. X트랜잭션은 A테이블을 수정한 다음 B테이블을 수정하려 함...```5. X트랜잭션은 A테이블만 수정한다 했던거 같은데 B테이블은 왜 수정하나요?4. 세션으로서 전송이 되어서 한 번에 처리를 하려한다는게 어떤 얘기일까요? 5번과 연관지어 생각했을 때 하나의 트랜잭션에 여러 요청이 들어오는 걸 세션으로 전송된다고 말씀하신건가요? 그래서 하나의 세션에 A테이블을 수정하는 작업과 B테이블을 수정하는 작업 두개가 들어온거일까요?

제목 그대로 입니다.저는 지금 11.4.2-MariaDB-ubu2404 버전을 사용 하고 있는데요.. lateral 키워드를 인식을 못합니다.검색 해서 알아보니 마리아디비 및 mysql 에서는 lateral 키워드를 완벽히 지원 못한다는 내용이 있던데요..원래 PostgreSQL 에서 지원하는 기능 이었다고 하던데요.. mysql 8 강의에서 소개를 하고 있다면 사용 가능한 것 일텐데..저의 데이터베이스 세팅 등이 이상한 걸까요?mysql 8 버전으로 테스트를 해봐야 할까요?lateral 설명을 보니 많은 도움이 될 것 같아 꼭 사용 하고 싶은 기능인데.. 왜 안되는지 알 수가 없네요.. 왜 그럴까요??SELECT e.emp_id, e.emp_name, l.recent_salary, l.salary_dateFROM employees eLEFT JOIN LATERAL ( SELECT salary AS recent_salary, date AS salary_date FROM salary_history sh WHERE sh.emp_id = e.emp_id ORDER BY date DESC LIMIT 1) AS l ON TRUE;하면SQL Error [1064] [42000]: (conn=9) You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '(이런 에러가 생깁니다.LATERAL 을 인식 못하는 것 같습니다.   

varchar 타입의 경우 데이터 업데이트시 파편화가 생길 수 있다는 점을 이해했습니다! 다만, char 타입을 쓰면 좋은 경우가 문자열의 길이가 가변성이 크지 않은 경우라고 한다면varchar의 경우에도 길이 가변성이 크지 않은 탓에 처음부터 선언해둔 길이를 벗어나지 않을 가능성이 클 거 같다는 생각이 들었습니다. 만약 주민등록번호라고 한다면 13자리니까char(13)로 하거나 varchar(13)해도 이 자리수를 넘어가지 않을 것이고자주 업데이트 되는 경우라고 해도 char도 그렇고 varchar도 그렇고 길이수만 잘 잡아놓으면fragmenation 문제가 없는 것이 아닌지 궁금합니다. 그럼에도 char를 쓰는 것이 더 좋은 이유가 있을지 궁금해서 질문남깁니다!

안녕 하세요..실제로 count(*) 때문에 고민이 많습니다.게시판 형태의 화면이 있는데요..데이터가 약 250만건 정도 입니다.조인된 테이블은 6개 이고요..테이블 6개를 조인 해서 보여주다 보니 검색 조건은 매우 많습니다.페이징을 20개씩 10페이지씩 보여주고 있는데요..강의 내용 대로 전체 count(*) 때문에 속도가 느립니다.전체 갯수를 소스 상에 써 놓고 테스트를 해보면 속도가 느리지 않거든여..강의를 보기 전에도 테스트 해본 결과 속도는 전체 갯수의 count(*) 문제 라고 판단 하고 있었는데요..시스템의 로우 갯수를 사용 하는 방법이나리눅스의 cron 으로 각 테이블의 갯수를 10분 단위로 입력 하는 것 등..여러가지 생각을 해보았으나..검색 때문에 포기 했습니다.검색을 하면 검색 결과에 대한 전체건수가 나와야 하는데..이건 실시간 아니면 파악할 수가 없으니까요..강의를 보면서 힌트를 얻고자 했으나..대략적인 건수..임의의 페이지 표기 통계 이용대략 이해는 됩니다만..만일 검색을 하게 되면..모두 사용 할 수 없는 것 아닌가요?강의 에서 얘기한 것들은 모두 아무런 조건이 없을 경우 이고..예를 들어 검색 조건이 10가지 정도 될 경우 어떤 조건으로 검색할 지 모르는 상황인데대략적인 건수를 표시할 수도 없고 임의의 페이지를 표시할 수도 없습니다.예를 들어 검색 조건 시 1개도 없는 경우도 있을 수 있는데..어떻게 대략적인 건수를 표시를 할 것이며..임의의 페이지를 표시 할 수 있을까요..검색결과가 1건도 나오지 않았는데 페이지를 1~10 까지 대략적으로 표시할 수는 없는 것 아닌가요?통계이용은 검색 시 더더욱 사용할 수 없고요..제시하신 방법으로는 문제가 해결 될 것 같지 않은데..제가 잘못 생각 하고 있는 걸까요?제 생각이 틀렸으면 좋겠습니다만..방법이 있을까요?

안녕하세요. Skip Locked For Session 강의를 보다가 궁금증이 생겨서 질문을 하게 됐습니다. Skip Locked For Session 12:14초의 내용을 보면 왼쪽 터미널에서 SELECT * FROM testLock WHERE name = "ax" order by seq limit 3 for update skip locked쿼리를 통해서 1개의 row를 받아오는 장면이 나오는데요.오른쪽 MySQL Workbench에서 트랜잭션을 실행하고 SELECT * FROM testLock WHERE name = "ax" order by seq limit 3 for update를 통해 Lock을 잡고 있는 상황인데 어떻게 왼쪽 터미널(다른 세션)에서 name이 ax인 row를 가져올 수 있는지 궁금합니다. skip locked 설정이 들어갔으니 lock이 걸린 데이터 (name이 ax인 row)는 못 가져와야 하는거 아닌가요 ?? skip locked를 제외했을 때는 lock 걸린 데이터를 가져와야 하니 timeout이 나는 상황은 이해를 했습니다.

안녕하세요.예시를 위해 테이블명을 변경했습니다. 도메인상 이해안되도 이해부탁드립니다..!바로 질문으로 들어가면 아래에 쿼리를 발생시키면 supremum pseudo-record 락이 생기게 됩니다. 하지만 여기서 다른 세션에서 아래 쿼리를 똑같이 실행하면 select for update에서 락대기가 걸릴거라고 예상했는데 START TRANSACTION; #1 #reader_id+name 조합으로 유니크인덱스 사용중 SELECT * FROM book b WHERE reader_id = 21 AND name = 'ABC' FOR UPDATE; #2 INSERT INTO book VALUES (null, 'ABC', 21); #3아래 처럼 같은 락이 추가됩니다. 그래서 두 세션중 어느세션에서 insert 쿼리를 입력하든 Lock 대기가 걸리게됩니다. select에서 락대기가 걸리길 바랬는데 insert를 해야 락대기가 걸리는 이유가 무엇인가요?답변 미리 감사합니다.

"테이블 파티셔닝이 필요한 이유"중에 "자원 사용 효율 증가 및 쿼리 성능 향상"을 언급주셨습니다.예를들어 최근에 저장된 데이터들 위주로 조회하는 경우 파티션 프루닝을 통해 최근 데이터만 접근하니까 효율적이라는 내용인데요, 효율적인 부분이 제가 생각했을 때 아래 2가지 정도인 것 같습니다.테이블의 모든 row를 접근 안해도 되고 더 적은 데이터만 읽어도 됨버퍼풀에 자주 사용되는 일부 데이터만 로드해도 됨여기서 질문이 있습니다. 파티셔닝키를 대상으로 인덱스를 걸면, 마찬가지로 최근 데이터만 접근가능하고, 버퍼풀에 최근 데이터만 올라가지 않나요?인덱스를 거는 방식이 파티셔닝을 사용하는 것에 비해 어떤 점에서 부족한가요?

"DeadLock 예시(2)"에서 INSERT구문이 UNIQUE를 보장하기위해 shared lock을 걸고 확인한다고하였는데요, 그냥 처음부터 exclusive lock을 걸고 값을 확인하게 구현할 수도 있을 것 같은데, 그렇게 안되어있는 특별한 이유가 있을까요?exclusive lock을 건 상태에서는 값이 있는지 확인이 불가능하다 (shared lock을 걸었을때만 가능하다)그냥 어쩌다보니 MySQL이 그렇게 구현되어있다.lock경합을 줄이기위한 의도로 이렇게 구현했다?제가 생각나는 이유는 위 2개 정도인데, 어떤 이유인지 아실까요?

에피소드 15에서 복합 인덱스의 경우 순서가 중요하다고 하셨는데요.그럼 인덱스 생성 시 (account_type, joined_at) 와 같은 순서일때 조건에 joined_at account_type 순서로 주어지면 인덱스를 활용하지 못하는게 맞을까요??

안녕하세요. 질문 드립니다.1:N 구조의 웹 어플리케이션입니다.종종 동일한 insert 요청이 짧은 시간에 발생 합니다.insert는 N(child) 테이블에 되어야 합니다.해당 테이블에는 유니크 제약조건이 걸려있어서 중복 데이터는 절대로 insert 되지 않지만 동일 요청에 의해서 DeadLock이 발생하고 있습니다.(물론 빈도는 많지 않습니다.)실행 순서는 이렇게 됩니다.Parent테이블의 id를 이용해서 join 쿼리로 select 합니다. (child 테이블 존재 여부 확인)child 테이블에 데이터가 존재한다면 수량 증가, 없다면 insert를 합니다.이 때 데이터가 없는 상황에서 select-insert 요청이 서로다른 tx에서 발생할 때 데드락이 발생합니다.이 경우 어떤 전략으로 회피할 수 있을까요?유니크 제약 조건에 의해서 중복 데이터가 생기는건 방지되고 있고, 데드락 자체가 하루 한 건 정도 발생하고 있어서 시스템 운영상에서는 문제가 없으나 어떤 해결책이 있을지 궁금합니다.

안녕하세요. 현재 강의를 수강중인 학생입니다. RATERAL 사용 관련되어 질문이 있어 글 남겨드립니다.  잘못된 지식일 수 있지만, 서브쿼리를 사용하면 DBMS에서 지원하는 최적화를 지원받지 못해 서브쿼리를 사용하는 것보다는 최대한 조인을 사용하거나 차라리 쿼리를 나눠서 사용하는 것을 권장한다고 알고 있었습니다. 그런데 해당 강의를 수강하고 LATERAL의 사용을 적극 권장하셔서 제가 알고 있는 지식과 충돌하는 것 같습니다 혹시 어떤 경우에 LATERAL을 사용 하는 것이 좋을 지 여쭤보고자 글을 작성합니다.감사합니다. 

안녕 하세요..이런 질문을 드려도 될까 모르겠습니다만..현재 운영 되는 사이트는 ms-sql 로 bak 파일 기준 약 50기가 정도 됩니다.사이트를 개편 하려고 하고 있는데요..mysql 로 바꾸는 것을 논의 중 입니다.처음 부터 데이터가 50기가 가 입력 되는 것은 아니고..운영 하면서 데이터가 늘어날텐데.. 경험 상 50기가 정도 될 것으로 예상 됩니다.특정 테이블은 몇천만건의 데이터가 입력 될 수도 있는데요..mysql 이나 mariadb 로 이 정도의 데이터베이스를 운영 할 수 있을지..사이트 속도 에는 큰 문제가 없을지..조언 부탁 드립니다.감사 합니다.

안녕하세요. 이제 2회차로 다시 잘 보고 있는 수강생입니다 🙂 Ep15를 보던 중 복합 인덱스의 컬럼들 중 선행컬럼을 조건에서 누락할 경우 풀 스캔이 될 수 있다고해서 직접 쿼리를 실행해봤습니다. 환경: MySQL 8.2.0쿼리explain select * from users where joined_at > '2022-07-24 00:00:00';결과8.0.21버전부터는 인덱스 스킵 스캔을 통해 선행 컬럼이 조건에 포함되지 않아도 후속 컬럼을 이용해 인덱스 일부 활용이 가능하다고 하는데 이 때문에 위와 같은 실행 계획나 나온걸까요?

예제에서는 WHERE 절 때문에 LEFT JOIN이 INNER JOIN으로 최적화되는 것으로 알고 있지만 만약에 LEFT JOIN으로 걸릴 수 있는 쿼리라면 SKIP LOCKED 의 잠금 경합의 결과가 달라질 수도 있나요?

질문 내용은 제목 그대로 입니다!