1、Innodb引擎是索引組織表，所謂索引組織表就是資料的插入順序是根據主鍵的順序來的，如果設定業務ID為主鍵，沒有辦法保證業務ID自增的話，那麼新資料的插入會引起行遷移，這就是為什麼很多回答中提到自增主鍵會提升插入效率。
2、Innodb引起表中所有的二級索引（非主鍵）的key值記錄的都是主鍵，所以儘量要求主鍵的欄位型別簡單，而業務開發一般會用char/varchar來設計業務ID，用varchar和int來設計主鍵，影響的不僅僅是主鍵的長度，該表上所有的索引都會變大。從SQL最佳化的角度來說，最佳化的本質是減少IO，而減少IO最直接的方法其實就是設計最簡單的欄位型別（包括索引）。
3、從運維DBA的角度來說，你們遇到過非自增主鍵，十幾億條記錄的表，要分批操作時候的絕望嗎？如果有自增主鍵，直接指定primary key操作，會大大簡化後期維護操作。當然你說可以透過updatetime欄位來操作，但是不一定所有的表都有自更新的時間戳欄位啊，而且也不一定能保證時間戳有索引啊。
4、當然你也可以說如果我的表只有幾百條資料，也不會有什麼分批操作的需求，這就跟這樣的表要不要設計索引一樣。當然考慮實際情況或者業務場景，這樣的表不設主鍵或索引也是可以接受的，但是從開發規範來說，難道我制定主鍵規範的時候只說大家根據實際需求來嗎？
所以一般的開發規範中都會要求設計自增ID為主鍵。
1、Innodb引擎是索引組織表，所謂索引組織表就是資料的插入順序是根據主鍵的順序來的，如果設定業務ID為主鍵，沒有辦法保證業務ID自增的話，那麼新資料的插入會引起行遷移，這就是為什麼很多回答中提到自增主鍵會提升插入效率。
2、Innodb引起表中所有的二級索引（非主鍵）的key值記錄的都是主鍵，所以儘量要求主鍵的欄位型別簡單，而業務開發一般會用char/varchar來設計業務ID，用varchar和int來設計主鍵，影響的不僅僅是主鍵的長度，該表上所有的索引都會變大。從SQL最佳化的角度來說，最佳化的本質是減少IO，而減少IO最直接的方法其實就是設計最簡單的欄位型別（包括索引）。
3、從運維DBA的角度來說，你們遇到過非自增主鍵，十幾億條記錄的表，要分批操作時候的絕望嗎？如果有自增主鍵，直接指定primary key操作，會大大簡化後期維護操作。當然你說可以透過updatetime欄位來操作，但是不一定所有的表都有自更新的時間戳欄位啊，而且也不一定能保證時間戳有索引啊。
4、當然你也可以說如果我的表只有幾百條資料，也不會有什麼分批操作的需求，這就跟這樣的表要不要設計索引一樣。當然考慮實際情況或者業務場景，這樣的表不設主鍵或索引也是可以接受的，但是從開發規範來說，難道我制定主鍵規範的時候只說大家根據實際需求來嗎？
所以一般的開發規範中都會要求設計自增ID為主鍵。