MySQL大表分片到基于唯一ID的小表

Question

我们有一个包含以下列的大型 MySQL 表 (device_data)：

ID (int)
dt (timestamp)
serial_number (char(20))
data1 (double)
data2 (double)
... // other columns

该表每天接收大约 1000 万行。

我们根据时间戳的日期 (device_data_YYYYMMDD) 对表进行了分片。但是，我们认为这并不有效，因为我们的大多数查询（如下所示）总是检查“serial_number”并且会跨多个日期执行。

SELECT * FROM device_data WHERE serial_number = 'XXX' AND dt >= '2018-01-01' AND dt <= '2018-01-07';

因此，我们认为根据序列号创建分片会更有效。基本上，我们将拥有：

device_data_<serial_number>
device_data_0012393746
device_data_7891238456

因此，当我们要查找特定设备的数据时，我们可以很容易地引用为：

SELECT * FROM device_data_<serial_number> WHERE dt >= '2018-01-01' AND dt <= '2018-01-07';

这种方法似乎很有效，因为：

1. 应用程序始终会首先访问基于设备的数据。
2. 我们检查了没有先指定设备序列号的查询访问数据。
3. 每个设备的表格都相对较小（每天 9000 行）

我们认为我们将面临的一些挑战是：

1. 我们有很多设备。这意味着表 device_data_ 也会很多。我已经检查过 MySQL 没有限制数据库中的表数量。与将它们放在一个表中相比，这会影响性能吗？
2. 这将如何影响我们以后想要扩展 MySQL（例如使用主/从等）？
3. 是否有其他替代方案/解决方案可以解决此问题？

更新。下面是我们现有表的 show create table 结果：

CREATE TABLE `test_udp_new` (
 `id` int(20) unsigned NOT NULL AUTO_INCREMENT,
 `dt` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
 `device_sn` varchar(20) NOT NULL,
 `gps_date` datetime NOT NULL,
 `lat` decimal(10,5) DEFAULT NULL,
 `lng` decimal(10,5) DEFAULT NULL,
 PRIMARY KEY (`id`),
 KEY `device_sn_2` (`dt`,`device_sn`),
 KEY `dt` (`dt`),
 KEY `data` (`data`) USING BTREE,
 KEY `test_udp_new_device_sn_dt_index` (`device_sn`,`dt`),
 KEY `test_udp_new_device_sn_data_dt_index` (`device_sn`,`data`,`dt`)
) ENGINE=InnoDB AUTO_INCREMENT=44449751 DEFAULT CHARSET=latin1 ROW_FORMAT=DYNAMIC

最常运行的查询：

SELECT  *
    FROM  test_udp_new
    WHERE  device_sn = 'xxx'
      AND  dt >= 'xxx'
      AND  dt <= 'xxx'
    ORDER BY  dt DESC;

Answer 1

处理那个查询的最佳方式是在一个非分区表中

INDEX(serial_number, dt)

更好的是更改PRIMARY KEY。假设您目前拥有id AUTO_INCREMENT，因为没有适合作为“自然PK”的唯一列组合，

PRIMARY KEY(serial_number, dt, id),  -- to optimize that query
INDEX(id)  -- to keep AUTO_INCREMENT happy

如果还有其他经常运行的查询，请提供；这可能会伤害他们。在大型表中，找到最佳索引是一项杂耍任务。

其他评论：

• 很少有使用案例可以通过分区实际加快处理速度。
• 制作大量“相同”的表是维护的噩梦，同样，也不是性能优势。可能有一百个关于 stackoverflow 的 Q&A 大喊不要这样做。
• 通过在PRIMARY KEY 中拥有serial_numberfirst，所有引用单个序列号的查询都可能受益。
• 一百万serial_numbers？没问题。
• 分区的一个常见用例涉及清除“旧”数据。这是因为大的DELETEs 比DROP PARTITION 更昂贵。这涉及PARTITION BY RANGE(TO_DAYS(dt))。如果您对此感兴趣，我的 PK 建议仍然有效。 （无论有没有这种分区，相关查询的运行速度都差不多。）
• 在表的容量超过您的磁盘之前需要多少个月？ （如果这是一个问题，让我们讨论一下。）
• 你需要8字节的DOUBLE吗？ FLOAT 具有大约 7 位有效数字的精度，并且只占用 4 个字节。
• 您正在使用 InnoDB？
• serial_number 是否固定为 20 个字符？如果没有，请使用VARCHAR。另外，CHARACTER SET ascii 可能比默认的 utf8 更好？
• 每个表（或表的每个分区）至少涉及一个操作系统必须处理的文件。当你有“太多”时，操作系统会抱怨，通常在 MySQL 抱怨之前。 （药物过量都很难“死”。）

Answer 2

解决查询

 PRIMARY KEY (`id`),
 KEY `device_sn_2` (`dt`,`device_sn`),
 KEY `dt` (`dt`),
 KEY `data` (`data`) USING BTREE,
 KEY `test_udp_new_device_sn_dt_index` (`device_sn`,`dt`),
 KEY `test_udp_new_device_sn_data_dt_index` (`device_sn`,`data`,`dt`)

-->

 PRIMARY KEY(`device_sn`,`dt`, id),
 INDEX(id)
 KEY `dt_sn` (`dt`,`device_sn`),
 KEY `data` (`data`) USING BTREE,

注意事项：

• 通过使用device_sn, dt 开始PK，您可以获得使用WHERE device_sn = .. AND dt BETWEEN ... 进行查询的集群优势
• INDEX(id) 是为了让AUTO_INCREMENT 开心。
• 当您有INDEX(a,b) 时，INDEX(a) 是多余的。
• (20) 毫无意义； id 将达到 40 亿左右。
• 我扔掉了最后一个索引，因为新的 PK 可能对它有足够的帮助。
• lng decimal(10,5) -- 小数点左边不需要 5 个小数位；只需要 3 或 2。所以：lat decimal(7,5),lng 十进制（8,5）`。这将总共节省每行 3 个字节。