TEXT字段不能直接做主键，因为InnoDB不允许对TEXT/BLOB创建全字段索引，而主键必须是完整、可比较的聚簇索引；其根本限制在于TEXT类型不支持长度声明（如TEXT(100)非法），且前缀索引不适用于主键或UNIQUE约束；正确做法是添加自增ID或改用VARCHAR，而非强行使用TEXT。
TEXT字段不能直接做主键，因为MySQL不支持无长度限制的索引
MySQL报错 BLOB/TEXT column 'name' used in key specification without a key length 的根本原因不是“TEXT不能当主键”这个说法本身绝对成立，而是：InnoDB不允许对TEXT/BLOB类字段创建**全字段索引**，而主键本质就是一个强制的、完整的聚簇索引。由于TEXT内容可能长达4GB（如LONGTEXT），MySQL无法为其生成稳定、可比较、可排序的完整索引项——它连读取全部内容都可能触发额外I/O，更别说在B+树里维护了。
- 所有TEXT子类型（
TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT）和BLOB类（TINYBLOB等）都受此限制 - 错误常出现在建表时直接写
PRIMARY KEY (content)，其中content是TEXT类型 - 也出现在ALTER TABLE时试图给已有TEXT字段加主键或UNIQUE约束
- 哪怕字段当前只存了10个字符，只要类型是TEXT，就过不了语法校验
为什么加长度前缀（比如TEXT(100)）也不行？
你可能会想：“那我写成 content TEXT(100) 不就行了吗？”不行。TEXT(100) 是非法语法，MySQL会直接报错 Incorrect column specifier for column 'content'。TEXT类型**不接受括号内指定长度**——这和VARCHAR(100)有本质区别。它的长度上限由类型本身决定（如TEXT最大65535字节），但索引时只能显式声明前缀长度，例如 INDEX(content(100))，但这仅适用于普通索引，且不能用于主键或UNIQUE约束。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 主键/UNIQUE要求值完全可比较、可唯一判定，前缀截断破坏了这个前提
-
INDEX(content(100))合法，但PRIMARY KEY(content(100))语法错误 - 即便允许，用前100字符做主键也会导致语义错误：两个不同全文只在第101位起不同，会被判为重复
替代方案不是“绕过”，而是按数据语义重新设计
真正可行的解法不是强行让TEXT当主键，而是回归业务本质：主键应该是一个轻量、稳定、无业务含义的标识符。如果你的表逻辑上需要靠一段文本内容来唯一识别一条记录，大概率说明这张表缺少真正的主键字段，或者那个“文本”本就不该承担标识职责。
- 优先添加自增整数列：
id INT PRIMARY KEY AUTO_INCREMENT - 若必须用字符串标识，改用
VARCHAR并设合理上限（如VARCHAR(255)），确保能覆盖所有合法输入 - 如果原始TEXT字段是URL、JSON、日志正文等纯内容字段，它本身就**不该是主键候选**，应与主键分离
- 极少数场景（如归档表按哈希去重），可用
SHA2(content, 256)生成固定长度摘要，存为CHAR(64)再设主键，但要注意哈希碰撞概率和计算开销
容易被忽略的关键点：没有主键比TEXT主键更危险
有人看到报错后干脆删掉主键，这是更大的隐患。InnoDB会在背后悄悄生成一个隐藏的6字节_rowid，但它不可见、不可引用、无法用于JOIN或UPDATE，还会导致二级索引变大、复制延迟、全表扫描等一连串问题。比起纠结“怎么让TEXT当主键”，更该问：“这个表为什么还没有一个像样的主键？”
