1、業務場景：例如訂單、支付單號等比較敏感的肯定不能自增了，都是安全級別很高的欄位，需要唯一id作為主鍵。

2、技術實現：在實際開發過程中批次匯入或處理資料的時候要考慮到技術實現的效能那麼要多方面驗證用自增主鍵還是非自增主鍵了。

簡單寫點我的經驗。

1，如果表只是用來記錄非業務資料，如日誌訊息等，用自增ID沒問題，這種場景不需要使用ID去檢索。

2，業務上使用的標識欄位不要用自增ID，因為自增ID不可控，資料遷移和合並困難。

3，業務上使用的主鍵如果不想用guid，可以自行生成，有很多流行的主鍵生成演算法可以借鑑。 無非是: 空間（產生主鍵的機器標識，如mac地址、主機板序列號等）+ 時間（時間戳，如unix epoch）+ 種子（遞增序列，取值範圍看生成的併發數）。這樣即便是在不同的伺服器上同時生成，也不會發生衝突。

最好是自己生成全域性唯一ID。生成方法有

生成的ID剛好是一個long型別所能表示的數字範圍。一句話解釋：一個擁有1024臺伺服器（10個bit用於表示機器id，2的10次方就是1024）的叢集，可以連續69年(41個bit用於表示時間，2的41次方表示的毫秒數就是69年)生成自增唯一ID，每臺機每毫秒可以生成4096個ID（12個bit的序列號，2的12次方就是4096）。

Snowflake演算法有一部分內容是【機器id】，因此他的一個缺點就是【需要為每個使用的服務指定編號(0至1024編號)】,不過這個也不是什麼大問題。