database

pull model조회 시점의 부하를 쓰기 시점의 부하로 치환 (쓰기 성능↑ , 조회 성능↓)시간 복잡도↑ , 공간 복잡도↓ex) 1번 유저(from)가 팔로워들(to)의 게시물(post)을 타임라인에 띄우려면 Post Table에 to.id(post.memberId)

Atomicity(원자성)트랜잭션과 관련된 작업들이 부분적으로 실행되다 중단되지 않음을 보장해야한다. 하나의 기능은 무조건 ALL(전체 성공) or NOTHING(전체 실패)Consistency(일관성)트랜잭션 실행이 성공하고 완료가 되었을 때는 항상 일관성있는 데이터

커버링 인덱스란?테이블에 접근하지 않고 인덱스 데이터만 반환(응답)!mysql에서는 PK가 clustered Index이기 때문에 이 조건에 매우 유리!모든 인덱스 테이블에 id(pk)가 존재하기에 커버링 인덱스에 매우 유리!인덱스가 있을 경우 순서예시일반적인 경우순서

데이터의 값을 변형 시키는 구문에는 인덱스가 적용되지 않는다! (인덱스 필드에 값과 달라졌을때...)ex)하나의 쿼리는 하나의 인덱스만 탄다.여러 인덱스 테이블을 동시에 탐색하지 않는다.※index merge hint를 사용하면 가능!WHERE, ORDER BY, GR

동시성 이슈가 발생할 것이라 생각을 해서 미리 줄을 세우게 만드는 방법단점락을 통한 동시성 제어는 불필요한 대기 상태를 만듬MySQL에서 인덱스를 잠구기 때문에 where문 조건에 따라 불필요한 데이터까지 잠길 수 있다.동시성이 빈번하지 않은 쿼리로 잠금을 잠가버려 다

explain을 사용하면 옵티마이저의 실행계획과 얼마나 많은 데이터를 접근하고 필터했는지 확인할 수 있다.인덱스 없이 실행실행 결과실행 시간 -> 3초이상중요한 항목 : type , rows, filtertype(데이터 스캔 항목) : ALL인덱스 생성※Grouping

gap lock nextkey lock PESSIMISTIC_READ insert into feedlikecount (id, likecount, feedid) value (1, 0, 1); insert into feedlikecount (id, likecount,