728x90 MySQL10 실제DB → 테스트DB 마이그레이션 시간 단축 하기 안녕하세요. 오늘은 예전에 실제로 운영 되는 실제 DB 데이터를 테스트 DB로 데이터를 옮기는 과정중HeidiSQL 같은 GUI 툴로 데이터를 옮기곤 했었습니다.데이터가 많아지다 보니, 시간이 매우 오래 걸리는 상황이 발생하여서시간을 획기적으로 단축할 방법을 찾기 위해 사용한 사례에 대해 글을 쓰고자 합니다. 📍 문제 상황예전에는 DB 마이그레이션을 할 때 DBeaver, HeidiSQL 같은 GUI 툴로 데이터 덤프 후 복원 작업을 진행했습니다.데이터 용량이 크다 보니데이터 이동 및 복원까지 총 20분 이상 걸리는 경우가 많았음네트워크 속도와 디스크 I/O 병목이 심함 🔍 원인 분석 백업 데이터 처리 방식의 차이GUI 툴은 대부분 쿼리 실행 → 응답 → 파일 저장을 반복하는 구조덤프 전체를 한 번에.. 2025. 8. 13. 메모리 기반 Temporary Table(임시테이블)을 활용한 데이터 정확성 + 속도 개선 트러블슈팅 안녕하세요. 오늘은 바빠서 미루었던 트러블 슈팅 했던 경험을 쓰고자 합니다.대규모 계약 통계(지점별) 데이터를 집계하는 과정에서,데이터 정확성과 조회 속도라는 두 가지 과제를 동시에 해결해야 했던 경험이 있습니다. 1. 문제 상황쿼리 복잡성모든 항목(상담 내역, 계약 건수, 계약 비율, 결제 금액 등)을 단일 쿼리로 처리하려다 보니,JOIN과 서브쿼리가 중첩되어 실행 계획이 복잡해지고 성능이 저하됨.데이터 정확성 저하 가능성서로 다른 집계 로직이 얽히면서 일부 항목의 값이 왜곡될 가능성 존재.대용량 데이터 속도 문제매 요청 시마다 전체 데이터를 풀 스캔 → 결과 응답 시간이 길어짐. 2. 해결 전략A. 메모리 기반 임시테이블 설계MySQL MEMORY 엔진 기반의 임시테이블을 사용해 디스크 I/O를 최.. 2025. 8. 12. MYSQL 엔진 성능 최적화 쿼리 최적화를 시도하는 동안, WHERE 절 조건을 아무리 줄여도 2.4초라는 속도가 변하지 않았습니다. 최적화 방법을 지속적으로 검색하던 중, MySQL 엔진의 성능 자체가 낮은 설정이 최적화에 영향을 줄 수 있다는 생각이 들었습니다. 이에 관련된 성능 최적화가 잘 정리된 글을 참고하여 설정을 조정한 결과, 최적화가 성공적으로 이루어졌습니다. 정리된글을 언제든 볼수 있도록 포스팅 하고 싶어 그대로 복사 하였다.MySql 성능 최적화 방안 (옵션 설정값 설명 포함) 1. 기본 설정 Basic Settings에서 생각해 볼 것은 tmpdir을 어디에 둘 것인지 여부입니다.기본으로는 하드디스크인 /tmp에 설정되어 있습니다.여러 번 시행 착오 끝에 리눅스 tmpfs 파일시스템은 일부 임시 파일생성을 허용하.. 2024. 7. 28. 고객 검색 최적화 트러블 슈팅 고객 검색 최적화 트러블 슈팅 경험많은 부분이 부족할 수 있고, 제 경험을 적는 글이니 양해 부탁한다. 이번 글에서는 고객 검색 최적화 작업을 통해 경험했던 트러블 슈팅 사례를 공유하고자 한다.배경기존의 고객 검색은 ORM을 통해 이루어졌으며, 인덱스를 제외한 최적화가 이루어지지 않았다.(2~6초 이상)더 세부적인 검색 요구 사항이 발생함에 따라, ORM을 쿼리문으로 변경하고 최적화에 초점을 맞추고자 했다.전제 조건고객 테이블:고객 테이블의 휴대폰 번호는 하이픈이 포함된 상태로 저장됩니다.고객 등록 시 하이픈 제거된 번호와 하이픈 제거된 번호가 역순으로 저장된 컬럼이 존재합니다.모든 쿼리는 딕셔너리 형태로 저장됩니다.하이픈 제거된 번호와 역순 번호는 STORED 가상 열로 저장됩니다. (STORED, V.. 2024. 6. 2. STORED 컬럼을 이용한 쿼리 최적화 해당 글은 회사 업무 중 스케줄 데이터(약 150만개) 들중 다양한 스케줄 제목(스튜디오 특성 상 사용자가 입력 하기 나름)을 가진 데이터 자체를 최적화 했던 방식을 정리 하는 글이다. 1. 데이터 예시 위의 사진과 같이 다양한 종류가 존재한다. 2. 최적화 전 1. 촬영 스케줄 이름이 돌 과 같은 데이터를 뽑아 내고자 했을때 쿼리문 schedule_title에 인덱싱이 적용 될수도 없는 LIKE문으로 데이터를 뽑아내야 한다. 이는 돌 데이터만 이렇게 뽑아 낸것이고, 만약 돌, 200일, 100일 등등 여러가지 조건들이 한꺼번에 들어가서 쿼리를 작성해야한다면, 상당한 비용이 발생 될것이다. 다른 방안을 찾아야한다!!! 3. 해결 방안 1. 인덱싱 활용 2. 가상 STORED 컬럼 활용 해결 방안으로는 첫.. 2024. 3. 9. [MySQL] Pagination 방법론 업무 중 수 많은 데이터들을 쉽게 보기 위해서 페이지 네이션을 진행 했어야 했다. 페이지 네이션을 위해서 Limit, Offset를 찾아 본 결과, 성능적으로 문제가 많이 있다는 걸 검색을 통해서 알 수 있었다. 조사한 결과를 글로 적어 보고자 한다. 1. 성능 문제 OFFSET을 사용하면 데이터베이스는 지정된 숫자만큼의 레코드를 건너뛴 후 결과를 반환한다. 이는 데이터베이스가 모든 레코드를 실제로 읽은 후에 원하는 오프셋까지 건너뛰는 것을 의미한다. 이는 큰 데이터셋에서는 매우 비효율적일 수 있다. 특히 오프셋이 매우 크거나 데이터셋이 커지면 성능 문제가 발생할 수 있다. 아래의 이미지를 보게 되면 단번에 알 수 있다. 2. 일관성 문제 데이터베이스에서 OFFSET을 사용하여 페이징을 할 때, 새로운 .. 2024. 3. 3. 이전 1 2 다음 728x90
