將 SHA256 壓縮為可行的數據庫 ID？
對密碼學不太了解，因此需要一些幫助。
我想在我的數據庫中為使用者使用 SHA256 字元串作為唯一 id，但是很難擴展。
是否可以將 SHA256 字元串轉換為更短的唯一版本，不會發生衝突（或很少發生衝突）？
在這種情況下，通過 CRC32、FNV164 或 ADLER32 傳遞 SHA256 字元串是否可行？
我認為這是一個 XY 問題，實際上應該發佈在Software Engineering SE上。OP 中描述的目標，即使用者 ID 的生成，可以在沒有任何密碼學的情況下解決。
1. 縮放
當負載可以在短時間內基本上增加時，縮放是相關的。但只有新使用者才需要新的使用者 ID。一位使用者通常需要 1 到 5 分鐘進行註冊。因此，每個使用者每分鐘擁有的新 ID 不會超過 1 個。
許多數據庫提供 ID 生成器。PostreSQL、MariaDB、Oracle 提供了稱為“序列”的生成器。MySQL 提供自動增量 ID。不僅在直接使用時速度很快，而且這些數據庫還提供了額外的性能優化，例如 ID 池。Java 和 C# 等平台與這些 ID 生成器很好地集成在一起。基本上，新 ID 的生成意味著只增加一個整數，並且很少需要數據庫請求。
範例：假設您使用 PostgreSQL 並使用包含 10 000 個 ID 的池進行序列化。假設應用程序向數據庫請求刷新池範圍需要 10 毫秒。因此，您可以為每個應用程序實例（即每個集群節點、每個 Kubernetes pod 或類似情況）每秒生成 1 000 000 個新 ID。該生成器將在 2 小時內產生與全世界人數一樣多的 ID。
顯然，如果使用這樣的標準使用者 ID 生成器，它不會成為瓶頸。
2.縮短
您打算為每個使用者儲存多少數據？1K、10K、100K？假設每個使用者有 1K 數據。假設您擁有與 Facebook 或 Twitter 一樣多的使用者。因此 4 個字節的 ID 就足夠了。將 SHA-256 從 32 個字節截斷為 4 個字節可為每個使用者節省 28 個字節，節省的儲存空間不到 3%。因此，找到一種將 SHA-256 轉換為 4 字節而沒有很多衝突的算法的複雜性、正確實現它的努力、對發生衝突的情況進行處理的努力、錯誤修復的努力以及總成本這種解決方案的成本可能遠高於節省 3% 的儲存成本。計算它，然後你就會知道它是否適合你的情況。