안녕하세요. 현재 강의를 수강중인 학생입니다. 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 의 잠금 경합의 결과가 달라질 수도 있나요?

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

안녕하세요, 강의 잘 듣고 있습니다.  강의와 책을 동시에 보면서, 학습을 하고 있습니다. 근데 강의와 도서에서 설명하는 내용에 다른점이 있는 것 같아서 질문드립니다.  REAL MySQL 8.0 (2권) 중 11.4.6 COUNT() 절에서는 아래와 같이 설명되어 있습니다.MyISAM 스토리지 엔진을 사용하는 테이블은 항상 테이블의 메타 정보에 전체 레코드 건수를 관리한다. 그래서 "SELECT COUNT(*) FROM tb_table"과 같이 WHERE 조건이 없는 COUNT(*) 쿼리는 MySQL 서버가 실제 레코드 건수를 세어 보지 않아도 바로 결과를 반환할 수 있기 때문에 빠르게 처리된다.하지만, 강의 Ep.03 COUNT(*) vs COUNT(DISTINCT) 튜닝 에서는 WHERE 절 없는 COUNT(*) 는 제거 대상이라고 설명을 해주셨습니다. 책의 내용처럼 메타 정보에서 가져온다고 한다면 굳이 제거 대상이 될 것 같지는 않은데, 혹시 제가 놓친 배경이 있었을까요? 아니면 이게 뭔가 이분법적인 차원에서 접근하기에는 어려운 내용일까요?  

안녕하세요!14분 쯤 나오는 단일 인덱스 크기와 전체 인덱스 크기가 얼마인지 나오는데, 각각 구하는 계산식을 알 수 있을까요..?어떻게 8바이트가 1억건의 테이블이 있을때 6GB가 되는지 잘 모르겠습니다..8바이트 x 1억 레코드 = 800MB800MB / 1000 = 0.8GB인줄알았는데 따로 계산법이 있는걸가요?추가적으로 필요인스턴스 관련해서 aws에서 계산해보고싶은데 aws요금 계산기에서 Aurora MySQL 서비스 로 검색하면되는게 맞을까요? 서비스 찾기에 Aurora MySQL 검색해도 결과없음으로 나와서요..ㅠㅠ

안녕하세요!좋은 강의 감사합니다!이력 테이블의 대용량 데이터를 저장하기 위해pk값 설정 시 정수형은 제한이 있다고 생각해서시간+uuid로 복합키를 설정하려고 하는데요! 레인지 파티션도 사용하려구 하구요! 이렇게 할 경우 결국엔 String타입으로 저장되서 클러스터링 인덱스가 제대로 저장이 될까? 고민이 있었는데요!이런 고민을 갖고 강의를 보게 되었는데, 강의 내용을 참고해보면uuid값이 정수형보다 길어서 pk로 사용할 경우메모리를 많이 차지해서 메모리크기가 큰 인스턴스를 사용해야 하므로 비용처리가 드는걸로 이해했습니다.uuid대신 snowflake나 sonyflake 라이브러리로 대체하는게 더 좋다고 말씀해주셨는데, 해당 라이브러리가 망하거나(?) 제대로 작동을 안할경우의 위험성도 고려해봐야할것 같다는 생각이 들어서요! 제가 요 라이브러리는 잘 몰라서 여쭤보고자합니다!그래서 질문은 아래 3가지 입니다!Q1. 시간+uuid로 복합키로 pk를 설정하거나, 애플리케이션단에서 시간+uuid만든 String 타입을 pk를 설정하는것보다, snowflake 라이브러리 하나만 사용하는게 더 메모리가 효율적인게 맞을까요?Q2. snowflake가 실제로 현업에서도 많이 쓰이는지 해당 라이브러리가 추후에 제대로 작동을 안할 경우에는 어떻게 대처를 해야 하는지 궁금합니다!Q3. 추가적으로 uuid관련 내용이 Real Mysql 2권 중 어디에 있는지도 궁금합니다! 목차에서는 찾을 수가 없어서요 ㅠㅠ

Select for update 시 lock 을 걸어 원 데이터를 버장힌다는 것은 이해 하였습니다그렇다면 a|b 가 동시 접근 하여 서로 다른 값으로 변경하려는 부분은 없고 동일 프로세스가 두번 진입 할 수 있다고 가정한다면어차피 update 시 xlock이 row에 대하여 획득하니select for update 는 필요없는게 맞다라고 이해를 했습니다이 부분이 맞을까요?

강의 마지막 주의사항 중 아래의 설명이 있었는데요."참조하는 테이블들의 데이터에는 읽기 잠금(Shared Lock) 이 발생하므로, 잠금경합이 발생할 수 있음" 이 부분에 대한 추가적인 궁금증이 있습니다.만약 Product 테이블이 100만건이 있고 Order 테이블을 업데이트 하기 위해 Product 테이블과 JOIN 을 거는 상황이라고 했을 때 업데이트 대상이 되는 Order 테이블에 X 락이 걸리는 것 뿐만 아니라, Product 테이블에도 S락이 걸리므로 다른 트랜잭션에서 Product 테이블에 UPDATE 를 하려고 했을때 lock wait timeout 같은 문제가 발생할수있다는 것일까요?

현재 spring data jpa query + paging 을 사용하고 있습니다. fun findAllFollowing(followerId: Long, pageable: Pageable): List<SnapProfile> = from(snapProfileFollow) .join(snapProfile).on(snapProfile.id.eq(snapProfileFollow.following.id)) .where(snapProfileFollow.follower.id.eq(followerId)) .orderBy(*snapProfile.orderSpecifiers()) .offset(pageable.offset) .limit(pageable.pageSize.toLong()) .fetch() .map { it.following.toModel() }이것을 데이터 개수 기반으로 변경하고 싶은데 혹시 이럴 때 변경해보신 경험이 있으실까요?

utf8mb4 char에서도 varchar와 마찬가지로 변경되는 문자열이 할당된 길이를 넘어버리면 레코드를 다른 공간으로 옮겨야하는 것이겠죠?그렇다면 varchar와 마찬가지로 길이가 자주 변경되는 경우 사용하면 안되겠네요. 맞나요?varchar가 char과 달리 공간을 미리 예약하지 않는다면, varchar(50)에서 50은 무슨 의미인가요?2강에 나오는 메모리 버퍼 크기에만 영향을 주는 것인가요?varchar 타입의 메모리 버퍼 공간은 어떤식으로 사용되는 것인가요?예를들어, 메모리 버퍼 공간을 테이블 1개당 1개 만들어서 재활용한다고 하면 varchar(30)는 겨우 (latin기준) 30바이트, varchar(255)는 겨우 255바이트를 사용하니까 메모리 공간 차이가 별로 없을 것 같습니다.그래서 테이블 1개당 1개만 사용하는 것은 아닐 것 같은데, 가져오는(예상되는?) row갯수만큼 할당해두는 것이려나요?(text 디폴트 관련) 표현식이라는 용어를 처음 들어봤는데요, 표현식이 무엇인가요? 구글에 나이브하게 검색하면 정규표현식만 나오네요.https://dev.mysql.com/doc/refman/8.4/en/expressions.html 이 문서의 expression을 의미하는 것일까요?'abc'와 ('abc') 사이에 어떤 차이가 있는지 궁금합니다.text는 어떻게 저장되기 때문에 row사이즈 제한에 포함이 안되나요?혹시 언제나 오프페이지로 저장되는건가요?

안녕하세요! 페이징 쿼리 관련해서 질문 좀 드립니다방명록(사진) 목록을 조회하는 페이징 쿼리에서 테이블에 soft delete(deleted_at), 공개 여부(is_private) column이 있어서 post.deleted_at is null and post.is_private is false 조건이 자주 들어가는데 커버링 인덱스를 위해 해당 column을 인덱스에 추가하는 것은 어떻게 생각하시나요?

안녕하세요.강의 내용 중에"커넥션 풀을 사용하기 때문에 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직접 입력하기 번거로우시면 여기서 보시면 됩니당