可以的。但逻辑确实很奇怪，不是很建议，因为：

double的运算因为精度问题和我们的预测不一定一致；
double里有很多NaN表示异常，无法排序；

double占用的空间相当于bigint，干嘛不用bigint?



【 在 misslost 的大作中提到: 】
: 最近一个小项目里面，因为某种不足评论的原因，在考虑用double做表的形式主键。是业务系统内部生成的唯一递增的值。
: 虽然是觉得荒谬。但还是想认真请教一下，这么做有没有大的弊端？是否可行？
:
--
FROM 183.95.135.*

理论上可以
实际上是挺奇怪的。
你能确保非空唯一就行。

【 在 misslost 的大作中提到: 】
: 标  题: double类型可以用来做形式主键吗？
: 发信站: 水木社区 (Fri Mar  3 18:31:17 2023), 站内
:
: 最近一个小项目里面，因为某种不足评论的原因，在考虑用double做表的形式主键。是业务系统内部生成的唯一递增的值。
:
: 虽然是觉得荒谬。但还是想认真请教一下，这么做有没有大的弊端？是否可行？
:
:
: --
: ※ 修改:·misslost 于 Mar  3 18:32:06 2023 修改本文·[FROM: 120.245.130.*]
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 120.245.130.*]
--
修改:misslost FROM 120.245.130.*
FROM 124.126.150.*

        转成string时在前面补0，不会影响比较

【 在 misslost 的大作中提到: 】
: 关于数学运算。我感觉主键主要是比较关系运算，不需要对主键进行数学运算。所以好像没什么影响？
: 因为主键的值是很规范的很普通的浮点值，也不会有NaN等问题？
: 占用空间确实是8字节。其实本来是希望用int64 但是因为某种奇怪的外部原因 不能选择这个类型。（其实这个奇怪原因也可以解释一下，是无关话题。因为用到protobuf定义数据结构和json规范。而protobuf认为json的局限性导致没有int64的完善支持，所以会把int64转换为字符串存储
: ...................
--
FROM 114.253.36.*

这里我强调的是 形式主键，不是业务主键。所以，一般不存在数学运算的情况。
【 在 roy 的大作中提到: 】
: 1. double比较肯定比int要慢的多
:         2. 如何保证查询时生成的double键值和主键里存的值完全一致？
: 最简单的，0.1+0.1+0.1不等于0.3
: ...................
--
FROM 120.245.130.*

【 在 misslost 的大作中提到: 】
: 关于数学运算。我感觉主键主要是比较关系运算，不需要对主键进行数学运算。所以好像没什么影响？
: 因为主键的值是很规范的很普通的浮点值，也不会有NaN等问题？
: 占用空间确实是8字节。其实本来是希望用int64 但是因为某种奇怪的外部原因 不能选择这个类型。（其实这个奇怪原因也可以解释一下，是无关话题。因为用到protobuf定义数据结构和json规范。而protobuf认为json的局限性导致没有int64的完善支持，所以会把int64转换为字符串存储。这在很多地方就难受了，存储和比较，排序都会有问题。所以考虑用double规避这个问题。）
: ...................

如果数据库为啥不用int64， BIGINT， 至于数据传输，序列化这根本不是问题， 无非就是序列化过程做一下处理， 序列化本来也就是做这个工作的， 这是本分。
至于protobuf或者json支持不支持64， 这根本不是问题， 无论用字符串传输， 或者干脆弄成两个int传输都很容易。
所以， 我觉得， 底层逻辑使用int64就是正途， 换成double反倒是因噎废食，反倒让逻辑代码不伦不类。
--
FROM 115.171.245.*