说实话，数据库这活儿，十个人里有八个人栽在主键上。不是不会写那行SQL，而是压根没想明白为什么要加、加了之后会带来什么。我见过太多项目，表建得跟菜地似的，主键随手一丢，结果数据一多，查询慢得像蜗牛爬，关联表的时候更是惨不忍睹。今天咱们就把这事儿掰开揉碎了聊，从最基础的语法到背后的设计思路，一次给你讲透。
先解决最直接的问题：怎么加主键。如果你在建表的时候就想好了，那最简单，直接在字段后面跟一句PRIMARY KEY就行。比如你要建一张用户表，用户ID肯定是主键，写法就是CREATE TABLE users (userid INT PRIMARY KEY, username VARCHAR(50))。就这么一行，完事儿。但你要是表已经建好了，半路想加主键，那也简单，用ALTER TABLE语句。比如你的users表已经存在，但没有主键，那就写ALTER TABLE users ADD PRIMARY KEY (userid)。注意啊，这个字段里的值必须是唯一的，而且不能有NULL，不然数据库会直接报错，跟你翻脸。
但这里有个坑，很多人踩了还不自知。你加主键的字段，如果本身是业务字段，比如手机号、身份证号，看起来挺合适，实际上隐患很大。业务字段是会变的，手机号可能换，身份证号虽然是唯一的，但你确定你能拿到所有用户的身份证？更别提有些系统里，同一张表的数据来源可能都不止一个渠道。所以业内有个不成文的规矩：主键尽量用自增整数，或者用UUID这类无业务含义的标识符。你想想，一个自增ID，从上到下排下去，数据库索引好建，查询走索引快，多好。要是用手机号做主键，哪天运营商回收了号码，你再分配给新人，之前的记录全乱了。
说完怎么加，咱们得聊聊加完之后会发生什么。主键这东西，本质上就是给每行数据发一个独一无二的身份证号。有了它，数据库才能快速定位到某一行。你想想，没有主键的表，就像一本没有页码的书，你想翻到某一页，只能从头一页页翻，那效率能高吗？加上了主键，数据库会自动为这个字段建一个聚簇索引，数据物理存储的顺序也跟着主键走。这就是为什么你按主键查询的时候，速度飞快，因为数据库直接就知道该去哪儿找。
不过，我得提醒你一句，主键不是万能的，选错了反而添乱。比如你用UUID当主键，随机生成的字符串，插入的时候数据库得频繁调整索引结构，性能反而下降。如果你用的是自增整数，那插入是顺序的，效率最高，但风险是别人能通过ID号猜到你的数据量，比如你今天注册用户ID是100，明天是150，人家就知道你一天增加了50个用户。所以有些敏感系统会故意用复杂的ID生成策略，这就是在性能和隐私之间做取舍，没有绝对的对错。
实际操作的时候，还有个细节特别容易翻车——多表关联。你给订单表加主键，那订单明细表里的外键就得指向这个主键。如果两边类型不一致，比如一边是INT，一边是VARCHAR，关联查询的时候数据库得做隐式转换，性能直接掉一截，甚至可能查不出数据。所以设计主键的时候，你得把整个系统的表结构都想清楚，别只顾着眼前这一张表。这就像盖房子，地基歪一点，楼层越高越危险。
还有一类情况，你可能得建复合主键，就是两个字段合起来当主键。比如一个选课表，学生ID和课程ID，单独任何一个都不唯一，但合起来就唯一了。这时候你可以这么写：ALTER TABLE enrollments ADD PRIMARY KEY (studentid, courseid)。但复合主键有个麻烦，如果你后续想改其中一个字段，或者要加个自增ID，就得先把原来的主键删掉再重建，流程繁琐不说，还容易出错。所以我一般建议，除非业务逻辑特别强，否则还是用个自增ID当主键，把复合唯一约束用UNIQUE KEY来做，灵活得多。
咱们说说主键的维护，这步很多人忽略了。有些项目上线后，发现主键不够用了，比如自增INT的上限是21亿多，听着挺多，但如果是日志表，一天几百万条，几年就满了。到时候你就得扩容，把字段类型从INT改成BIGINT，那可不是改个字段类型那么简单，索引要重建，数据要迁移，搞不好还得停机维护。所以，建表的时候就得有远见，数据量大的表，直接用BIGINT起步，省得以后折腾。另外，定期检查主键的使用情况，看看有没有碎片化严重的问题，该重建索引就重建，别等系统卡到不行了才想起来。
写到这儿，该说的差不多都说了。从怎么加主键的语法，到选字段的坑，再到复合主键的取舍，是维护的远见，其实核心就一句话：主键是表的灵魂，选对了，系统跑得又快又稳；选错了，后面全是还债的日子。你建表之前，多花十分钟想想主键怎么设计，比后面加班加点调优强一百倍。数据库这行，功夫都在细节里，主键看似基础，实则是整个数据架构的定海神针。
