建议支持AUTO UUID，方便稀疏主键。
您好： 可以考虑在插入数据时生成，是否能满足您的需求？
嗯，其实是可以的，代价就是需要跟业务讲清楚，这个ID不是自增的了，不能再想当然的按照ID的大小决定写入的先后顺序了，有时候Mysql用户会有这样固有的思维。
业务上就不方便了，我希望是业务不要感知，这个主键业务本来也不用。
了解。
相对于 AUTO_RANDOM，AUTO UUID 的好处，是可以在通过字符串类型在潜意识中提醒用户，数据是非自增的。
缺点在于：
- 如果考虑空间，
UUID()分配出来的结果比 BIGINT 长不少。 -
UUID()分配的是字符串类型。TiDB 目前不支持字符串类型主键的聚簇索引，一方面，TiDB 需要为主键建立额外的索引数据，如果有主键查询，也需要额外的回表操作。
请再次权衡一下上面的优缺点。如果仍然希望使用 AUTO UUID，那么我觉得可以为字符串主键支持 DEFAULT UUID() 函数。
嗯，理解了，仔细看了编码设计说明，有一点儿疑惑是，把字符串类型的主键排除在聚簇索引之外，文档并没有解释的特别清楚它的优势，相比于直接编码string。点查需要回表这样操作消耗太多的网络和磁盘IO感觉得不偿失。或者有其他层面的设计考虑，这个我不是很明白了。如果仅仅是因为这样节约空间，感觉并不合适。
Hi，这里其实并不是 “把字符串类型的主键排除在聚簇索引之外"，而是 “优化整数主键为聚簇索引”，对于所有的非整数主键，都是没有聚簇索引的。具体这么做的原因，是以为 TiDB 的隐式 rowid 就是整数类型，整数主键可以直接映射到 rowid，实现起来非常简单。
另外，TiDB 正在尝试实现所有类型主键的聚簇索引，没有意外的话会在下一个大版本提供支持。
明白了。 自增主键带来了很多的挑战，一方面很多业务使用它仅仅是作为一种逻辑时钟，来确定插入的先后顺序，将来导出的时候比较方便，如果使用时间戳其实本质是一样的，仍然有热分片的问题。仍然建议增加一个UUID的函数，这样用户就不用自己实现一个UUID了，我们这边目前针对这种场景的设计的方案是时间戳（精度秒或者分钟…）+UUID的唯一索引，来平衡这种逻辑顺序（业务并不要求决定的顺序）。
还是想讨论一下UUID的问题，如果使用UUID写入数据，尽管离散程度很高，几乎不会有热分片问题，但是一个潜在的隐患或者副作用就是对底层rocksDB的压力，因为数据完全无序，compaction的压力就会很高因为几乎所有的数据都要重新排序（同一层内）。这种对IO和CPU的使用其实会反噬因为随机写入带来的吞吐提升。
1 个赞
你好，
关于技术性的讨论可以移步 [开发者问答](https://asktug.com/c/developer/developer-qa)，在哪个版块，研发同学会和你有更直接的讨论哦~
感谢你的理解和配合，可以积极发帖回帖！
1 个赞
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。