sql_require_primary_key参数仅控制DDL操作中是否强制定义主键，不影响查询执行计划；开启后CREATE/ALTER表无主键即报错，但SELECT等DML语句仍由优化器自主选择索引，与该参数无关。

sql_require_primary_key 参数和“强制使用主键索引”完全无关，它只控制建表或修改表结构时是否必须定义主键，不参与查询执行计划的索引选择。

你改了这个参数，SELECT ... WHERE id = 123 该走全表扫描还是走全表扫描，一点不会变。

---

sql_require_primary_key 的真实作用

• 默认值：OFF（MySQL 8.0.19+ 引入，但非默认启用）
• 开启后（SET sql_require_primary_key = ON）：
  • CREATE TABLE 必须显式声明 PRIMARY KEY，否则报错 ERROR 3750 (HY000): Unable to create or change a table without a primary key
  • ALTER TABLE ... ADD PRIMARY KEY 类操作不受影响
  • 对已有表的任何 SELECT / UPDATE / DELETE 查询行为零影响
• 它是 DDL 约束，不是查询提示，也不改变优化器逻辑

---

真正能“强制走主键索引”的方法只有这些

• FORCE INDEX (PRIMARY)
  最直接有效：MySQL 必须用主键索引，哪怕代价更高。适用于明确知道主键范围小、过滤强的场景。
  示例：SELECT * FROM users FORCE INDEX (PRIMARY) WHERE id BETWEEN 100 AND 200;

• USE INDEX (PRIMARY)
  仅建议，优化器仍可无视。适合试探性验证主键是否比当前选中的索引更优。

• MySQL 8.0+ 的优化器 Hint（更现代、更细粒度）
  SELECT /<em>+ INDEX(users PRIMARY) </em>/ * FROM users WHERE id = 42;
  优势：支持嵌套查询、多表 hint，且语法更标准；缺点：需注释风格，易被 ORM 或中间件剥离。

• 避免让主键索引失效的写法（常被忽略）

  

  MySQL

  编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

  下载
  • 条件列类型不匹配：WHERE id = '123'（id 是 INT）→ 触发隐式转换，索引失效
  • 对主键列使用函数：WHERE ABS(id) = 123 → 索引无法下推
  • OR 连接不同列条件（尤其含非主键列）可能让优化器放弃主键

---

为什么有人误以为 sql_require_primary_key 能“强制走索引”

• 名字带 “primary_key”，容易望文生义
• 开启后表几乎都有主键，于是观察到“查询变快了”——其实是主键存在本身带来的好处（如聚簇索引、避免全表扫描），而非该参数在运行时干预了执行计划
• 没做 EXPLAIN 对比，把相关性当因果

---

真正要确认主键索引是否生效，唯一可靠方式是：

EXPLAIN SELECT ...
看输出中 key 列是否为 PRIMARY，type 是否为 const / range / ref，且 Extra 不含 Using filesort 或 Using temporary（除非业务真需要）。

参数本身不参与执行，它只管“你建表时老不老实”。