默认只显示问题 —— 先自己在心里答一遍，再展开对答案。答不上来就标「不会」，下次抽认卡会先抽它。Only the question shows by default. Answer it in your head first, then open the answer. Mark the ones you miss; the flashcard round puts those first.
0 / 105道自评过self-assessed
0会Got it0模糊Shaky0不会No idea105还没做Not seen
正在读这台浏览器里的标记…Reading your marks from this browser…
标记不是打分，是给下一轮排队Marks are a queue, not a score
标「不会」的题会排到抽认卡最前面，标「会」的进低频池排最后。所以别客气 —— 觉得答得磕磕巴巴就标「模糊」。准备好了就去抽认卡。“No idea” jumps to the front of the next round; “got it” drops to the back. So be honest — if it came out shaky, mark it shaky. Then go run a flashcard round.
找一道题Find one按方向、掌握状态筛Filter by topic and mark数据库Databases
In one line: relational means you define the schema up front, relate rows with JOINs, and lean on consistency; non-relational means a flexible shape, data laid out for the queries you actually run, and easier scale-out.
Relational (MySQL, PostgreSQL)
Non-relational (MongoDB, Redis)
Shape
Tables, rows, columns — fixed schema
Documents / key-value / graph — flexible schema
Relating data
JOIN
Nested documents, or you stitch it in the app
Transactions
ACID is the whole point
Present but weaker (MongoDB 4.0+ has multi-document)
Scaling
Mostly vertical; sharding is painful
Mostly horizontal — add machines
Good for
Complex relationships and strong consistency — orders, ledgers, inventory
Shifting shapes, heavy read and write, one query pulling a whole blob — logs, content, sessions, caches
The right way to talk about choosing:“Look at the shape of the data and the access pattern.”
Everything one query needs always travels together (an article and all its paragraphs) → document store fits.
The same data gets related from many angles (users × orders × products × coupons) → relational fits, because a document store either duplicates it or makes you JOIN in application code.
You need transfer-money-level consistency → relational.
Follow-up: “Is MongoDB being schema-less an advantage?” — it cuts both ways. You move faster early on, but the constraints move into your application code, and given enough time one collection holds three generations of document shapes. Which is why teams reach for something like Mongoose to put a schema back on top. “Is the line still clear today?” — it is blurring. PostgreSQL’s jsonb stores documents and indexes them, so “start on Postgres, use jsonb where you need a document” is a very common real-world answer.
In one line:a primary key uniquely identifies a row in its own table; a foreign key points at another table’s primary key, expressing the relationship and keeping the reference valid.
Primary key
Foreign key
Job
Identifies one row
Points at another table’s primary key
Unique?
Must be
Can repeat (one user, many orders)
Nullable?
No
Yes — meaning “not linked yet”
How many per table
One (possibly composite, several columns)
Many
Index
Created for you
Not always — MySQL does, PostgreSQL does not
That last row is the bonus point. In PostgreSQL a foreign key column gets no index automatically, and both JOINs and cascading deletes need one — forgetting to add it by hand is a very common performance bug.
The real value of a foreign key is referential integrity: the database refuses to insert an order pointing at a user who does not exist, and refuses to delete a user who still has orders. That is consistency the database holds for you, so you do not write the check in application code.
They will ask about delete behaviour — know these three:
RESTRICT / NO ACTION — refuse the delete while references exist (the default, and the safest)
CASCADE — delete the children along with it (convenient and dangerous; deleting one user can take tens of thousands of rows with it)
SET NULL — null out the child’s foreign key (fits “the author is gone, keep the article as anonymous”)
Another follow-up: “Auto-increment id or UUID?” — auto-increment is short, gives good index locality, but leaks how much data you have and collides when you shard. UUID is globally unique, good for distributed systems and for generating ids on the client, but longer, and random inserts are unkind to a B+ tree index. The middle ground is ULID or UUIDv7 — time-prefixed, so they sort — and saying that makes you sound like you have done this before.
Text建表时的三个要点示意Illustrative
1CREATE TABLE users (
2 id BIGSERIAL PRIMARY KEY, -- 主键：唯一、非空、自动建索引
3 email TEXT UNIQUE NOT NULL -- 唯一约束 ≠ 主键
4);
5
6CREATE TABLE orders (
7 id BIGSERIAL PRIMARY KEY,
8 user_id BIGINT NOT NULL
9 REFERENCES users(id)
10 ON DELETE RESTRICT, -- 还有订单就不许删用户
11 total NUMERIC(10,2) NOT NULL
12);
13
14-- PostgreSQL 不会自动给外键列建索引，JOIN 会慢
15CREATE INDEX idx_orders_user_id ON orders(user_id);
1CREATE TABLE users (
2 id BIGSERIAL PRIMARY KEY, -- primary key: unique, not null, indexed automatically
3 email TEXT UNIQUE NOT NULL -- a unique constraint is not the same as a primary key
4);
5
6CREATE TABLE orders (
7 id BIGSERIAL PRIMARY KEY,
8 user_id BIGINT NOT NULL
9 REFERENCES users(id)
10 ON DELETE RESTRICT, -- a user with orders left cannot be deleted
11 total NUMERIC(10,2) NOT NULL
12);
13
14-- PostgreSQL does not index a foreign key column for you, and the JOIN gets slow
15CREATE INDEX idx_orders_user_id ON orders(user_id);
99 道来自面试题库 #269–#387；TypeScript 深度那 6 道是 DrillLab 自出的（senior 补强，卡片上有标注）。答案都是 DrillLab 写的，所以讲解里的代码块一律标「示意」。每道题都能点回它出处的那一节课。99 questions come from the interview bank (#269–#387); the 6 TypeScript deep-dive ones are DrillLab-made (marked on the card). All answers are written by DrillLab, so every code block here is labelled “demo”. Each card links back to the lesson it came from.