그누보드의 경우 몇개의 큰 테이블의 성능 때문에 고통을 받고 있는데
이런 부분이 테이블 파티셔닝을 통해서 간단하게 해결 가능하구요
테이블 파티셔닝은 MySQL 5.7 이상의 버젼에서 사용할 것을 추천 드립니다.
- 년도를 기준으로 파티셔닝 (point 갯수가 많은 경우는 월별/일별로 파티셔닝)
- 개인정보 보호를 위한 정보의 최대 보유기간인 5년을 경과하는 것은 table drop
1. g4_visit 테이블의 record 갯수와 가장 오래된 vi_date를 확인
있는 날짜부터 파티셔닝을 하면 되니까...
2. table structure를 확인
primary key를 확인. 그누보드 기본은 vi_id 입니다.
3. vi_date를 primary key에 추가
파티셔닝의 기준이 되는 날짜가 primary key에 들어 있어야 합니다.
ALTER TABLE `g4_visit` DROP PRIMARY KEY ,
ADD PRIMARY KEY ( `vi_id` , `vi_date` )
4. SQL script를 작성
ALTER TABLE g4_visit
PARTITION BY RANGE ( TO_DAYS(vi_date) ) (
PARTITION vi2007 VALUES LESS THAN (TO_DAYS('2008-01-01')),
PARTITION vi2008 VALUES LESS THAN (TO_DAYS('2009-01-01')),
PARTITION vi2009 VALUES LESS THAN (TO_DAYS('2010-01-01')),
PARTITION vi2010 VALUES LESS THAN (TO_DAYS('2011-01-01')),
PARTITION vi2011 VALUES LESS THAN (TO_DAYS('2012-01-01')),
PARTITION vi2012 VALUES LESS THAN (TO_DAYS('2013-01-01')),
PARTITION vi2013 VALUES LESS THAN (TO_DAYS('2014-01-01')),
PARTITION vi2014 VALUES LESS THAN (TO_DAYS('2015-01-01')),
PARTITION vi2015 VALUES LESS THAN (TO_DAYS('2016-01-01')),
PARTITION vi2016 VALUES LESS THAN (TO_DAYS('2017-01-01')),
PARTITION vi2017 VALUES LESS THAN (TO_DAYS('2018-01-01')),
PARTITION vi2018 VALUES LESS THAN (TO_DAYS('2019-01-01')),
PARTITION vi2019 VALUES LESS THAN (TO_DAYS('2020-01-01')),
PARTITION vi2020 VALUES LESS THAN (TO_DAYS('2021-01-01')),
PARTITION vi2021 VALUES LESS THAN (TO_DAYS('2022-01-01')),
PARTITION vi2022 VALUES LESS THAN (TO_DAYS('2023-01-01')),
PARTITION vi2023 VALUES LESS THAN (TO_DAYS('2024-01-01')),
PARTITION vi2024 VALUES LESS THAN (TO_DAYS('2025-01-01')),
PARTITION vi2025 VALUES LESS THAN (TO_DAYS('2026-01-01')),
PARTITION vi2026 VALUES LESS THAN (TO_DAYS('2027-01-01')),
PARTITION vi2027 VALUES LESS THAN (TO_DAYS('2028-01-01')),
PARTITION vi2028 VALUES LESS THAN (TO_DAYS('2029-01-01')),
PARTITION vi2029 VALUES LESS THAN (TO_DAYS('2030-01-01')),
PARTITION vi2030 VALUES LESS THAN (TO_DAYS('2031-01-01')),
PARTITION vimax VALUES LESS THAN MAXVALUE
);
*** 주의사항 ***
g4_visit의 경우는 primary key의 생성을 할 때
DB의 접속을 멈추지 않으면
중복 key가 발생해서 primary key의 생성이 안됩니다.
g4_point 테이블과 달리
반드시 DB를 멈춘상태에서 작업을 해야 합니다.
튜닝의 효과는 서프라이즈이며
g4_point, g4_board_new 등의 테이블도 튜닝하면 좋습니다.