우리가 매일 반복하는 선택들이 신중하게 생각하고 내린 결정의 결과물로 여겨지겠지만, 실제로는 그렇지 않다. 대부분의 선택이 습관이다. - P10


댓글(0) 먼댓글(0) 좋아요(2)
좋아요
북마크하기찜하기 thankstoThanksTo
 
 
 
개발자와 DBA를 위한 Real MySQL 위키북스 오픈소스 & 웹 시리즈 38
이성욱 지음 / 위키북스 / 2012년 5월
평점 :
절판



댓글(0) 먼댓글(0) 좋아요(1)
좋아요
북마크하기찜하기 thankstoThanksTo
 
 
 
개발자와 DBA를 위한 Real MySQL 위키북스 오픈소스 & 웹 시리즈 38
이성욱 지음 / 위키북스 / 2012년 5월
평점 :
절판


COUNT(*) 쿼리에서 가장 많이 하는 실수는 ORDER BY 구문이나 LEFT JOIN과 같은 레코드 건수를가져오는 것과는 전혀 무관한 작업을 포함하는 것이다. 대부분 COUNT(*) 쿼리는 페이징 처리를 위 - P416

해 사용할 때가 많은데, 많은 개발자가 SELECT 쿼리를 그대로 복사해서 칼럼이 명시된 부분만 삭제하고 그 부분을 COUNT(*) 함수로 대체해서 사용하곤 한다. 그래서 단순히 COUNT(*)만 실행하는 쿼리임에도 ORDER BY가 포함돼 있다거나 별도의 체크 조건을 가지지도 않는 LEFT JOIN이 사용된 채로실행될 때가 많다. COUNT(*) 쿼리에서 ORDER BY 절은 어떤 경우에도 필요치 않다. 그리고 LEFT TOIN 또한 레코드 건수의 변화가 없거나 아우터 테이블에서 별도의 체크를 하지 않아도 되는 경우에는 모두 제거하는 것이 성능상 좋다.
많은 사용자들이 일반적으로 칼럼의 값을 SELECT하는 쿼리보다 COUNT(*) 쿼리가 훨씬 빠르게 실행될 것으로 생각할 때가 많다. 하지만 인덱스를 제대로 사용하도록 튜닝하지 못한 COUNT(*) 쿼리는페이징해서 데이터를 가져오는 쿼리보다 몇 배 또는 몇십 배 더 느리게 실행될 수도 있다. COUNT(*)리도 많은 부하를 일으키기 때문에 주의 깊게 작성해야 한다.
COUNT() 함수에서 한 가지 주의해야 할 점이 있다. 칼럼명이나 표현식이 인자로 사용되면 그 칼럼이나 표현식의 결과가 NULL이 아닌 레코드 건수만 반환한다. 예를 들어 "COUNT(columni)"이라고SELECT 쿼리에 사용하면 columnl이 NULL이 아닌 레코드의 건수를 가져온다. 그래서 NULL이 될수 있는 칼럼을 COUNT() 함수에 사용할 때는 의도대로 쿼리가 작동하는지 확인하는 것이 좋다.


댓글(0) 먼댓글(0) 좋아요(3)
좋아요
북마크하기찜하기 thankstoThanksTo
 
 
 
개발자와 DBA를 위한 Real MySQL 위키북스 오픈소스 & 웹 시리즈 38
이성욱 지음 / 위키북스 / 2012년 5월
평점 :
절판


OUTER JOIN에서 레코드가 없을 수도 있는 쪽의 테이블에 대한 조건은 반드시 LEFT JOIN의 ON 절에 모두 명시하자. - P362


댓글(0) 먼댓글(0) 좋아요(0)
좋아요
북마크하기찜하기 thankstoThanksTo
 
 
 
개발자와 DBA를 위한 Real MySQL 위키북스 오픈소스 & 웹 시리즈 38
이성욱 지음 / 위키북스 / 2012년 5월
평점 :
절판


조인의 처리에서 어느 테이블을 먼저 읽을지를 결정하는 것은 상당히 중요하며, 그에 따라 처리할 작업량이 상당히 달라진다. INNER JOIN은 어느 테이블을 먼저 읽어도 결과가 달라지지 않으므로 MySQL 옵티마이저가 조인의 순서를 조절해서 다양한 방법으로 최적화를 수행할 수 있다. 하지만 OUTE /JOIN은 반드시 OUTER가 되는 테이블을 먼저 읽어야 하기 때문에 조인 순서를 옵티마이저가 선택할 수 없다. - P358


댓글(0) 먼댓글(0) 좋아요(1)
좋아요
북마크하기찜하기 thankstoThanksTo