MySQL 5.5 파티션 기능 개선사항 자세히 알아보기
개요
MySQL 5.5 릴리즈는 몇 가지 기능향상이 되었습니다. 당연히, 대부분의 내용은 semi-synchronous replication가 주목되는 동안 파티션의 향상된 기능은 도외시되고, 때로는 이 기능의 진정한 의미에 대한 약간의 오해도 발생했습니다. 이 문서를 통해서, 멋진 기능과 특히 잘 이해가 되지 않는 부분을 설명하려 합니다.
직관적인 부분: 비정수(non-integer) 컬럼의 파티션
지금까지 정수형이 아닌 컬럼을 사용하여 파티션을 사용해본 경험이 있다면(MySQL 5.1 파티션 연습 참조) 많은 문제로 일종의 좌절을 경험했을 것입니다.
새로운 추가사항은 범위(RANGE)와 리스트 파티션과 함꼐 작동합니다. 새로운 기능을 소개하는 새로운 컬럼 키워드가 있습니다.
다음과 같은 테이블이 있다고 가정합니다.
CREATE TABLE expenses (
expense_date DATE NOT NULL,
category VARCHAR(30),
amount DECIMAL (10,3)
);
만약에 MySQL 5.1에서 category 컬럼으로 파티션을 원한다면, category 컬럼을 정수형으로 변환하고 category에 대한 내용을 찾아볼 수 있는 테이블을 추가해야만 합니다. MySQL 5.5에서는 간단하게 처리할 수 있습니다.
ALTER TABLE expenses
PARTITION BY LIST COLUMNS (category)
(
PARTITION p01 VALUES IN ( 'lodging', 'food'),
PARTITION p02 VALUES IN ( 'flights', 'ground transportation'),
PARTITION p03 VALUES IN ( 'leisure', 'customer entertainment'),
PARTITION p04 VALUES IN ( 'communications'),
PARTITION p05 VALUES IN ( 'fees')
);
이 구문은 명확하게 읽을 수 있고 효율적인 결집으로 데이터를 정리하는것 뿐만아니라 오직 열거된 category만 사용이 가능하여, 다른측면에서의 혜택이 있습니다.
MySQL 5.1에서의 또 다른 문제점은 날자열의 처리입니다. 아래와 같은 상황에서 YEAR 또는 TO_DAYS 중 하나를 사용하는 컬럼에 대해서 직접 사용할 수 없지만, 변환이 필요합니다.
/* with MySQL 5.1*/
CREATE TABLE t2
(
dt DATE
)
PARTITION BY RANGE (TO_DAYS(dt))
(
PARTITION p01 VALUES LESS THAN (TO_DAYS('2007-01-01')),
PARTITION p02 VALUES LESS THAN (TO_DAYS('2008-01-01')),
PARTITION p03 VALUES LESS THAN (TO_DAYS('2009-01-01')),
PARTITION p04 VALUES LESS THAN (MAXVALUE));
SHOW CREATE TABLE t2 \G
*************************** 1. row ***************************
Table: t2
Create Table: CREATE TABLE `t2` (
`dt` date DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
/*!50100 PARTITION BY RANGE (TO_DAYS(dt))
(PARTITION p01 VALUES LESS THAN (733042) ENGINE = MyISAM,
PARTITION p02 VALUES LESS THAN (733407) ENGINE = MyISAM,
PARTITION p03 VALUES LESS THAN (733773) ENGINE = MyISAM,
PARTITION p04 VALUES LESS THAN MAXVALUE ENGINE = MyISAM) */
이 얼마나 무섭고 진정한 고통을 주는 코드입니까? 물론, 해결 방법은 있지만, 많은 문제가 발생했습니다. YEAR 또는 TO_DAYS를 사용하여 파티션을 정의하는 것과, 함수로 파니셔닝된 부분에 질의 문으로 노출된 컬럼을 기준으로 질의를 하는 것은 정말 말도 안 되는 퍼즐을 마추는 것 같습니다.
이젠 상황이 달라졌습니다. 날짜별로 분할하는 것이 쉬고 직관적으로 되었습니다.
/*With MySQL 5.5*/
CREATE TABLE t2
(
dt DATE
)
PARTITION BY RANGE COLUMNS (dt)
(
PARTITION p01 VALUES LESS THAN ('2007-01-01'),
PARTITION p02 VALUES LESS THAN ('2008-01-01'),
PARTITION p03 VALUES LESS THAN ('2009-01-01'),
PARTITION p04 VALUES LESS THAN (MAXVALUE));
SHOW CREATE TABLE t2 \G
*************************** 1. row ***************************
Table: t2
Create Table: CREATE TABLE `t2` (
`dt` date DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
/*!50500 PARTITION BY RANGE COLUMNS(dt)
(PARTITION p01 VALUES LESS THAN ('2007-01-01') ENGINE = MyISAM,
PARTITION p02 VALUES LESS THAN ('2008-01-01') ENGINE = MyISAM,
PARTITION p03 VALUES LESS THAN ('2009-01-01') ENGINE = MyISAM,
PARTITION p04 VALUES LESS THAN (MAXVALUE) ENGINE = MyISAM) */
이전 경우와 같은 파티션 정리는 버릴 수 있습니다. 정의된 컬럼을 기준으로 하기 때문에, 컬럼을 기준으로 함수와 쿼리의 의한 정의 사이에서 혼란이 없습니다. DBA의 업무를 수월하게 하기 위해서, 정의되어진 값을 그대로 유지합니다.
모두가 행복해졌죠? 아마, 대부분 그럴것 입니다. 이제 컬럼 특성에 대한 조금 더 모호한 특성에 대하여 살펴보겠습니다.
직관에 반대되는 부분: 다중 컬럼(multiple columns)
컬럼 키워드는 문자열이나 date 컬럼의 파티션 정의자를 허락하는 것보다 더 좋습니다. 그것은 또한 파티션을 정의하는 다중 컬럼으로 사용이 가능합니다.
공식적인 문서에서 아래의 예문과 비슷한 몇 가지 예제를 본적이 있을 것입니다.
CREATE TABLE p1 (
a INT,
b INT,
c INT
)
PARTITION BY RANGE COLUMNS (a,b)
(
PARTITION p01 VALUES LESS THAN (10,20),
PARTITION p02 VALUES LESS THAN (20,30),
PARTITION p03 VALUES LESS THAN (30,40),
PARTITION p04 VALUES LESS THAN (40,MAXVALUE),
PARTITION p05 VALUES LESS THAN (MAXVALUE,MAXVALUE)
);
CREATE TABLE p2 (
a INT,
b INT,
c INT
)
PARTITION BY RANGE COLUMNS (a,b)
(
PARTITION p01 VALUES LESS THAN (10,10),
PARTITION p02 VALUES LESS THAN (10,20),
PARTITION p03 VALUES LESS THAN (10,30),
PARTITION p04 VALUES LESS THAN (10,MAXVALUE),
PARTITION p05 VALUES LESS THAN (MAXVALUE,MAXVALUE)
)
PARTITION BY RANGE COLUMNS (a,b,c) 을 기준으로 하는 예제도 있습니다. 만약에 이러한 예문으로 부터 대단한 아이디어를 얻은 독자라면, 부담 없이 나를 재미있게 만들어 주세요. 왜냐하면 나는 그렇게 하지 못했기 때문입니다.
오랜 세월 동안 MySQL 5.1 파티션을 사용하는데 있어서, 다중 컬럼에 의한 파티션의 중요성을 파학하지 못했습니다. LESS THAN (10,10) 구문의 의미는 무엇입니까? 그리고 다음 파티션으로 LESS THAN (10,20)이 설정된다면 어떤 일이 발생합니까? (20,30)과 같이 완전히 다른 쌍을 적용한다면 어떻게 되겠습니까? 이러한 모든 질문에 답변이 필요하고, 답변하기 전에 우리가 함께 다루고 있는 이것에 대해서 더 많은 이해가 필요합니다.
처음에는 MySQL 엔지니어 가운데도 약간의 혼동이 있었습니다. 그리고 그것 뿐만 아니라 나는 어리석었습니다! 모든 파티션의 첫 번째 범위 값은 마치 단 하나의 컬럼으로 분할되어진 것과 같이 실질적인 값은 전부 다르다고 믿고 있었습니다. 그러나 이 경우만이 아니었습니다. 다음 예제를 보겠습니다.
CREATE TABLE p1_single (
a INT,
b INT,
c INT
)
PARTITION BY RANGE COLUMNS (a)
(
PARTITION p01 VALUES LESS THAN (10),
PARTITION p02 VALUES LESS THAN (20),
PARTITION p03 VALUES LESS THAN (30),
PARTITION p04 VALUES LESS THAN (40),
PARTITION p05 VALUES LESS THAN (MAXVALUE)
);
이것은 p1 테이블에 해당되지 않습니다. 만약에 p1dp (10, 1, 1)을 삽입한다면, 그것은 첫 번째 파티션에 포함될 것입니다. p1_single에 대입하면 2번째 파티션에 포함될 것입니다.
(10,1)은 (10, 10)보다 작기 때문입니다. 만약 오직 첫 번째 값을 초점을 둔 경우라면, 튜플이 아닌 단일 값을 비교하였을 것입니다.
이제부터 어려운 부분입니다. 데이터(row)가 어디로 배치될지 결정이 필요할 때 무슨 일이 발생합니까? (10,9) < (10,10)와 같은 작없을 어떻게 비교 합니까? 답변은 간단합니다: 두개의 레코드를 정렬하여 비교하는 방법이 사용됩니다.
a=10
b=9
(a,b) < (10,10) ?
# 다음과 같이 평가 합니다.:
(a < 10)
OR
((a = 10) AND ( b < 10))
# 다음과 같이 변환을 합니다.:
(10 < 10)
OR
((10 = 10) AND ( 9 < 10))
만약에 3개의 컬럼과 복잡한 표현이 있다고 하여도, 더 이상 복잡하지 않습니다. 우선 첫 번째 항목에 대해서 적은 비용(낮은 리소스의 사용을 의미함)으로 테스트합니다. 만약 두개 이상의 파티션에서 일치하는 경우라면, 두 번째 항목을 테스트 합니다. 그렇게 한 다음에도 하나 이상의 후보 파티션을 가지고 있다면, 다음 세 번째 항목을 테스트합니다.
아래의 그림은 세 개의 평가 기록이 파티션의 정의를 통해서 테이블에 삽입되는 과정을 보여줍니다.
(10,10),
(10,20),
(10,30),
(10, MAXVALUE)
그림 1. 첫 번째 (비교)값이 파티션 정의의 첫 번째 범주보다 작은 경우에 모든 것이 쉽습니다. 데이터(row)는 여기에 포함됩니다.
 |
그림 2. 튜플 비교. 첫 번째 (비교)값이 파티션 정의의 첫 번째 범주와 같을 때, 두 번째 항목을 비교해야 합니다. 남은 하나가 두 번째 범위보다 작다면, 데이터(row)는 여기에 포함됩니다.
 |
그림 3. 튜플 비교. 첫 번째 (비교)값과 두번쨰 (비교)값 둘 다 (첫번째) 해당 범주 값과 동일합니다. 튜플은 정의된 범위보다 작지 않으므로, 여기에 포함되지 않습니다. 다음단계로 넘어갑니다.
 |
그림 4. 튜플 비교. 다음 범위를 보면, 첫 번째 (비교)값은 같고, 두 번째 (비교) 값은 작습니다. 따라서 튤플은 작고 데이터(row)는 여기에 포함됩니다.
 |
이와 같은 수치의 도움으로, 우리는 다중 컬럼으로 파니션된 테이블에 레코드를 삽입하는 절체에 대해서 더 많은 이해를 할 수 있게 되었습니다. 이것이 이론이 되었습니다. 내가 했던 것보다 훨씬 더 쉽게 새로운 기능을 파악하는 것을 돕기 위해서, 감각적으로 이해 할려고 하는 독자들에게 다른 예제를 제공하자고 합니다. 런치패드에 있는 MySQL test 데이터베이스의 employees 테이블의 몇 가지를 수정하여 사용합니다.
CREATE TABLE employees (
emp_no int(11) NOT NULL,
birth_date date NOT NULL,
first_name varchar(14) NOT NULL,
last_name varchar(16) NOT NULL,
gender char(1) DEFAULT NULL,
hire_date date NOT NULL
) ENGINE=MyISAM
PARTITION BY RANGE COLUMNS(gender,hire_date)
(PARTITION p01 VALUES LESS THAN ('F','1990-01-01') ,
PARTITION p02 VALUES LESS THAN ('F','2000-01-01') ,
PARTITION p03 VALUES LESS THAN ('F',MAXVALUE) ,
PARTITION p04 VALUES LESS THAN ('M','1990-01-01') ,
PARTITION p05 VALUES LESS THAN ('M','2000-01-01') ,
PARTITION p06 VALUES LESS THAN ('M',MAXVALUE) ,
PARTITION p07 VALUES LESS THAN (MAXVALUE,MAXVALUE)
위의 예제와 다르게 이것은 이론적인 측면을 보면 너무 많은 모호함을 가지고 있음을 알 수 있습니다. 첫 번째 파티션은 1990년 이전, 두 번째 파티션에서는 1990년에서 2000년 사이, 그리고 세 번째파티션은 남아있는 고용된 여자 직원을 저장합니다. 파티션 p04에서 p06도 비슷한 케이스이지만, 남자 직원을 저장합니다. 마지막 파티션의 조작의 경우: 누군가가 이 파티션에 저장이 되기 위해서는 어딘가에 실수가 있어야 합니다.
마지막 문장을 읽어보면, 올바른 문장인지 확인할 필요가 있습니다. 데이터(row)가 어떤 파티션에 저장되는지 어떻게 알 수 있을까요?
두가지 방법이 있습니다. 첫 번째 방법은 정의 하는데 사용되는 동일한 조건을 가진 질의를 하는 것입니다.
SELECT
CASE
WHEN gender = 'F' AND hire_date < '1990-01-01'
THEN 'p1'
WHEN gender = 'F' AND hire_date < '2000-01-01'
THEN 'p2'
WHEN gender = 'F' AND hire_date < '2999-01-01'
THEN 'p3'
WHEN gender = 'M' AND hire_date < '1990-01-01'
THEN 'p4'
WHEN gender = 'M' AND hire_date < '2000-01-01'
THEN 'p5'
WHEN gender = 'M' AND hire_date < '2999-01-01'
THEN 'p6'
ELSE
'p7'
END as p,
COUNT(*) AS rows
FROM employees
GROUP BY p;
+------+-------+
| p | rows |
+------+-------+
| p1 | 66212 |
| p2 | 53832 |
| p3 | 7 |
| p4 | 98585 |
| p5 | 81382 |
| p6 | 6 |
+------+-------+
만약 MyISAM 또는 ARCHIVE 테이블이라면, INFORMATION_SCHEMA에서 제공되는 통계를 신뢰 할 수 있습니다.
SELECT
partition_name part,
partition_expression expr,
partition_descript-xion descr,
table_rows
FROM
INFORMATION_SCHEMA.partitions
WHERE
TABLE_SCHEMA = schema()
AND TABLE_NAME='employees';
+------+------------------+-------------------+------------+
| part | expr | descr | table_rows |
+------+------------------+-------------------+------------+
| p01 | gender,hire_date | 'F','1990-01-01' | 66212 |
| p02 | gender,hire_date | 'F','2000-01-01' | 53832 |
| p03 | gender,hire_date | 'F',MAXVALUE | 7 |
| p04 | gender,hire_date | 'M','1990-01-01' | 98585 |
| p05 | gender,hire_date | 'M','2000-01-01' | 81382 |
| p06 | gender,hire_date | 'M',MAXVALUE | 6 |
| p07 | gender,hire_date | MAXVALUE,MAXVALUE | 0 |
+------+------------------+-------------------+------------+
InnoDB 엔진을 사용하는 경우에는, 위의 값은 근사치이며, 정확한 값이 필요하다면, INFORMATION_SCHEMA는 신뢰 할 수 없습니다.
한 가지 의문점은 위의 모든 설명과 성능에 관련된 것들은, 아직까지 미지수입니다. 이와 같은 partition pruning을 개선 사항으로 볼 수 있겠습니까? 답변은 분명히 '그렇다' 입니다. 5.1 버전과 달리, 5.5에서는 날짜뿐만 아니라, 모든 파티션은 COLUMNS 키워드로 정의된 partition pruning을 사용하는, 두 가지 기능의 파티션닝을 지원합니다. 다음을 보면:
select count(*) from employees where gender='F' and hire_date < '1990-01-01';
+----------+
| count(*) |
+----------+
| 66212 |
+----------+
1 row in set (0.05 sec)
explain partitions select count(*) from employees where gender='F' and hire_date < '1990-01-01'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: employees
partitions: p01
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 300024
Extra: Using where
첫 번째 파티션을 정의하는 조건을 사용하여, 매우 최적화된 쿼리를 얻었습니다. 그 뿐만 아니라, 일부 조건은 불필요한 부분이 제거된 파티션으로 부터 (검색) 혜택을 받았습니다.
select count(*) from employees where gender='F';
+----------+
| count(*) |
+----------+
| 120051 |
+----------+
1 row in set (0.12 sec)
explain partitions select count(*) from employees where gender='F'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: employees
partitions: p01,p02,p03,p04
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 300024
Extra: Using where
이것은 복잡한 인덱스에 사용된 것과 같은 알고리즘 입니다. 조건이 인덱스의 왼쪽 부분을 의미 하는 경우, MySQL은 그것을 사용합니다. 마찬가지로, 당신은 파티션 정의의 왼쪽 부분을 참조 한다면, 가능한 최대한 불필요한 부분을 제외합니다. 파티션 정의의 오른쪽 부분을 참조하는 경우에는 복합 인덱스와 불필요한 부분이 제거된 파티션이 작동하지 않습니다.
select count(*) from employees where hire_date < '1990-01-01';
+----------+
| count(*) |
+----------+
| 164797 |
+----------+
1 row in set (0.18 sec)
explain partitions select count(*) from employees where hire_date < '1990-01-01'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: employees
partitions: p01,p02,p03,p04,p05,p06,p07
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 300024
Extra: Using where
첫 번째를 사용하지 않고, 파티션 정의의 두 번째 부분을 참조하면, 전체 테이블을 검색합니다. 이것은 항상 파티션 생성과 쿼리 디자인을 할 때, 고려해 두어야 합니다.
사용성 개선: TRUNCATE PARTITION
파티션 ID 가장 매력적인 기능 중 하나는 거의 즉시 대량의 데이트를 제거하는 능력입니다. 이 스키마는 DBA들이 로그 데이터를 기록하는 날짜를 기준으로 정의된 파티션된 테이블에서, 정기적으로 오래된 기록이 보관된 파티션을 삭제하는 방법으로 매우 인기를 끌고 있습니다. 이 방법은 아주 잘 작동합니다. 첫 번째 (가장 오래된 기록을 가진) 파티션을 삭제 하고, 끝에 (최신 기록을 저장할) 새로운 파티션을 추가합니다.
모두 좋습니다. 단지 끝부터 잘라내야 합니다. 하지만 중간에 있는 파티션을 제거해야하는 경우에는 상황이 원활하게 진행되지 않습니다. 이런 경우에 대해서 아무 문제없이 파티션을 삭제 할 수 있습니다. 그러나 단지 파티션을 비우는 것을 원한다면, 상당히 어러운 문제에 직면한 것입니다. 파티션으로 부터 모든 레코드를 제거하기 위해서 할 수 있는 것:
- DELETE 구문을 사용하여, 잘려진 파티션의 장점의 대부분을 포기하는 방법
- DROP PARTITION을 사용한 다음, REORGANIZE PARTITIONS으로 다시 만들려면, 이전의 선택보다 더 많은 부하가 발생합니다.
MySQL 5.5버전에서는 DROP PARTITION과 같지만, 파티션이 삭제되는 대신에 다시 사용할 준비가 되어지는 TRUNCATE PARTITION 구문을 소개합니다.
TRUNCATE PARTITION 구문은 모든 DBA의 도구상자에 있어야 합니다.
더 미세한 조정: TO_SECONDS
보너스로 파티션 기능 개선 패키지는 날짜와 시간 컬럼을 조작하는 새로운 함수가 준비되어 있습니다. TO_SECONDS와 같은 기능으로 날짜 시간 컬럼을 "0"년 부터 초 단위로 변환할 수 있습니다. 만약 하루 보다 작은 시간 간격으로 파티션하려는 경우에 유용한 기능입니다.
향상된 기능의 나머지 부분과 같이, TO_SECONDS으로 파티션을 잘라내는 것은 날짜 함수의 수가 세 가지가 됨으로써, 효율적인 파티션닝을 할 수 있습니다.
TO_DAYS는, FROM_DAYS로 변환할 수 있지만, TO_SECONDS에 대한 그런 기능은 없습니다. 하지만 이런 것을 만드는 것은 어렵지 않습니다.
drop function if exists from_seconds;
delimiter //
create function from_seconds (secs bigint)
returns DATETIME
begin
declare days INT;
declare secs_per_day INT;
DECLARE ZH INT;
DECLARE ZM INT;
DECLARE ZS INT;
set secs_per_day = 60 * 60 * 24;
set days = floor(secs / secs_per_day);
set secs = secs - (secs_per_day * days);
set ZH = floor(secs / 3600);
set ZM = floor(secs / 60) - ZH * 60;
set ZS = secs - (ZH * 3600 + ZM * 60);
return CAST(CONCAT(FROM_DAYS(days), ' ', ZH, ':', ZM, ':', ZS) as DATETIME);
end //
delimiter ;
이런 새로운 무기로 무장한 우리는 하루도 안 되는 시간을 기준으로 정의한 파티션과 같은 테이블을 자신 있게 만들 수 있습니다.
CREATE TABLE t2 (
dt datetime
)
PARTITION BY RANGE (to_seconds(dt))
(
PARTITION p01 VALUES LESS THAN (to_seconds('2009-11-30 08:00:00')) ,
PARTITION p02 VALUES LESS THAN (to_seconds('2009-11-30 16:00:00')) ,
PARTITION p03 VALUES LESS THAN (to_seconds('2009-12-01 00:00:00')) ,
PARTITION p04 VALUES LESS THAN (to_seconds('2009-12-01 08:00:00')) ,
PARTITION p05 VALUES LESS THAN (to_seconds('2009-12-01 16:00:00')) ,
PARTITION p06 VALUES LESS THAN (MAXVALUE)
);
show create table t2\G
*************************** 1. row ***************************
Table: t2
Create Table: CREATE TABLE `t2` (
`dt` datetime DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1
/*!50500 PARTITION BY RANGE (to_seconds(dt))
(PARTITION p01 VALUES LESS THAN (63426787200) ENGINE = MyISAM,
PARTITION p02 VALUES LESS THAN (63426816000) ENGINE = MyISAM,
PARTITION p03 VALUES LESS THAN (63426844800) ENGINE = MyISAM,
PARTITION p04 VALUES LESS THAN (63426873600) ENGINE = MyISAM,
PARTITION p05 VALUES LESS THAN (63426902400) ENGINE = MyISAM,
PARTITION p06 VALUES LESS THAN MAXVALUE ENGINE = MyISAM) */
COLUMNS 키워드를 사용하지 않기 때문에 (그리고 우리가 COLUMNS 과 함수의 홈합을 허용하지 않은 이유로 할 수 없었던) TO_SECONDS 함수의 결과로 정의되어진 테이블 안에 값을 기록되었습니다.
그러나 새로운 기능덕분에,
오래된 블로그 포스트에서 본것 같은 값을 변환하지 않아도 사람이 읽을 수 있는 값을 사용할 수 있습니다.
select
partition_name part,
partition_expression expr,
from_seconds(partition_descript-xion) descr,
table_rows
FROM
INFORMATION_SCHEMA.partitions
WHERE
TABLE_SCHEMA = 'test'
AND TABLE_NAME='t2';
+------+----------------+---------------------+------------+
| part | expr | descr | table_rows |
+------+----------------+---------------------+------------+
| p01 | to_seconds(dt) | 2009-11-30 08:00:00 | 0 |
| p02 | to_seconds(dt) | 2009-11-30 16:00:00 | 0 |
| p03 | to_seconds(dt) | 2009-12-01 00:00:00 | 0 |
| p04 | to_seconds(dt) | 2009-12-01 08:00:00 | 0 |
| p05 | to_seconds(dt) | 2009-12-01 16:00:00 | 0 |
| p06 | to_seconds(dt) | 0000-00-00 00:00:00 | 0 |
+------+----------------+---------------------+------------+
요약
MySQL 5.5버전은 파티션을 사용하는 사용자에게 확실히 좋은 소식입니다. (응답 시간과 같은 성능을 평가하는 경우라면) 성능에 직접적인 개선은 없었지만, 기능향상으로 사용이 쉬워지고, 시간을 절약할 수 있는 새로운 TRUNCATE PARTITION 구문과 같은 결과로 DBA나 최종 사용자의 시간을 많이 절약할 수 있습니다.
