Mysql
在 MySQL 5.5 上移動到“真實”日期分區是否有優勢?
我們每天為我們的一些表使用分區。我們從 MySQL 5.1 開始,所以我們必須使用 to_days(
end_time
是一datetime
列)進行分區:ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin /*!50100 PARTITION BY RANGE ( to_days(end_time)) (PARTITION p20130521 VALUES LESS THAN (735375) ENGINE = InnoDB, .... PARTITION p20130603 VALUES LESS THAN (735388) ENGINE = InnoDB, PARTITION p20130604 VALUES LESS THAN (735389) ENGINE = InnoDB, PARTITION p20130605 VALUES LESS THAN (735390) ENGINE = InnoDB, PARTITION p20130606 VALUES LESS THAN (735391) ENGINE = InnoDB, PARTITION p99991230 VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */
從 MySQL 5.5 開始,現在可以避免
to_days
按實際日期進行 and 分區。這樣做有什麼(速度)優勢嗎?
使用to_days進行分區
to_days函式產生一個700,000的 6 位數字(在 MEDUIMINT 範圍內)。
使用 DATE 或 DATETIME 進行分區
DATE 佔用 3 個字節。DATETIME 佔用 8 個字節。
推測
今天的UNIX_TIMESTAMP超過 13.7 億。儲存它需要 4 個字節。範圍分區允許範圍值很高。這是MySQL 文件中的一個範例:
也可以使用 UNIX_TIMESTAMP() 函式根據 TIMESTAMP 列的值按 RANGE 對錶進行分區,如下例所示:
CREATE TABLE quarterly_report_status ( report_id INT NOT NULL, report_status VARCHAR(20) NOT NULL, report_updated TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) PARTITION BY RANGE ( UNIX_TIMESTAMP(report_updated) ) ( PARTITION p0 VALUES LESS THAN ( UNIX_TIMESTAMP('2008-01-01 00:00:00') ), PARTITION p1 VALUES LESS THAN ( UNIX_TIMESTAMP('2008-04-01 00:00:00') ), PARTITION p2 VALUES LESS THAN ( UNIX_TIMESTAMP('2008-07-01 00:00:00') ), PARTITION p3 VALUES LESS THAN ( UNIX_TIMESTAMP('2008-10-01 00:00:00') ), PARTITION p4 VALUES LESS THAN ( UNIX_TIMESTAMP('2009-01-01 00:00:00') ), PARTITION p5 VALUES LESS THAN ( UNIX_TIMESTAMP('2009-04-01 00:00:00') ), PARTITION p6 VALUES LESS THAN ( UNIX_TIMESTAMP('2009-07-01 00:00:00') ), PARTITION p7 VALUES LESS THAN ( UNIX_TIMESTAMP('2009-10-01 00:00:00') ), PARTITION p8 VALUES LESS THAN ( UNIX_TIMESTAMP('2010-01-01 00:00:00') ), PARTITION p9 VALUES LESS THAN (MAXVALUE) );
分區似乎以數字表示為 4 字節無符號整數。如前所述,
DATE
佔用 3 個字節,但據我觀察,分區由 4 個字節的數字限定。鑑於此,將 a 表示DATE
為RANGE
參數實際上並沒有給您帶來任何好處,除了用於定義範圍的更簡潔的語法。自己表達DATE 的to_days或讓 mysql 為你做這件事歸結為個人選擇。