mysql: Zahl-ID vs. Mix-ID

[Encoder]

Ich möchte aber vermeiden, dass man anhand der URL auf die Position innerhalb der Datenbank schließen kann.

Schätzungsweise um nicht rauszugeben in welcher Reihenfolge sich die User angemeldet haben?
So schlimm wäre das aber vielleicht auch nicht. Und du könntest ja auch eine zufällige ID vergeben, sofern du eine neue zufällige ID ohne zu großen Aufwand (sprich: etliche Versuche und Prüfungen) bilden kannst. Vielleicht wäre das ja eine Idee.

Oder du berechnest die zufällige ID aus dem Identity, so dass du das auch wieder zurück rechnen kannst. public-key Verfahren gehen in diese Richtung. Aber man kann auch selber damit experimentieren, es geht ja hier nicht um zu schützende Passwörter, die unbedingt unknackbar sein müssen.

Was genau spricht eigentlich dagegen, von begin an eine userId der Art "72H2H.J8_F6" zu verwenden und diese auch als PRIMARY KEY festzulegen.

Aus meiner Sicht nichts. Das einzige wahrscheinlich, du hast hier einen String der im Vergleich zu einem int etwas komplizierter zu vergleichen ist. Aber obs das wirklich rausreißt?

Ist das aber auch performant?

Evtl. performanter als jedes mal die Umsetzung zu machen.
Oder hast du die "richtige" ID in einer Session gespeichert? Dann machst du die Umsetzung nur ein einziges mal bei der Anmeldung, alle weiteren Aufrufe erfolgen dann sowieso über die aus der Session stammende tatsächliche ID.