按秒进行分库分表是个好的选择吗？

背景

有个服务要生成唯一 ID （支持批量），后续的查询（仅支持单条）也按照这个唯一 ID 来查，因此毫无疑问分库分表依据只能是这个唯一 ID 。

这个唯一 ID 可以看作雪花算法，里面有比如机器号码、时间、自增 ID 等信息（可以反解出来）。

问题

设计分库分表方法的时候，考虑了以下的方案：

1. 均匀分布，例如按照 hash1(唯一 ID) % 10 来分库，按 hash2(唯一 ID) % 100 来分表。这样的好处是数据都会均匀，没有什么热点的问题。但是后来又觉得，因为生成的时候是批量生成的，例如生成了 200 个 ID 想写进表里，那如果全都是 hash 的，就会需要写多个库、多个表，而且很大可能没办法合并（因为是完全均匀的）。

2. 为了减少事务数量，又想了个办法按照 "唯一 ID 中的时间戳+机器号码" % 10 来分库，这样同一台机器每秒内生成的 ID 都可以落到相同相同的 DB ，只用执行 1 次事务 INSERT 。

3. 再后来又想把对表的写入也能批量完成，因为按照方案 2 ，如果分表的依据依然是 hash2(唯一 ID)%100 ，那有可能是在一个事务里面要写很多条 INSERT 到不同的表，效率也不搞。所以就想把分表的方案改成 hash2(唯一 ID 中的时间戳)，这样同一秒内生成的所有唯一 ID 都会落入相同的表了。

现在的实现是第三种方案，但是在表维度来说，短时间内会有热点问题（但是拉长了看依然是均匀的），想问下有经验的老哥，这种场景有风险、有更好的方案吗（ MySQL ，且暂不考虑替换其他中间件、数据库的方案）？

PS: 写入量可以暂且预估为每天要写入几千万行左右，数据量不大。