使用 unix 时间戳作为订单 ID 有什么缺点？

Question

我正在设计一个购物项目，正在考虑使用 unix 时间戳作为订单 ID。我知道我可以使用 mySQL 增量数字作为订单 ID，例如 10001、10002 等，但我不想让每个人都知道实际有多少订单。

这样做安全吗？我显然不希望每秒超过 1 个订单，所以我应该是安全的，对吧？

function check_number(){

$unique_number = time();
$exists = $this->count_rows('orders', "WHERE order_id='" . $unique_number . "'");

if ($exists >0){
    $results = check_number();
}
else{
    $results = $unique_number;
    return $results;
}
}

Answer 1

一个更强大的解决方案是使用 PHP 的 uniqid() 函数。它隐藏了您系统中的订单数量，但如果两个或更多订单恰好同时进入，它不会崩溃。

至于实际问题：不，使用 unix 时间戳作为半随机事件的唯一 ID 是不安全的，例如用户下订单。无论多么不可能，既然可以轻松避免碰撞，为什么还要留下碰撞的可能性呢？

Answer 2

我不会推荐它，因为有可能在同一秒内发出两个订单。使用默认增量和 add/subtract 固定数字的 ID，以便用户看到更大的数字。

$ID = $_GET['ID'];
$ID -= 183727; // subtract offset
// Do mysql stuff
// Build an ID for an URL
$ID += 183727;
echo 'http://../test.php?order=' .$ID;

Answer 3

你可以制作一个 crontab 来做 ALTER TABLE orders AUTO_INCREMENT = max_id + <something>; 每天或每小时随机移动它（虽然这不是最好的做法）；或者您可以在插入中随机放置 ID（超过当前最大 ID）。
如果你想在数据库中保留整数，你可以使用 base64_ family with a salt。
您可以在 URL 中使用 uniques slug
你可以使用com_create_guid或类似的函数甚至生成随机字符串/数字，但要确保你在数据库中有一个"UNIQUE"约束。

"timestamp" 的问题与许多并发操作有关，它在特定时间范围内不是唯一的；您可以使用微秒并在末尾添加一些随机数 - 这会有所帮助。

使用 unix 时间戳作为订单 ID 有什么缺点？

what are the cons of using unix timestamp as an order ID?

php

mysql

unix

timestamp