Merancang Kunci Utama dan Kunci Pengganti
Pelajari cara pilihan antara kunci alami, kunci pengganti berurutan, dan UUID memengaruhi ukuran indeks, laju penyisipan, serta kinerja kueri secara keseluruhan.
Merancang Kunci Utama dan Kunci Pengganti adalah pelajaran PostgreSQL Performance & Query Optimization gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar PostgreSQL Performance & Query Optimization, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus PostgreSQL Performance & Query Optimization mencakup 4 pelajaran total.
Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.
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
Belajar SQL dengan tutor AI — gratis
Tulis dan jalankan kode asli di browser kamu, dapatkan bantuan instan dari tutor AI 24/7, dan lanjutkan di mana kamu tinggalkan di web atau aplikasi.
- Kursus
- 22
- Pelajaran
- 88
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Merancang Kunci Utama dan Kunci Pengganti” gratis?
Ya — teks lengkap “Merancang Kunci Utama dan Kunci Pengganti” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus PostgreSQL Performance & Query Optimization, upgrade ke CoddyKit PRO. Kursus PostgreSQL Performance & Query Optimization mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Merancang Kunci Utama dan Kunci Pengganti”?
Pelajari cara pilihan antara kunci alami, kunci pengganti berurutan, dan UUID memengaruhi ukuran indeks, laju penyisipan, serta kinerja kueri secara keseluruhan. Kamu berlatih PostgreSQL Performance & Query Optimization dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai PostgreSQL Performance & Query Optimization?
Tidak diperlukan pengalaman sebelumnya. PostgreSQL Performance & Query Optimization di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.
Berapa lama pelajaran “Merancang Kunci Utama dan Kunci Pengganti” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran PostgreSQL Performance & Query Optimization ini?
Ya. Setiap pelajaran PostgreSQL Performance & Query Optimization menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- Pertukaran Normalisasi dan Denormalisasi
- Memilih Jenis Data yang Tepat
- Mempartisi Tabel Besar
- Merancang Kunci Utama dan Kunci Pengganti