10. DB 깔짝

1. CRUD 쿼리

• Create (Insert)
  • SQL : INSERT INTO
  • JPA 레파지토리 : .save(entity)
• Read (Select)
  • SQL: SELECT * WHERE
  • JPA 레파지토리: .findByXXX(...)
• Update
  • SQL: UPDATE ... SET ...
  • JPA 레파지토리: .save(entity) < id 있으면
• Delete
  • SQL : DELETE FROM ...
  • JPA 레파지토리: .deleteByXXX(...)

2. PK (Primary Key)

• 행의 주민등록번호 라고 생각하셈.
• 즉, 모든 행을 고유하게 식별하는 값.
• 절대 중복 X
• 절대 Null 안됨
• 테이블당 1개
• @GeneratedValue 쓰면 자동 증가함
• 또는 유저 id 값으로 Pk 지정할수도

3. UNIQUE

• 이 조합은 중복 안돼~~

4. FK (Foreign Key) - 다른 테이블 참조

• 이 값은 다른 테이블의 Pk를 가리키삼!
• 참조하는 테이블에 해당 값이 있어야함
• 다만, 마이크로서비스에서는 FK를 DB 레벨에서 강제하지 않고, 코드에서 관리하는 경우가 많음

5. 인덱스

• 책의 목차라고 생각하기
• 언제 인덱스를 걸어?
  • WHERE 절에 자주 쓰이는 컬럼에 걸어

SELECT * FROM something
WHERE id = 100 < - id 에 인덱스
	AND date = '2026-01-18' <- date 에 인덱스

• UNIQUE 제약 자체가 인덱스 역할도 한다.

  • why?
  • DB 입장에서 생각해보면 유니크 제약 건다는것 자체가 인덱스 만드는게 선행되어야함. (중복체크를 빠르게 하려면, 인덱스가 필수니까)

• 인덱스의 트레이드오프

  • 장점: SELECT 가 빨라짐
  • 단점: INSERT/UPDATE가 살짝 느려짐 (인덱스도 업데이트해야하니까)

만약에 디비에 100만 행이 있다고 상상해보자.

• SELECT * FROM something WHERE user_id = 100;
  ^ 요거 실행하려면, 처음부터 끝까지 다 뒤져봐야함.
• 인덱스 걸려있으면 목차가 미리 만들어져있다고 생각하면됨. ex. userId랑 실제 행 위치가 매핑되어있는것.
• 따라서, 인덱스를 건다는건 이 목차를 매핑해달라고 DB에 요청하는것.
  • CREATE INDEX user_id ON something (user_id);
• 복합 인덱스도 가능함

6. 트랜잭션

• 전부 성공 or 전부취소
• @Transactional 어노테이션이면 끝남...

7. 동시성 / 락

• 같은 유저가 동시에 2번 요청한다면?
• 해결: Lock