对大型mysql表进行分区

Question

对大型mysql表进行分区

我有一个大 (40GB) 的表，我想对其进行分区。这些行基本上是一次写入多次读取。目前我正在使用带有 file_per_table 的 mysql 5.5 innodb。由于重建整个文件需要很长时间，因此很难优化此表。

我希望对表进行分区，以便只写入一个分区；我认为这意味着优化表将花费更少的时间，因为每个非当前文件只会优化一次，不需要再次触及。

我是 mysql 中的表分区的新手，我不确定解决这个问题的正确方法是什么。我知道没有“文件大小”分区方案，所以下一个最好的方法是在行范围内进行 SWAG，这将导致我更喜欢的文件大小（3-4GB 似乎不错 - 所以我们每年大约有 3-4 个文件）当前利率）。我的想法是范围分区，id但这不能满足文件分区的技术要求（“分区表的分区表达式中使用的所有列必须是表可能具有的每个唯一键的一部分。”）。那么解决这个问题的正确方法是什么？以下是精简为重要部分的表定义：

+-----------------+--------------+------+-----+---------+----------------+
| Field           | Type         | Null | Key | Default | Extra          |
+-----------------+--------------+------+-----+---------+----------------+
| id              | int(11)      | NO   | PRI | NULL    | auto_increment |
| TransactionId   | int(11)      | NO   | MUL | NULL    |                |
| Parent          | int(11)      | NO   | MUL | 0       |                |
| Headers         | longtext     | YES  |     | NULL    |                |
| Creator         | int(11)      | NO   |     | 0       |                |
| Created         | datetime     | YES  |     | NULL    |                |
+-----------------+--------------+------+-----+---------+----------------+

Run Code Online (Sandbox Code Playgroud)

时间过得真快……我们已经转而使用 mysql.com 存储库并升级到 5.6。审判时间。使用较小的表，我尝试使用 Online DDL 优化。我没有得到预期的结果：

mysql> optimize table Users;
+-----------+----------+----------+-------------------------------------------------------------------+
| Table     | Op       | Msg_type | Msg_text                                                          |
+-----------+----------+----------+-------------------------------------------------------------------+
| rt4.Users | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| rt4.Users | optimize | status   | OK                                                                |
+-----------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.43 sec)

mysql> desc Users;
+-----------------------+--------------+------+-----+---------+----------------+
| Field                 | Type         | Null | Key | Default | Extra          |
+-----------------------+--------------+------+-----+---------+----------------+
| id                    | int(11)      | NO   | PRI | NULL    | auto_increment |
| Name                  | varchar(200) | NO   | UNI | NULL    |                |
| Password              | varchar(256) | YES  |     | NULL    |                |
| AuthToken             | varchar(16)  | YES  |     | NULL    |                |
| Comments              | text         | YES  |     | NULL    |                |
| Signature             | text         | YES  |     | NULL    |                |
| EmailAddress          | varchar(120) | YES  | MUL | NULL    |                |
| FreeformContactInfo   | text         | YES  |     | NULL    |                |
| Organization          | varchar(200) | YES  |     | NULL    |                |
| RealName              | varchar(120) | YES  |     | NULL    |                |
| NickName              | varchar(16)  | YES  |     | NULL    |                |
| Lang                  | varchar(16)  | YES  |     | NULL    |                |
| EmailEncoding         | varchar(16)  | YES  |     | NULL    |                |
| WebEncoding           | varchar(16)  | YES  |     | NULL    |                |
| ExternalContactInfoId | varchar(100) | YES  |     | NULL    |                |
| ContactInfoSystem     | varchar(30)  | YES  |     | NULL    |                |
| ExternalAuthId        | varchar(100) | YES  |     | NULL    |                |
| AuthSystem            | varchar(30)  | YES  |     | NULL    |                |
| Gecos                 | varchar(16)  | YES  |     | NULL    |                |
| HomePhone             | varchar(30)  | YES  |     | NULL    |                |
| WorkPhone             | varchar(30)  | YES  |     | NULL    |                |
| MobilePhone           | varchar(30)  | YES  |     | NULL    |                |
| PagerPhone            | varchar(30)  | YES  |     | NULL    |                |
| Address1              | varchar(200) | YES  |     | NULL    |                |
| Address2              | varchar(200) | YES  |     | NULL    |                |
| City                  | varchar(100) | YES  |     | NULL    |                |
| State                 | varchar(100) | YES  |     | NULL    |                |
| Zip                   | varchar(16)  | YES  |     | NULL    |                |
| Country               | varchar(50)  | YES  |     | NULL    |                |
| Timezone              | varchar(50)  | YES  |     | NULL    |                |
| PGPKey                | text         | YES  |     | NULL    |                |
| Creator               | int(11)      | NO   |     | 0       |                |
| Created               | datetime     | YES  |     | NULL    |                |
| LastUpdatedBy         | int(11)      | NO   |     | 0       |                |
| LastUpdated           | datetime     | YES  |     | NULL    |                |
| SMIMECertificate      | text         | YES  |     | NULL    |                |
+-----------------------+--------------+------+-----+---------+----------------+
36 rows in set (0.00 sec)

mysql> select @@VERSION;
+------------+
| @@VERSION  |
+------------+
| 5.6.19-log |
+------------+
1 row in set (0.00 sec)

Run Code Online (Sandbox Code Playgroud)

我错过了什么？

Answer 1

Bil*_*win 7

首先，您应该考虑以另一种方式解决问题。

升级到 MySQL 5.6，OPTIMIZE TABLE无需阻塞即可工作（对于 InnoDB 表），因为InnoDB Online DDL支持它。
如果无法升级，可以尝试使用 Percona Toolkit 的 pt-online-schema-change，它可以无阻塞地进行表重建。
```
$ pt-online-schema-change h=localhost,D=mydatabase,t=mytable --execute
    --alter="ENGINE=InnoDB"
```
Run Code Online (Sandbox Code Playgroud)

如果您坚持使用分区，是的，您必须id在显示的表中制作分区键。您可以使用将表转换为分区ALTER TABLE。如果您需要非阻塞的转换操作，请使用 pt-online-schema-change。

无法分区到固定大小的分区。您必须按值进行分区。但是，每个分区达到特定大小真的那么重要吗？

关于分区大小的评论：

使用 RANGE 分区时，我所做的是设置一个时间表来 ALTER TABLE 并不时拆分最后一个分区。如果您有规律的增长率，这很容易，但如果您有不规则的增长模式，您可以设置定期检查来检查每个分区的行数（使用INFORMATION_SCHEMA.PARTITIONS），如果它越来越满了。

例如，让我们设置一个按范围分区的表id。

CREATE TABLE `mytable` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `transactionid` int(11) NOT NULL,
  `parent` int(11) NOT NULL,
  `headers` longtext,
  `creator` int(11) NOT NULL,
  `created` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `id` (`id`),
  KEY `transactionid` (`transactionid`,`parent`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
/*!50100 PARTITION BY RANGE (id)
(PARTITION p0 VALUES LESS THAN (0) ENGINE = InnoDB,
 PARTITION p1 VALUES LESS THAN (1000) ENGINE = InnoDB,
 PARTITION p2 VALUES LESS THAN (2000) ENGINE = InnoDB,
 PARTITION p3 VALUES LESS THAN (3000) ENGINE = InnoDB,
 PARTITION p4 VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */

Run Code Online (Sandbox Code Playgroud)

随着MAX(id)接近 3000，它已接近填满p3并溢出到p4. 所以是时候重组了。最好在任何数据溢出到之前执行此操作p4，因为重组只会影响最后一个空分区，因此速度非常快。

ALTER TABLE mytable REORGANIZE PARTITION p4 INTO 
(PARTITION p4 VALUES LESS THAN (4000), PARTITION p5 VALUES LESS THAN MAXVALUE);

Run Code Online (Sandbox Code Playgroud)

即使您错过了一天并且您将一些数据放入了 old 中p4，也有可能没有太多数据。但是，如果您一两个月忽略了这一点，并且p4填充了大量数据，那么 REORGANIZE 将花费更长的时间。

归档时间：	11 年，4 月前
查看次数：	4747 次
最近记录：	11 年，2 月前