数据库设计 - 社交应用的mysql表主键该怎么定义？

问题描述

目前在设计一个移动社交应用，涉及的内容有：用户注册、发布图文分享、发表评论等等。

我已经定义好相关的表及其主键，比如用户信息表（USER_INFO-->USER_ID）、图文分享表（SHARE_INFO-->SHARE_ID）、评论表（COMMENT_INFO-->COMMENT_ID）,那么请教下这些表的主键我应该怎么定义呢，是使用mysql的自增主键，还是程序自定义一套业务主键？

目前我的设计思路：自定义了一个表，存放每个数据表的表名和当前的表的最大值（如表名：TABLE_MAX，字段：TABLE_NAME、MAX_VALUE），新增数据时，为了防止并发，使用存储过程获取下一个主键，然后数据表入库，但是这么做的话就使用到了数据库的存储过程的特性，感觉不是很好，代码如下：

CREATE DEFINER=`root`@`localhost` PROCEDURE `generate_table_id`( in tn varchar(40), out cv int )BEGIN UPDATE table_id_generate SET CURRENT_VALUE = CURRENT_VALUE + 1 WHERE TABLE_NAME=tn; SELECT CURRENT_VALUE into cv from table_id_generate WHERE TABLE_NAME=tn;END

另外我看到的segmentfault的问题的url是这样的：https://segmentfault.com/q/10...，知乎的问题url是这样的：https://www.zhihu.com/questio...，其中的某个答案的url是：https://www.zhihu.com/questio...，这种url路径，我相信应该是restful风格，那些数字应该是相应问题或者回答的主键，请问这种数字类的主键是怎么生成的？数据库是用varchar还是int，像sf这么长的估计还不能用int。

请高手指教，谢谢！

问题解答

其实不应该自己去维护一套类似自增字段的逻辑,sf这个应该是在自增id的基础上加了一个前缀,其实没有多大必要,我理解的好的url规范应该是通俗易懂的,这是我们家的url,尽可能使用自增id做主键,能用整型的不要用字符型,字符型会减慢查询速度增大存储空间

自增ID以后不好分表不好水平扩展。

mysql主键最好不用字符型，字符型会导致页断裂，不是顺序写，影响性能不同的业务设计不同的主键生成规则比如说帖子分类表，顶多几十个直接用mysql自增；又比如说帖子表，在可以预见的将来可能会增加得很快，以后会设计到分表，分库等，这种业务最好程序维护主键生成不要用自增