Concevoir des clés primaires et des clés de substitution
Apprenez comment le choix entre des clés naturelles, des clés de substitution séquentielles et des UUID influe sur la taille des index, le débit d’insertion et les performances globales des requêtes.
Concevoir des clés primaires et des clés de substitution est une leçon PostgreSQL Performance & Query Optimization gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage PostgreSQL Performance & Query Optimization, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours PostgreSQL Performance & Query Optimization comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
Natural vs Surrogate Keys
A natural key is a real-world attribute (e.g. email). A surrogate key is a meaningless generated value (e.g. an integer id). Surrogate keys stay stable even when business data changes.
Why Key Choice Affects Performance
The primary key is referenced by every foreign key and many indexes. A wide key bloats all of those structures, increasing disk usage and cache pressure. Narrow keys keep indexes small and fast.
Sequential Integer Keys
The classic choice is a monotonically increasing integer. New rows append to the end of the B-tree, minimizing page splits and keeping inserts fast.
CREATE TABLE orders (
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
total NUMERIC
);IDENTITY vs serial
Prefer the SQL-standard GENERATED ALWAYS AS IDENTITY over the older serial pseudo-type. It is cleaner and avoids ownership quirks with the underlying sequence.
The UUID Temptation
UUIDs are great for distributed systems because clients can generate them. But random UUIDs (v4) scatter inserts all over the index, causing page splits and poor cache locality.
CREATE TABLE events (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
payload JSONB
);Time-Ordered UUIDs
If you need UUIDs, prefer a time-ordered variant (UUIDv7) so values increase roughly with time. This restores the append-friendly behavior of sequential keys while keeping global uniqueness.
Key Width Matters
A BIGINT is 8 bytes; a UUID is 16 bytes. Every secondary index stores the primary key, so wider keys multiply storage across all of them. Measure the impact.
SELECT pg_size_pretty(pg_relation_size('orders_pkey'));Composite Primary Keys
Sometimes the natural key spans two columns, such as (order_id, line_no) in a detail table. Keep composite keys narrow and put the most selective column first.
CREATE TABLE order_lines (
order_id BIGINT,
line_no INT,
PRIMARY KEY (order_id, line_no)
);Foreign Keys Inherit the Cost
Every child row stores a copy of the parent key. A 16-byte UUID parent key makes a million-row child table 8 MB larger than an 8-byte integer would. Multiply by every referencing table.
Choosing in Practice
Guidelines:
- Default to BIGINT IDENTITY for single-database apps
- Use time-ordered UUIDs when clients must generate ids or you shard
- Avoid random v4 UUIDs as primary keys on hot insert paths
- Keep composite natural keys short
Indexing the Foreign Key Side
Whatever key you pick, always index the child's foreign key column. Without it, deleting or updating a parent forces a full scan of the child table to check references.
CREATE INDEX idx_order_lines_order
ON order_lines (order_id);Quick Check
Test your key-design knowledge.
Recap
You learned key design for performance:
- Surrogate keys stay stable; natural keys can change
- Narrow keys shrink every index and foreign key
- Sequential BIGINT IDENTITY inserts are cheap
- Random v4 UUIDs scatter inserts; prefer time-ordered UUIDs
- Keep composite keys short and selective-first
Apprends SQL avec un tuteur IA — gratuit
Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.
- Cours
- 22
- Leçons
- 88
Questions Fréquemment Posées
La leçon « Concevoir des clés primaires et des clés de substitution » est-elle gratuite ?
Oui — le texte complet de « Concevoir des clés primaires et des clés de substitution » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours PostgreSQL Performance & Query Optimization, passe à CoddyKit PRO. Le cours PostgreSQL Performance & Query Optimization comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Concevoir des clés primaires et des clés de substitution » ?
Apprenez comment le choix entre des clés naturelles, des clés de substitution séquentielles et des UUID influe sur la taille des index, le débit d’insertion et les performances globales des requêtes. Tu pratiques PostgreSQL Performance & Query Optimization avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer PostgreSQL Performance & Query Optimization ?
Aucune expérience préalable n'est requise. PostgreSQL Performance & Query Optimization sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.
Combien de temps prend la leçon « Concevoir des clés primaires et des clés de substitution » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon PostgreSQL Performance & Query Optimization ?
Oui. Chaque leçon PostgreSQL Performance & Query Optimization inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Compromis entre normalisation et dénormalisation
- Choisir les types de données appropriés
- Partitionner les grandes tables
- Concevoir des clés primaires et des clés de substitution