9) Error Handling , 10) Left Join 주의사항 및 튜닝

MySQL 에러 구분

• Gobal Error
  • Server-side & Client-side 에서 공용으로 발생
• Server Error
  • Server-side에서 만 발생
• Client Error
  • client-side에서만 발생

에러범위(숫자)에 따라 이게 client 인지 server인지 구별이 가능하다

Server erorr중에는 client side까지 전달이 되는 에러들도 존재한다.

 

SQL State

• 5글자 영문 숫자로 구성된다.
• ANSI-SQL에서 제정한 vendor 비 의존적 에러코드이다.
• SQL-State는 2 파트로 구분된다. 
  • 앞 두글자는 상태 값의 분류를 의미한다.
    • 00 = 정상
    • 01 = 경고
    • 02 = 레코드 없음
    • HY = ANSI-SQL에서 아직 표준 분류를 하지 않은 상태 (벤더 의존적 상태 값)
    • 나머지는 모두 에러이다.
  • 뒷 세글자 = 주로 숫자 값이며 (가끔 영문) , 각 분류별 상세 에러 코드 값이다.

ERROR 1062 (23000) : Duplicate entry "abc..." for key "ux_email"   ,  23은 에러를 의미하는 것을 알 수 있다.

 

• Error Handlling을 할때 Error Message을 기준으로 app을 작성하면 안된다. 매번 말 없이 달라질 수 있다.
• Error No 또한 문제가 될 수 있다. (내부적으로 사용되는 스토리지 엔진에따라 달라진다.)
• SQL State또한 문제가된다. 동일 에러에 대해서 다양한 에러 번호와 다양한 에러 메시지가 존재한다.
• 앵간하면 SQL State 값으로 Error Handling을 하는것이 좋다.

HY인 경우에는 버전 업그레이드시 새로운 카테고리의 SQL State로 변경이 가능함으로 Error No로 처리하는것이 좋다

---

 

전체유저 목록은 나오되 ,  3번 쿠폰을 가진 유저들만 유저 쿠폰 테이블에 추가 정보가 표시된다.

없는 유저 row들은 null로 나오게 될 것이다.

 

 left join을 잘못 쓰면 inner join처럼 결과가 반영이 될 수 있다.

on 절에서 where 절로 이동시켰더니 1000 row만 나오게 되었다.

on 절에 조건이 주어졌을 때는 User Table의 데이터에 대해서 User Coupon table 의 데이터를 연결하는 역할을 수행했던 반면에 where절에 주어졌을 때는 실제 결과로 반환되는 데이터를 필터링하는 역할을 수행했기 때문이다.

 

 

1) left join에서는 driving table (uer)가 항상 먼저 읽히게 된다. 

user전체를 읽고 user coupon에서 on 조건에 따라 join을 수행하게 된다.

 

2) mysql 같은 경우 위 예시처럼 where로 조건을 옮긴경우 optimizer 가 inner join으로 변경시킨후 수행한다.

user coupon을 먼저 읽어서 id=3를 추리는 방식으로 동작한다,  user 전체를 굳이 먼저 읽을 필요가 없게 된다.

 

1번째는 어차피 user row전체를 다 return함으로 count 할 거면 굳이 불필요한 leftjoin을 할필요가 없겠다 (아니면 잘못쓴거겠지)

2번재는 left join시 null 인 user만 (coupon이 없는) 반환하고 싶은 것이니 left join이 반드시 필요한 경우이다.

 

정리

• left join을 사용하고자 한다면 driven table (inner table) 컬럼의 조건(조인 조건)은 반드시 on절에 명시해서 사용해야 한다. 
  (IS NULL 조건은 예외다. 위 2번째 예시)
• left join 과 inner join은 결과 데이터 및 쿼리 처리 방식 등이 매우 다르므로 , 필요에 맞게 올바르게 사용하는것이 중요하다.
• left join 쿼리에서 count를 사용하는 경우 left join이 굳이 필요하지 않다면 join은 제거한다.