게시글
질문&답변
2024.07.02
prepardStatement 관련 질문 드립니다
안녕하세요. 말씀주신 아래 내용은 맞습니다. 예를 들어 1번 커넥션에서 A쿼리 패턴으로 PreparedStatement 객체를 생성하여 mysql 서버에 캐시가 되었다면, 다시 동일한 1번 커넥션을 사용하여 A쿼리 패턴을 쓰게 된다면 이미 캐시된 Parse-tree를 재활용하는 것이 아닐까? 이렇게 생각했거든요. 근데, 조금 다른 관점으로 살펴보면, 이게 작동하려면, Connection 단위로 모든 PrepredStatement 객체가 삭제되지 않고 관리되어야 해요. 예를 들어서, 응용 프로그램에서 필요한 쿼리의 패턴이 만약 100개 정도가 있다고 가정해볼게요. 그러면 Connection 단위로 PreparedStatement가 100개씩 캐시되고 있어야, MySQL Server-side에서는 SQL의 Parse-tree라도 재활용될 수 있는거죠. 근데 만약 모든 응용 프로그램에서 사용하고 있는 Connection이 5000라고 가정(예를 들어서 AppServer가 100대이고, 각 AppServer가 Connection을 50개씩 가지는 경우)해보면, App Server에서는 각 서버별로 PreparedStatement 객체를 5000(50 x 100)개를 가지고 있어야 하고, MySQL 서버에서는 500000 (5000 x 100)개의 Parse-tree를 메모리에 가지고 있어야 하는거죠. 근데, MySQL 서버의 preparedstatement 개수는 지정된 개수만 캐시하게 되기 때문에, (동영상에서 언급했던) 또 다른 이슈도 생길 수 있는거죠. 결론은 Parse-Tree가 재활용되지 못한다는 의미가 아니라, 너무 많은 Parse-Tree가 관리되어야 한다는 부분을 지적한 내용이라고 보시면 될 것 같습니다. 감사합니다.
- 0
- 1
- 40
질문&답변
2024.06.30
VARCHAR 타입 길이 변경과 INNODB 관련 질문
안녕하세요. 말씀하신 내용은 맞는 말씀입니다. 그런데 제가 말씀드린 내용은 , 하나의 데이터 페이지 내부에서 레코드의 위치 이동을 밀씀드린 것이엇습니다. 참고로, 하나의 데이터 페이지 내부에서 레코드들은 Array가 아니라 Linked-list구조로 저장됩니다. 감사합니다.
- 0
- 1
- 52
질문&답변
2024.06.29
ep 3 5분 16초 경 설명 질문 있습니다.
비오님, 안녕하세요. 말씀주셨던 오류 부분은 수정해서 동영상 다시 업로드해두었습니다. 감사합니다.
- 0
- 3
- 64
질문&답변
2024.06.29
ep 3 5분 16초 경 설명 질문 있습니다.
안녕하세요. 예제 쿼리에 오타가 있었네요. 말씀하신대로, "ix_col2" 가 아니고 "ix_fd2"가 되었어야 맞는 예제입니다. 빠르게 고쳐서 다시 업로드하도록 하겠습니다. 제보해주셔서 감사합니다.
- 0
- 3
- 64
질문&답변
2024.06.25
각 에피소드가 책의 어떤 장과 연결되는지 알 수 있을까요?
안녕하세요. 동영상 강의의 각 에피소드가 Real MySQL 책의 특정 챕터에 속하는 내용을 설명하고 있지는 않습니다. Real MySQL 책은 MySQL 서버를 학습하는데 있어서 전체 범위를 순서대로 나열해서 설명하고 있는 반면, 동영상 강의는 실졔 예제들을 이용해서 실무에 필요한 중요한 내용들을 위주로 설명드리고 있습니다. 그래서, Real MySQL 각 에피소드는 Real MySQL 책의 한개 챕터보다는 여러 챕터의 내용이 종합적으로 엮여서 설명에 사용되고 있을 가능성이 높습니다. 그래서, 특정 에피소드의 내용이 책의 어느 챕터와 연관이 있다고 1:1로 맵핑시켜서 말씀드리기는 조금 어려움이 있을 수 있습니다. 대신, 동영상 강의를 수강하시면서, 생소한 단어나 기술들이 나오면 해당 단어를 중심으로 Real MySQL 책을 찾아서 학습하시는 방법을 권장드리고 싶습니다. 혹시, Real MySQL 책에서 관련 내용을 찾기 어렵다거나, 그래도 잘 이해되지 않으신다면 인프런을 통해서 질문 주시면, 더 설명을 드리도록 하겠습니다. 언제든지 편하게 문의주시면, 답변드리도록 하겠습니다. 감사합니다.
- 0
- 1
- 89
질문&답변
2024.06.23
14:00 올려주신 공식문서 링크 올립니당
득이님, 안녕하세요. 제가 올려드려야 할 자료를 득이님이 올려주셨네요. ^^ 감사합니다.
- 0
- 1
- 82
질문&답변
2024.06.23
prepardStatement 질문있습니다.
안녕하세요. 우선, PreparedStatement의 효율에 대해서, Oracle RDBMS와 MySQL 서버의 비교는 큰 의미가 없어 보입니다. MySQL 서버에서는 ParseTree까지만 공유된다고 소개드렸는데, ParseTree는 실행 계획이 아니라, SQL 문장을 토큰 단위로 잘라서 의미를 해석해 둔 자료 구조일 뿐입니다. 그래서 MySQL 서버에서는 PreparedStatement가 다른 사용 DBMS 대비 효율이 그다지 좋지 않으면서, 차지하는 메모리 사용량까지 고려하게 만들어서 ... 각 서비스별로 효율성을 확인해볼 필요가 있다는 관점으로 이해해주시면 좋을 것 같아요. 혹시 더 궁금하신 내용은 다시 질문주세요. 감사합니다.
- 0
- 1
- 88
질문&답변
2024.06.17
PreparedStatment 사용 시 메모리 사용 증가
안녕하세요. 먼저 말씀드리고 싶은 내용은, 아래 질문 내용에서 "이슈"라는 표현이, PreparedStatement의 메모리 사용이 버그처럼 느껴지는 듯 한 느낌이 있는데요. 실제로 이 이슈를 재현해보고 싶습니다. Prepared Statement가 메모리를 추가로 사용하는 것은 버그는 아니고, 정상적인 작동 방식입니다. 단지 PreparedStatement를 사용하면 메모리가 더 필요해진다는 것이 이번 강의의 주요 내용입니다. 질문하신 메모리 사용량을 확인하시는 방법은, 아마도 MySQL 서버의 performance_schema가 활성화되어 있다면, 아래 쿼리로 PreparedStatement가 사용하는 메모리 공간의 크기를 확인하실 수 있을 듯 합니다. SELECT event_name, SUM(CURRENT_NUMBER_OF_BYTES_USED) AS memory_used_for_pstmt_as_bytes FROM performance_schema.memory_summary_global_by_event_name WHERE event_name LIKE '%prepare%' GROUP BY event_name ORDER BY memory_used_for_pstmt_as_bytes DESC; +---------------------------------------------------------+-----------+ | event_name | total_mem | +---------------------------------------------------------+-----------+ | memory/performance_schema/prepared_statements_instances | 2031616 | | memory/sql/Prepared_statement::main_mem_root | 61728 | | memory/sql/Prepared_statement::infrastructure | 3072 | +---------------------------------------------------------+-----------+ 여기에서 memory/sql/Prepared_statement::* 이 PreparedStatement 객체가 사용하는 메모리의 크기로 볼 수 있으며, memory/performance_schema/prepared_statements_instances 는 Performance_schema에서 PreparedStatements를 추적할 수 있는 기능이 있는데, 그 테이블이 사용하는 메모리 공간이라 보시면 됩니다. 또한 일반적인 상황에서 PreparedStatement가 사용하는 메모리양이 MySQL 서버를 사용하지 못할 정도의 공간 낭비를 초래하는 것은 아니며, SQL 문장 패턴이 많고 Connection이 많은 서버에서는 매우 많은 PreparedStatement가 필요해지고, 이런 경우 메모리 사용량이 높아지는 경우가 발생할 수 있으며, PreparedStatement가 사용하는 메모리 량을 고려해서 다른 메모리 설정을 적용해야 한다 정도로 이해해주시면 좋을 것 같습니다. 감사합니다.
- 0
- 1
- 106
질문&답변
2024.06.14
CHAR VARCHAR 질문입니다!
안녕하세요. 1번 : 레코드의 길이가 부족하지 않기 때문에, 다른 위치로 옮겨지지 않고 그 자리에 업데이트됩니다. 2번 : CHAR 타입의 길이가 얼마냐에 따라서 다릅니다. 동영상 강의 내용의 예제에서 언급했던 CHAR(10) 타입의 경우, "한글"을 저장하면 6바이트를 사용하고 4바이트는 비워두지만, "한글연습"으로 업데이트되면 12바이트가 필요해져서, 최종적으로는 다른 위치로 레코드가 옮겨지게 됩니다. 만약 "한글"에서 "한글날"로 업데이트되면 9바이트만 필요하기 때문에 위치가 옮겨지지 않고 그 자리에 그대로 업데이트될 수 있을 것으로 보여요. 감사합니다.
- 4
- 1
- 196
질문&답변
2024.06.14
실제 프로젝트에서의 데이터 타입 환경
안녕하세요. 답변드린다는 것을 깜빡하고 있었네요. 죄송해요. 사실 내용을 여럿 찾아봤는데 결과적으로 char를 써야 할 경우 TRIM을 통해 공백을 지워야 하기 때문에 그러한 연산이 더 들어가므로 varchar를 쓰는 것이 귀찮음도 없고 좋다라는 글을 보았던 것 같습니다.(백엔드 개발자의 입장에서도 편리하다고 생각합니다.) 아래 2개 비용을 비교해서 말씀을 하셨는데, 사실 1번과 2번은 작업 내용상 비용 비교가 될 수 있는 수준이 아닙니다. 정확하게 수치로 말씀드리긴 어렵지만, 대략 예를 든다면, 1번 작업이 마이크로 초 단위의 작업이라면 2번 작업은 밀리초 단위의 작업이 될 가능성이 높습니다. CHAR(*) 타입 컬럼의 값을 TRIM()으로 공백을 지우는 비용 파편화로 인한 공간 낭비 및 Row-migration(변경시 레코드 이동) 비용 그리고 MySQL 서버에서는 CHAR 타입과 VARCHAR 타입 모두 MySQL 서버에서 문자열 뒤쪽의 Space는 기본 Trim하고 Client로 내려 보내기 때문에 (옵션에 따라 다를 수 있지만, 기본 작동 방식 기준으로), AppServer에서 space trim 작업을 별도로 하실 필요가 없습니다. 실제로 웬만해서는 char보다는 varchar를 쓰는 편일까요? 아니면 trim의 연산을 하는 것을 감안하고 char를 쓰는 편일까요? 이미 말씀드렸듯이, TRIM 연산 비용보다는 CHAR로 인한 공간 낭비가 VARCHAR의 Fragmentation 대비 효율적이라는 근거만 있다면, CHAR 타입을 사용하는 것이 좋아 보입니다.
- 2
- 1
- 204