테스트 시 오류

안녕하세요~ 질문 남겨주셔서 감사합니다. 똑같이 따라 한 것 같은데 무결성 제약 조건이 나서 불편하셨겠네요.. 에러 메시지를 보니까 외래 키 제약 조건 위반을 나타내는 것 같네요. 이 경우, ledger_entries 테이블에 데이터를 삽입하려고 할 때 transaction_id 열의 값이 ledger_transaction 테이블의 id 열에 존재하지 않는 값이기 때문에 발생한 것으로 보입니다. ledger_entries 테이블에 삽입하려고 하는 transaction_id 값이 ledger_transaction 테이블의 id 열에 존재하지 않기 때문에 이 에러가 발생한 것으로 보이는데요. 비즈니스 로직이나 테스트 코드 로직을 다시 검토해보시는걸 추천드립니다~ 제 프로젝트에서는 잘되는데 왜 안되는지 모르겠군요..

실무에서 prefix index를 어떤 요구사항이 있을때 사용하는지 궁금합니다!

안녕하세요~ 질문 남겨주셔서 감사합니다. 먼저, Prefix 인덱스는 꽤 다양하게 사용될 수 있는데요. 게시글 본문 내용을 색인하는 경우 이커머스 플랫폼에서 상품 설명이 저장된 긴 내용을 색인하는 경우 로그 데이터나 사용자의 행동을 기록하는 텍스트 필드에서 색인하는 경우 그리고 다음 질문 주신 내용인 prefix index의 한계점도 일부 맞는 말입니다: Prefix 인덱스는 해당 prefix로 시작하는 모든 행을 먼저 찾은 다음, 실제 데이터를 검색하여 추가적인 필터링을 수행해야 합니다. 이렇게 두 단계를 거치지만 인덱스를 사용하지 않는 경우보다는 빠를거에요. 물론 인덱스 검색도 전체 데이터의 20~25%이상 조회하는거라면 풀스캔이 더 빠르긴 하겠죠. Prefix 인덱스는 ORDER BY 나 GROUP BY 절에서의 정렬이나 그룹화 작업에 효과적이지 않아요. 이건 인덱스가 전체 값을 포함하지 않기 때문에, MySQL이 결과의 정확한 순서를 보장할 수 없기 때문이에요. 커버링 인덱스는 쿼리가 필요로 하는 모든 데이터를 인덱스에서 직접 가져올 수 있을 때 사용되는데요. Prefix 인덱스는 필드의 일부만을 포함하므로, 쿼리가 해당 필드의 전체 데이터를 필요로 하는 경우 추가적인 디스크 접근이 필요하기 때문에 사용할 수 없어요.

innodb deadlock detect 비활성화 질문

안녕하세요~ 질문 남겨주셔서 감사합니다. 맞아요. 말씀 주신 내용처럼 매우 높은 동시성을 요구하는 환경이 아니라면 굳이 innodb_deadlock_detect=on 을 할 필요는 없습니다. 대부분의 국내 환경도 트래픽이 높지는 않아서 마찬가지일거에요. 대안 방법의 예시로 Redis 를 드셨는데 만약 Update 와 Insert 트래픽이 엄청 많은 상황에서는 고려해볼 수 있는 설정일거에요. 2번 질문 같은 경우는 innodb_deadlock_detect=off 로 했을 경우에 데드락 상황이 발생했을 때 감지할 수 있는 방법이 없으니 innodb_lock_wait_timeout 값을 짧게 줘서 성능 테스트를 해야할 것 같아요. 그리고 필요하다면 max_connections 값도 같이 증가시키는 게 좋을 수 있을 것 같습니다. 근데 이건 단순히 임시적인 조취일 수 있으니 문제가 일어났을 때 근본적인 해결을 찾는게 무엇보다 중요할 것 같네요. 원래는 dead_lock detect 상황을 실습해보려고 했는데 제 생각보다 더 많은 트래픽이 필요하더라구요. 그래서 로컬 환경에서는 진행하기가 어려웠어서 실습을 제외했습니다...

ssd 에선 innodb_flush_neighbors을 0으로 하면 될까요?

안녕하세요~ 말씀 주신 내용처럼 innodb_flush_neighbors 값은 SSD 에서 0으로 하는 것이 낫습니다. innodb_flush_neighbors 이 설정 자체가 디스크 헤드의 움직임을 줄여서 입출력 성능을 향상시키기 위함이에요. 질문 여러개 남겨주셨네요 ㅋㅋㅋ 열심히 하시는 모습 멋있습니다.

innodb_buffer_pool_instances 기준 질문 드립니다

안녕하세요~ 질문 남겨주셔서 감사합니다. InnoDB 스토리지 엔진에서 innodb_buffer_pool_instances 옵션은 인스턴스의 버퍼 풀을 여러 개로 분할하는 데 사용되잖아요. 그리고 설정은 주로 시스템의 동시성을 높이고, 버퍼 풀에 대한 스레드의 경쟁을 줄이는 목적이구요. 이런 점을 고려헀을 떄 innodb_buffer_pool_instances 의 수는 말씀 주신 내용처럼 다음 내용들을 고려할 수 있을 것 같아요: OS Memory (운영체제 메모리): 일반적으로 innodb_buffer_pool_size 의 전체 크기에 따라 innodb_buffer_pool_instances 를 설정하는데요. MySQL 공식 문서는 버퍼 풀의 크기가 1GB를 초과하는 경우 인스턴스 수를 늘리는 것을 권장하고 있어요. 예를 들면 8GB의 버퍼 풀이 있다면 8개의 인스턴스를 설정하는 걸 권장하죠. 그러면 각 인스턴스는 약 1GB의 메모리를 관리하게 될거구요. innodb_buffer_pool_size 같은 경우는 OS 메모리의 80%로 설정하는 것을 권장하고 있습니다. CPU Cores (CPU 코어 수): 서버의 CPU 코어 수를 기준으로 인스턴스 수를 설정하는 것도 도움이 될거에요. 코어 수가 많다면 더 많은 병렬성을 가질 수 있기 때문인데요. 멀티코어 시스템에서는 각 코어가 효과적으로 동시에 데이터를 처리할 수 있도록 버퍼 풀 인스턴스를 CPU 코어 수보다 많이 설정하는 것이 일반적이므로 CPU 코어가 8개인 시스템에서는 innodb_buffer_pool_instances 를 16 정도로 설정해볼 수 있을거에요. 감사합니다.