嗯，我对数据库架构了解不多，但我真的不明白CTO的想法，但他坚持使用字符作为 我们使用的所有表的主键的列类型。 但是主键看起来仍然像这样 -> 1,2,3...等。它们是数字。 所以我使用 integer + auto_increment 来合成 PK
但是 CTO 说这很糟糕，因为他不能在 PK 上使用 LIKE 条件发出查询？!
- 使用字符进行 PK 是否可以，尤其是当您的 PK 是数字时？
- 在PK上使用like condition是否正确？
PS - 所以不是自动递增/触发，序列 CTO 发出选择查询获取 表中的最大值，他加 1，然后将该值转换为字符串 然后存储它。
编辑
感谢您的帮助 !但我需要让他相信这将是一场灾难。
我只被告知这(在这种情况下字符 4 PK)是个坏主意。
他的论点是……
1.角色PK不会占用太多空间。
2. 如果您使用 int 类型 PK，数据库查询优化器将不得不重新读取您的查询
因为你必须发出像
这样的东西
“从名字像'somename'的员工中选择*
和
从 id = 6 的员工中选择 *。
因为 where 子句改变了。
他强烈主张我们使用的是
“从@columnName 喜欢@value 的员工中选择*”
他说这样，查询优化器会运行得更好。
我如何证明或给他一些正当理由让他改变主意？
谢谢你:)
最佳答案
您的 CTO 做出错误决定的原因有很多；让我介绍一些:
正如您所注意到的，您必须采取额外的步骤来生成新的自动递增 PRIMARY KEY。这是一种计算成本，而且还会增加它在未来某个时间点应用不一致的可能性。
一旦超过 4 个字符，字符将占用更多磁盘空间(换句话说，12345 比“12345”的存储成本低得多)。
如果您在主键上使用聚集索引(这是某些 RDBM 的默认设置)，则字符排序与整数排序完全不同:
字符:1、10、101、11、12、13、14、15... 数字:1,2,3,4...
如果您将最大数值作为字符插入，那么您就是在粉碎索引。不是无法克服的问题，而是更多浪费的计算能力需要清理。
至于你关于在 PRiMARY KEY 上使用 LIKE 的第二个问题，我想不出你会这样做的原因；如果您需要 LIKE 的功能，通常是因为您已经为用作 PRIMARY KEY 的列分配了某种重要性，这意味着您需要将其公开给最终用户。如果是这种情况，那么我会使用代理自动递增数字主键，并向用户公开某种形式的 ID。
关于database - 使用主键值字符 "1"而不是 int 值 1，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14189306/