我正在使用BIGINT来保存一个从1开始递增的id号。在一个表中，这将是主键，当然，它将是唯一的;在其他表中，它将是一个外键。我试图弄清楚如果我设置PACK_KEYS，这个键是否会“打包”，因为会有很多前导零。
我很难理解table creation中PACK_KEYS表选项的MySQL文档。以下是文档的相关引用：
当打包二进制数字键时，MySQL使用前缀压缩：
每个密钥都需要一个额外的字节来表示该字节的数量 上一个键与下一个键相同。
指向行的指针直接以高字节优先顺序存储 在关键之后，改善压缩。
这意味着如果连续两行有 许多相等的键， 所有后面的“相同”键通常只占用两个字节（包括 指向行的指针 。将此与普通情况相比较 以下键占用storage_size_for_key + pointer_size（其中 指针大小通常是4）。相反，您将获得显着的收益 来自前缀压缩只有你有许多数字 相同。如果所有键完全不同，则每个键使用一个字节 key，如果键不是可以具有NULL值的键。 （在这种情况下， 打包密钥长度存储在用于标记的相同字节中 如果一个键是NULL。）
他们在连续两行的“ 许多相等的键上失去了我， 所有后面的“相同”键通常只占用两个字节（包括 指向行的指针） “。根据我想要完成的事情，有人可以为我解释上述文档吗？例如，对于主键，不会有任何”等号键“ - 在两个连续的行上，连续三行，在100个非连续的行上......或者他们正在驾驶的任何行。
谢谢！
答案 0 :(得分：1)
您可能不需要PACK_KEYS。我看到你正在为你的PK使用BIGINT。你最终会在这张表中看到多少行？你存储什么样的数据？你打算如何检索/报告它和多久？这些是我在使用此功能之前首先考虑的事情。
如果我正确地阅读了该文档，它基本上说明如果你有两个连续的长PK记录说：
PK-x：1002350025789001 PK-y：1002350025789002
使用PACK_KEYS，PK-y现在变成类似“[指向PK-x的指针] 2”
这基本上是一种说PK-2与PK-1相同的方式，除了最后一个数字是2 ...而不必重写/存储相同的refix /前面的数字。
这样做的好处很可能只在你处理非常长的PK并且主要是存储/内存增加时实现，但是我认为整体性能的成本可能会或可能不会明显，这取决于如何表获得的访问负载很多。
可能不值得......我从来没有使用过这个功能，而且我在MySQL上构建了一些非常繁重的应用程序。
希望这会有所帮助。
祝你好运