High_Priority
- 높은 우선순위로 결과를 받아오도록 질의함
- mysql> SELECT HIGH_PRIORITY * FROM USER
Query_Cache
- 쿼리결과를 캐슁
- 해당 테이블이 변경(Insert,Update)가 처리되면 모든 캐쉬 Flush
Low_Priority
- INSERT 시 옵션을 주면 큐의 모든 Select가 완료될때까지 기다림
- 슬레이브(백업)서버의 경우 서버옵션으로 지정해놓으면 동기화는 느려도 Select는 빨라짐
대용량 INSERT
- MultiRow를 사용하면 성능이 높아짐
- MyISAM의 경우 8배, InnoDB에서는 30배 성능 향상
- 대용량 처리시 disable_key를 사용해서 인덱스 생성을 멈추고 완료후 활성화
DELETE 성능향상
- DELETE QUICK : MyISAM에서만 사용가능. 내부적인 인덱스 정리작업 처리안함
- 모든 데이터를 삭제할 경우에는 Drop Table 처리
- MyISAM 경우 Truncate Table를 사용가능(내부적으로 Drop Table처리)
Count(*)은 위험하다
- Count를 위해서 별도의 테이블을 만드는 것이 좋은 해결책
Count(*) 쿼리가 필요할까?
- Google같이 대략적인 COUNT로 해결
- Limit를 사용하여 1000개 이하는 정확한 수를 1000개 이상은 1000+라고 표시
Count(*)의 속도 높히기
- MyISAM는 전체 테이블 카운터를 가지므로 빠른 결과
- InnoDB는 풀스캔처리
- Count결과에 영향을 주지 않는 Join을 제거
- 인덱스를 사용하도록 처리(UsingIndex)가 explain의 extra의 결과에 나오도록 처리
높은 Limit값 다루기
- SELECT * FROM users ORDER BY last_online DESC limit 100000,10
- 처음10만row 검색후 버리게 되므로 비용이 높다
- DDos공격대상
- 검색엔진 봇은 높은 Page를 자추 찾아들어감
- 빠르게 동작하는걸 보장하지 못할경우 제한하는 방법 : Google 등
높은 Limit : 가능한 결과를 미리 생성
- SELECT * FROM sites ORDER BY visits DESC LIMIT 100,10
- 아래와 같이 레이팅을 처리하는 테이블을 추가하는 방법
- SELECT * FROM sites_rating WHERE position BETWEEN 101 and 110 ORDER BY position
- 실시간이 필요 없는 경우 통계테이블을 추가하면 성능 향상이 있음
배치작업에서의 LIMIT의 사용
- 배치작업에서는 Limit n,10000 보다 Where id Between n and n+99999 형태로 변경
- 정확한 개수는 필요 없을 경우
파생테이블(Derived Table)사용하기
- 파생테이블이란 : WHERE id IN (SELECT ID FROM tb)
- 부분적으로 인덱스를 사용할 수 있도록 함
- 파생테이블 두개를 조인하게 되면 MySQL에서는 풀조인을 하므로 주의
FROM절의 서브쿼리
- SELECT ... FROM (SELECT ...) WHERE ...
- 서브쿼리를 완전 별개로 처리함. 즉 Temp Table로 사용. Temp Table은 인덱스 사용암함
- Join으로 분할 해야함
Sorting시 File Sort 피하기
- SELECT * FROM TBL WHERE A IN (1,2) ORDER BY B LIMIT 5
- MySQL에서는 정렬시 인덱스 사용못함(모든 컬럼에서 = 비교를 하는 경우를제외)
- 정렬작업을 위해서 File Sort함
- 데이터 양이 많을 경우 시간이 오래 걸림
- UNION으로 쪼개면 인덱스만 사용하게 됨
- (
SELECT * FROM TBL WHERE A=1 ORDER BY B LIMIT 5
UNION
SELECT * FROM TBL WHERE A=2 ORDER BY B LIMIT 5
) ORDER BY B LIMIT 5
댓글 없음:
댓글 쓰기