Home/ Questions/Q 9002319
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-16T00:33:18+00:00

I am using a BIGINT to hold an id number that will increment from

  • 0

I am using a BIGINT to hold an id number that will increment from 1. In one table this will be the Primary Key and will, of course, be unique; in other tables it will be a foreign key. I’m trying to figure out whether this key will be “packed” if I set PACK_KEYS, since there will be a lot of leading zeroes.

I’m having difficulty understanding the MySQL doc for the PACK_KEYS table option in table creation. Here is the relevant quote from the doc:

When packing binary number keys, MySQL uses prefix compression:

  • Every key needs one extra byte to indicate how many bytes of the
    previous key are the same for the next key.

  • The pointer to the row is stored in high-byte-first order directly
    after the key, to improve compression.

This means that if you have many equal keys on two consecutive rows,
all following “same” keys usually only take two bytes (including the
pointer to the row). Compare this to the ordinary case where the
following keys takes storage_size_for_key + pointer_size (where the
pointer size is usually 4). Conversely, you get a significant benefit
from prefix compression only if you have many numbers that are the
same. If all keys are totally different, you use one byte more per
key, if the key is not a key that can have NULL values. (In this case,
the packed key length is stored in the same byte that is used to mark
if a key is NULL.)

They’ve lost me with “many equal keys on two consecutive rows,
all following “same” keys usually only take two bytes (including the
pointer to the row)“. Can someone interpret the above doc for me, in light of what I’m trying to accomplish? E.g., for a primary key there won’t be ANY “equal keys” – on two consecutive rows, on three consecutive rows, on 100 non-consecutive rows… or whatever they’re driving at.

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Chances are you do not need PACK_KEYS. I see you are using BIGINT for your PK. How many rows are you looking at having in this table eventually?? What kind of data are you storing? How do you intend to retrieve/report on it and how often?? These are things I would consider first before using this feature.

    If I read that documentation correctly, it’s basically stating that if you have two consecutive records with long PKs say:

    PK-x: 1002350025789001
    PK-y: 1002350025789002

    With PACK_KEYS, PK-y now becomes something like “[pointer to PK-x]2”

    It’s basically a way of saying PK-2 is the same as PK-1 except for the last number which is 2… without having to rewrite/store the same refix/preceding numbers.

    The gains from this are most likely only realized when you are dealing with very long PKs and will mostly be gains in storage/memory, however I would imagine there’s a cost to overall performance which may or may not be noticeable depending on how much access load that table gets.

    May not be worth it… I’ve never used this feature, and I’ve built some pretty heavy apps on MySQL.

    hope this helps.

    Good Luck

    • 0