我最近阅读了一篇关于创建安全 php 登录系统的文章，它将逐步指导，现在我想到了为什么在这篇文章中 login_attempts 表中没有主键。我谈到的文章： 这篇文章
Create the "login_attempts" table:
CREATE TABLE `secure_login`.`login_attempts` (
`user_id` int(11) NOT NULL,
`time` VARCHAR(30) NOT NULL
) ENGINE=InnoDB
请转到第 4 步
创建一个表来存储登录尝试。
那么问题就像标题一样非常清楚。有没有我们没有任何主键的情况？
是的，但是您至少需要在列上添加一个非唯一 INDEX的列User_ID以提高查询表时的性能。
ALTER TABLE login_attempts ADD INDEX idx_userID (User_ID)
那么主键的重点是提供一些值，您可以在其中索引数据的唯一值以提高性能。在像你这样的情况下，可能没有一列是唯一的。假设您的登录是多线程的，那么虽然很小，但许多用户都有相同time的登录机会，将主键放在上面显然会拒绝某人或导致错误。如果您将主键放在上面，user_id那么您将拒绝同一用户多次尝试。
在其他情况下，例如在其他两个表之间为外键创建多对多关系，您将执行类似的操作。
免责声明我相信有人可以提供更强有力的解释，但这是我的理解。
默认情况下不需要主键——这取决于表的每一行是否必须是可识别的，例如，当它在其他表中用作外键时。
在那种特定情况下，我会说user_id就足够了 - 但它应该被索引，因为您很可能希望使用该列进行选择。
很少有不需要主键的情况。想象一下，如果您想删除特定行，如何删除正确的行？同时两次登录尝试将插入两个相同的行。
主键是一种数据库管理工具，它已成为在数据库注册表中保持信息一致性的支柱。但是，只要有一种清晰且安全的机制来保持数据库表中所需信息的一致性，就可以放弃它们。在数据库级别，您可以处理主键。但是在逻辑层面上，你必须有一种机制来帮助你区分不同的注册表，这本身就是主键的实用概念......所以基本上：如果你需要一致的信息，你永远不能处理PKs，在逻辑层面上..
在我目前的工作中，我成为了 GPS 跟踪系统的 dba，我发现所有信息都在 MySQL 中分类。我得到了这个项目“原样”，几乎没有文档，也没有起点，但有很多任务要完成。我的第一个想法是扫描数据库模式。而且我发现所有的表都缺少 PK... 甚至没有接近遵循Database Normalization Basics。它是一个没有 PK 或 FK 的关系数据库，但它是可操作的，为数千个 GPS 设备提供服务。
当然，该数据库模式极易出现故障，但公司以一种非常原始的方式保持信息适度一致。
所以...我选择重做数据库架构并将所有信息迁移到基于自动增量 PK、约束和完整性触发器的新规范化架构，开发用于处理所有数据库数据的 MVC 应用程序，我非常喜欢挑战：我的第一个专业项目。
作为我个人经验的结论。主键是保持信息一致、真实和有条理的标准指南。您可以随时丢弃它们，但使用它们将为您节省大量完全不必要的设计和实现工作。