數(shù)據(jù)庫主鍵相關(guān)問題有哪些

1 是否每張表都應(yīng)該有自增主鍵？

不一定自增主鍵可以加快行的插入速度，對于表的空間利用上有優(yōu)勢，碎片化不明顯。

但是對一些內(nèi)容，如根據(jù)uid的查詢非常頻繁的，而且比較集中的，那如果不用自增主鍵，而是使用uid+id作為復(fù)合主鍵，那查詢效率會上去，但插入和碎片化就會增加。但如果數(shù)據(jù)庫的存儲類型是ssd，那這個(gè)問題就不存在了。

所以，大部分情況來看，表有自增主鍵是正確的。

2 自增主鍵是否具有業(yè)務(wù)上的唯一性？

不一定

單表結(jié)構(gòu)下，是的。

多表情況下，不一定，需要一定的策略，如設(shè)定不同的后綴，相同的間隔等。

3 自增主鍵是否可以牽扯到業(yè)務(wù)？

不建議這樣做。

如：表可以有自增主鍵，表內(nèi)是具有唯一性的。在根據(jù)id查詢和更新的時(shí)候，可以簡化操作。但一般來說，和業(yè)務(wù)上存在關(guān)系，并且需要唯一性的時(shí)候，應(yīng)該由業(yè)務(wù)自主去維護(hù)，如使用格式或算法，hash生成等方式。

4 業(yè)務(wù)維護(hù)的主鍵，怎樣在多表的情況下保持唯一性？

維護(hù)自增鍵區(qū)間段，服務(wù)器每次取其中的一段，樂觀鎖更新。這個(gè)需要額外的表或策略來維護(hù)這個(gè)字段。

基于算法A，固定時(shí)間前綴，如：yyyyMMddHHmmss+表數(shù)mod值+隨機(jī)數(shù)，通過位數(shù)的增加，來降低沖突的可能性。表字段存在唯一性約束（但有時(shí)候這個(gè)約束并不可靠）插入時(shí)若拋出重復(fù)字段值異常，則重新生成插入。

基于算法B，固定時(shí)間前綴，如：yyyyMMddHHmmss+固定位數(shù)碰撞自增值N+隨機(jī)數(shù)。不需要通過位數(shù)的增加來降低沖突的可能性。當(dāng)插入拋出重復(fù)字段值異常時(shí)，N++，重新插入，直到不再沖突為止。此后固定使用N作為中綴，并且N緩存于服務(wù)器，重啟后繼續(xù)使用此中綴。若出現(xiàn)重復(fù)異常，再次N++執(zhí)行相同操作即可。N的mod值這些就不用故意提起啦。

基于中綴管理，即上報(bào)中綴到中心服務(wù)器，可以理解有地方緩存了服務(wù)器的id關(guān)系，動態(tài)分配中綴。

其他方法，還有很多，也沒有用過，不贅述了。算法B，簡單，通信少，而且碰撞次數(shù)有限。算法A，存在無限次數(shù)的碰撞，盡管百分比非常非常低。但是在高并發(fā)的情況下，初始化的時(shí)候，算法B會比算法A來得更狂風(fēng)暴雨一些。

區(qū)間段和中綴管理，都引入了中心節(jié)點(diǎn)的概念，依賴性比較強(qiáng)，但相對可靠，業(yè)界更為通用的實(shí)現(xiàn)方式。