优化超大表的存储大小答案

【问题标题】：Optimize storage size for a very large table优化超大表的存储大小
【发布时间】：2016-11-26 05:42:46
【问题描述】：

我在 MyISAM 存储引擎上的 MySQL 中有大量行（数十亿）以下模式。关于如何更有效地存储（存储方面）的任何建议？

mysql> describe options;
+---------------+------------------+------+-----+---------+----------------+
| Field         | Type             | Null | Key | Default | Extra          |
+---------------+------------------+------+-----+---------+----------------+
| stockid       | int(10) unsigned | NO   | MUL | NULL    |                |
| strike        | float            | NO   |     | NULL    |                |
| symbol        | varchar(63)      | NO   |     | NULL    |                |
| last          | float            | NO   |     | NULL    |                |
| chg           | float            | NO   |     | NULL    |                |
| bid           | float            | NO   |     | NULL    |                |
| ask           | float            | NO   |     | NULL    |                |
| expirydate    | varchar(63)      | YES  |     | NULL    |                |
| ticker        | varchar(63)      | YES  |     | NULL    |                |
| expiry        | datetime         | YES  |     | NULL    |                |
| type          | varchar(63)      | YES  |     | NULL    |                |
| datecaptured  | datetime         | YES  |     | NULL    |                |
| volume        | bigint(20)       | YES  |     | NULL    |                |
| openint       | bigint(20)       | YES  |     | NULL    |                |
| lastclosedate | date             | YES  |     | NULL    |                |
| row_id        | int(11)          | NO   | PRI | NULL    | auto_increment |
+---------------+------------------+------+-----+---------+----------------+

【问题讨论】：

int(11) 可能没有想象的那么大 - 它的容量不超过int(2)。如果这真的是“数十亿”，那将是一个问题。
last/chg/bid/ask 列看起来像与市场价格相关的值，FLOAT 是一个非常危险的数据类型选择，其中涉及金钱，除非您可以接受不精确的近似值，这是使FLOAT 相对节省空间的权衡。您熟悉它的局限性吗？
确实是这样——将钱存储为 INT *100 的做法是什么？还是有更好的模型？

标签： mysql

【解决方案1】：

这里最明显的问题是将日期存储为字符串，这会占用不必要的空间，并使索引变得不切实际。您还需要检查为什么第一列设置为不规则的INT(10) UNSIGNED 类型而不是默认的INT(11)。

如果您想要非常紧凑的表格，您可能需要尝试ARCHIVE engine 类型。它有只追加的表，但它们被压缩并且可以保存大量数据而无需修剪或修剪。缺点是它们也没有索引，但这对你来说似乎不是问题。

注意：MyISAM 是一个非常古老且脆弱的存储引擎，因此如果您可以从它迁移到 InnoDB，您会做得更好。由于 MyISAM 没有日志，因此它无法从服务器崩溃中轻松恢复，并且很容易损坏而无法修复。 InnoDB 能够从大多数情况下恢复过来，在不能恢复的情况下，您仍然可以只读转储它并在其他地方使用数据。

如果SHOW TABLE STATUS 没有表示存储有问题，请不要担心。硬盘很便宜，甚至 SSD 也很便宜。

【讨论】：