Hello backEnd

부분 인덱스그냥 간단하게 말하자면 인덱스 기준을 전체가 아니라 일부분에만 거는 것이다.이게 뭐임말 그대로 부분적인 인덱스개발할 때에 MySQL 에서 VARCHAR(255) 이런 식으로 좀 큰 데이터를 사용하는 경우가 있는데, 이런 큰 값에 대해 인덱스를 걸어주는건 힘들다.근데 이거 뒤에까지 다 쓰지는 않지만 앞부분에 대한 검색이 종종 일어날 수는 있다.장점인덱스 크기 설정 가능일부분에 대해서만 인덱스를 생성하기 때문에저장 공간이 절약된다.인덱스 조회 속도가 향상된다.인덱스 생성할 때에 시간소요가 줄어든다.말하자면, 그냥 작은 인덱스를 만들기 때문에 전체를 다 만드는 것 보다 확실히 공간이나 속도 면에서 장점이 있다는 것이다.단점?인덱스 크기를 설정해서 발생일부분에 대해서만 인덱스가 생성되기 때문에유니크 ..

MySQL 8.0부터 추가된 explain analyze 에 대해 ARABOZA!MySQL에서 쿼리 인덱스랑 실제 동작 관련 테스트를 하는데... 엄청 많은 조건이 있어서 대체 어디서 시간이 오래걸리는지 이런거가 매우 헷갈렸다.이 때에 아주 유용한게 explain analyze 이다.사실 이거 보면 매우매우 잘 설명되어있기는 한데 걍 정리해본다.실제로 경험한 일인데, 상세한 내용을 말하기는 어렵고 통해 그냥 이거의 장점만 훑으려 한다.일단 기존의 explain 과 다른 점은explain은 실제로 SQL 쿼리를 실행하지 않은 상태에서 옵티마이저가 계획한 쿼리 실행 계획을 보여준다.explain analyze 는 쿼리를 실제로 실행한 뒤에 그 결과를 통해 실행 계획을 보여준다. 또, 실제로 실행하면서 각 단..

인덱스 이거 매우매우매우 중요!! 인덱스? 책 마지막의 색인으로 비유한다. 말하자면 DBMS의 모든 데이터를 찾아오는거는 힘드니까 key-value로 값-주소를 인덱스로 만들어 두는 것이다. 이거를 정해진 순서에 맞춰서 만들어두는것 정리하면, 본래 데이터는 순서 상관 없이 저장 되고 인덱스는 설정한 순서에 따라 정렬된 key value 쌍을 만들어둠 으로 이를 활용해서 해당 데이터를 찾는 방식이다. 이거는 보면 알겠지만 select에서는 성능이 좋지만 update, delete, insert할 때에 관련 인덱스도 업데이트해야해서 그 때에 성능이 희생된다. 너무 많이 만들면 안된다는것이다. 인덱스 분류 PK : 레코드 대표값(PK) 이게 식별자이고, 동시에 not null이며 중복할수 없다. 세컨더리 인덱..

데이터 암호화 MySQL5.7부터 암호화 기능 지원 이거는 데이터 파일(테이블스페이스)에 대해서만 지원됨 MySQL8.0부터는 더 지원된다. 리두로그, 언두로그 복제를 위한 바이너리 로그 등 이게 핀케트처럼 중요한 정보를 저장하는곳에서는 응용프로그램에서 암호화 한걸 다시 DB서버에서 암호화하는 이중 암호화를 하기도 한다 함 어플리케이션에는 중요정보 컬럼 단위 DB에서는 테이블 단위로 한다 한다. MySQL 데이터 암호화 DB서버랑 디스크 사이의 데이터 읽고쓰는 지점에서 암호화 / 복호화 수행됨 디스크 입출력 이외에서는 암호화 처리가 필요X 즉 InnoDB스토리지 엔진의 I/O 레이어에서만 데이터의 암호화 및 복호화 과정이 실행된다. 2단계 키 관리 TDE(Trasparent Data Encryption)..

# 데이터 압축 - 디스크에 저장된 데이터 파일 크기는 일반적으로 쿼리 성능, 백업, 복구 시간과 밀접하게 연결된다. - 쿼리 처리할 때에 데이터 페이지를 InnoDB 버퍼 풀로 읽어서 - 새로운 페이지가 버퍼 풀로 적재되니까 더티 페이지가 더 자주 디스크로 기록되어서 - 데이터 파일이 크면 백업/복구에 오래 걸린다 이를 해결하기 위해 도입된게 데이터 압축 ## 페이지 압축 - Transparent Page Compression이라고도 한다. - MySQL서버가 디스크에 저장하는 시점에 데이터 페이지가 압축되어 저장되고, 읽어올 때에는 압축이 해제되니까 - 즉 버퍼 풀에 데이터 페이지가 한 번 적재되면 InnoDB 스토리지 엔진은 압축이 해제된 상태로만 데이터 페이지를 관리함 - 압축 여부와 관계없이 투..

트랜잭션과 락 트랜잭션 작업의 완전성을 보장 데이터의 정합성 보장 잠금 동시성 제어 기능 트랜잭션 여러 논리작업이 한꺼번에(다같이 되거나 다같이 안되거나) 진행되도록 하는것이다. 그리고 트랜잭션은 무조건 모든곳에 넣는것은 좋지 않은데 예를 들어 유저가 글을 쓰는 로직을 볼 때 유저 정보 가져옴 글쓰기 오류 판별 업로드 파일 확인 및 저장 사용자 입력 정보 DBMS 저장 저장 내용을 DBMS에서 조회 게시물 등록 알림을 메일로 전송 알림 메일 발송 이력을 DBMS 저장 이렇게 보면 3 ~ 4가 실제 DB에 글을 저장하는 로직 7이 DB에 글을 저장하는 로직이다. 그리고 다른 부분은 이를 활용하는 것이거나 '6'번처럼 네트워크를 써서 문제가 생기는 경우가 있을 것이다. 처음부터 트랜잭션을 만들..

아키텍쳐 MySQL엔진 MySQL엔진은 SQL 문장 분석이나 최적화같은 두뇌역할을 수행 얘는 MySQL서버 하나에 한개밖에 없다. 커넥션 핸들러, SQL파서 및 전처리기 옵티마이저 쿼리의 최적화된 실행을 위해 스토리지 엔진 데이터 저장 / 불러오는 역할 수행 이거는 여러개 동시사용 가능하다. 스레딩 구조 MySQL서버는 프로세스가 아니라 스레딩 기반으로 동작 포그라운드 스레드 최소 mysql에 접근한 클라이언트의 수만큼 존재 그래서 사용하면 여기있고 다쓰면 스레드캐시로 돌아감 근데 스레드캐시가 일정 갯수 이상이면 그냥 종료시킨다. 데이터를 데이터버퍼나 캐시로부터 가져온다. 없는 경우에는 직접 디스크나 인덱스 파일에서부터 데이터를 가져옴 (InnoDB기준) 데이터 버퍼나 캐시에 저장 이후는 백그라운드에서 ..

레디스를 로컬이 아닌 외부에 두는 이유 보통 우리가 공부할 때에는 레디스를 로컬에서 실행한다. 근데 회사를 가면 열에 아홉은 외부 레디스를 쓸 것이다. 로컬에서 실행할때 얻을 수 있는 장점은 빠른 속도 외부 레디스의 경우 통신 과정이 필요하므로 레이턴시가 걸리게 된다. 개발 및 테스트 개발 환경에서의 접근과 설정, 테스트가 용이하다. 정도일 것이다. 단점은 무엇일까?? 어쩌면 뻔하다고 생각될 수 있지만 다음과 같다. 데이터 손상 로컬에 레디스가 존재하는 경우 데이터가 손실될 염려가 더 크다. ex) 서버가 중단되는 경우 데이터의 손상 또 외부에 두게 되면 Redis자체적으로 제공되는 스냅샷을 백업하거나 디스크 로그에 저장하는 등등을 통해 데이터를 조금 더 편하게 저장 가능하다. 확장성 결국 로컬 컴퓨터에..

보통 개발할 때에 반드시 공부하고 적용하는게 페이징일 것 같다. 그리고 아마... 처음에는 offset limit을 써서 적용을 할 것 같다. 이 offset limit에 대해, 그리고 offset limit의 문제점에 대해, 해결 방안에 대해 써보려고 한다. 일단은 간단한 테스트를 위해 CREATE TABLE board ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, heart INT DEFAULT 0 );이런 테이..

select for update가 뭘까?? 이름에서 알 수 있듯, 업데이트를 하기 위해 검색을 하는 것이다. 즉, 이후의 Update를 위해 select를 진행하는 것이라 할 수 있다. 그래서 뭐요? 사실 그냥 보면 뭐 그런갑다.. 할 수 있다. 근데 사실 저 select for update에서 중요한 것은, Select된 행의 UPDATE가 실제로 커밋되기 전까지 다른 트랜잭션이 이 행을 수정할 수 없다는 것이다. 뭔소리에요?? 그러니까 여러 트랜잭션이 하나의 레코드에 접근한다고 가정할 때, 현재 select for update 수행중인 내용은 변경 불가하다는 것이다!! 아래에서 실제로 보여주겠다. 실습 Table 먼저 human 테이블에 다음과 같은 데이터가 있다. 3개의 트랜잭션을 수행해 볼 것이다..