Senior/Expert Database Administrator (Oracle)

Isolation level quyết định một transaction thấy được bao nhiêu thay đổi của transaction khác; mức càng cao càng an toàn nhưng càng dễ tranh chấp.

• Dirty read: đọc dữ liệu transaction khác chưa commit.
• Non-repeatable read: đọc lại cùng một dòng thấy giá trị đã đổi.
• Phantom read: chạy lại cùng điều kiện thấy thêm hoặc mất dòng.

Bốn mức chuẩn: Read Uncommitted, Read Committed, Repeatable Read, Serializable. Mặc định của PostgreSQL, SQL Server, Oracle là Read Committed; MySQL InnoDB là Repeatable Read.

Thực tế các DB dùng MVCC nên hành vi có khác lý thuyết: Repeatable Read của PostgreSQL dùng snapshot nên không gặp phantom, còn InnoDB dùng gap lock cho câu đọc có khoá.

Người phỏng vấn muốn nghe: bạn biết DB mình dùng mặc định ở mức nào và đã từng xử lý lost update, vd. bằng SELECT ... FOR UPDATE hoặc optimistic locking.

Đo trước rồi mới sửa: tìm đúng query chậm, đọc execution plan, rồi chỉnh index hoặc cách viết query.

1. Bật slow query log (MySQL) hoặc pg_stat_statements (PostgreSQL) để biết query nào tốn thời gian nhất.
2. Chạy EXPLAIN (PostgreSQL nên dùng EXPLAIN (ANALYZE, BUFFERS)) xem có full scan, ước lượng số dòng lệch nhiều so với thực tế, sort trên đĩa không.
3. Sửa theo nguyên nhân: thêm hoặc đổi composite index, bỏ hàm bọc cột, chỉ SELECT cột cần, phân trang bằng keyset thay cho OFFSET lớn.
4. Kiểm tra phía ứng dụng: lỗi N+1 query, thiếu connection pool, lock chờ lâu.
5. Cập nhật thống kê (ANALYZE) nếu planner ước lượng sai.

Người phỏng vấn muốn nghe: quy trình có số liệu trước/sau, không phải đoán rồi thêm index bừa.

Chuẩn hoá là tách dữ liệu để mỗi thông tin chỉ lưu ở một chỗ, tránh dư thừa và sai lệch khi cập nhật.

• 1NF: mỗi ô một giá trị nguyên tử, không lưu danh sách trong một cột.
• 2NF: cột không khoá phụ thuộc vào toàn bộ khoá chính, không chỉ một phần.
• 3NF: cột không khoá không phụ thuộc bắc cầu qua cột không khoá khác.

Denormalize khi đọc nhiều hơn ghi rất nhiều và JOIN trở thành điểm nghẽn: lưu sẵn comment_count trong bảng bài viết, chép customer_name vào đơn hàng để giữ đúng tên tại thời điểm đặt, hoặc dựng bảng báo cáo riêng.

Hay sai: denormalize mà không có cơ chế đồng bộ (trigger, job, event) nên số liệu lệch dần. Hãy nói rõ cái giá phải trả là logic ghi phức tạp hơn.

N+1 là khi lấy danh sách bằng 1 query, rồi mỗi phần tử truy cập quan hệ lại sinh thêm 1 query. Ví dụ duyệt 50 bài viết và in post.author.name sẽ thành 51 query.

• select_related: dùng SQL JOIN, cho quan hệ trỏ tới một object (ForeignKey, OneToOne).
• prefetch_related: chạy query riêng rồi ghép trong Python, cho quan hệ nhiều (ManyToMany, reverse ForeignKey).

posts = (Post.objects
         .select_related("author")
         .prefetch_related("tags"))

Phát hiện bằng Django Debug Toolbar, hoặc assertNumQueries trong test.

Hay sai: gọi .filter() trên quan hệ đã prefetch bên trong vòng lặp. Lệnh đó tạo query mới và bỏ qua dữ liệu prefetch; dùng Prefetch(..., queryset=...) để lọc ngay từ đầu.

Context manager đảm bảo việc "mở" và "dọn dẹp" luôn đi cùng nhau, kể cả khi có exception: đóng file, trả connection, nhả lock, rollback transaction.

Cách nhanh nhất là dùng contextlib.contextmanager:

from contextlib import contextmanager

@contextmanager
def db_transaction(conn):
    try:
        yield conn
        conn.commit()
    except Exception:
        conn.rollback()
        raise

• Cách đầy đủ: viết class có __enter__ và __exit__(self, exc_type, exc, tb). Nếu __exit__ trả về True thì exception bị nuốt.
• Bản async: async with, __aenter__/__aexit__ hoặc asynccontextmanager.

Hay sai: quên raise lại exception trong khối except, khiến lỗi bị che mất và code phía sau tưởng mọi thứ đã thành công.

Deadlock là khi hai transaction giữ khoá mà bên kia cần và chờ nhau mãi. DB tự phát hiện, chọn một transaction làm nạn nhân và rollback nó.

Ví dụ: T1 khoá dòng A rồi muốn B, cùng lúc T2 khoá B rồi muốn A.

Cách giảm deadlock:

• Luôn khoá tài nguyên theo cùng một thứ tự (vd. sắp xếp theo id trước khi update nhiều dòng).
• Giữ transaction ngắn, không chờ I/O bên ngoài khi đang giữ khoá.
• Có index phù hợp để câu UPDATE/DELETE không khoá quá nhiều dòng.
• Ứng dụng bắt lỗi deadlock và retry có giới hạn.

Khi điều tra: MySQL dùng SHOW ENGINE INNODB STATUS, PostgreSQL xem log (deadlock được ghi kèm câu lệnh) và pg_locks.

Người phỏng vấn muốn nghe: bạn coi retry là bình thường nhưng vẫn tìm gốc rễ ở thứ tự khoá.

Chọn theo mô hình truy cập dữ liệu, không theo xu hướng. SQL mạnh ở quan hệ, ràng buộc và transaction; NoSQL mạnh ở schema linh hoạt, mô hình dữ liệu đặc thù hoặc scale ngang dễ hơn.

• Document (MongoDB): dữ liệu dạng cây, đọc nguyên khối theo một khoá, schema thay đổi thường xuyên.
• Key-value (Redis): cache, session, rate limit, bộ đếm, hàng đợi nhỏ; dữ liệu chủ yếu nằm trong RAM.
• Wide-column, time-series, search engine: ghi khối lượng lớn, log, tìm kiếm full-text.

Trade-off: JOIN và transaction nhiều document hạn chế hoặc đắt hơn, ràng buộc dữ liệu chuyển sang tầng ứng dụng, và phải thiết kế theo query ngay từ đầu.

Người phỏng vấn muốn nghe: nhiều hệ thống dùng kết hợp, vd. PostgreSQL làm nguồn sự thật, Redis làm cache. PostgreSQL với JSONB cũng đủ cho nhiều nhu cầu "schema linh hoạt".

Mỗi kỹ thuật giải một vấn đề khác nhau, nên cần xác định điểm nghẽn là đọc, ghi hay kích thước dữ liệu.

• Read replica: giảm tải đọc. Phải chấp nhận replication lag; luồng vừa ghi xong đọc lại nên đọc từ primary.
• Partitioning (trong một DB): chia bảng theo khoảng thời gian hoặc theo key. Query có điều kiện trên partition key chỉ quét phần liên quan, xoá dữ liệu cũ bằng DROP PARTITION rất nhanh.
• Sharding (nhiều DB): khi một máy không chịu nổi lượng ghi hoặc dung lượng. Đổi lại phải chọn shard key cẩn thận, query xuyên shard và transaction phân tán rất khó.

Thứ tự hợp lý: tối ưu query và index, archive dữ liệu cũ, thêm replica và cache, partition, cuối cùng mới shard.

Hay sai: chọn shard key gây hot spot, vd. theo ngày tạo khiến mọi lượt ghi dồn vào một shard.

asyncio chạy nhiều coroutine trên một thread. Khi coroutine gặp await một thao tác I/O, nó nhường quyền cho event loop chạy coroutine khác. Đây là đa nhiệm hợp tác: coroutine nào không await thì chiếm luôn cả loop.

Trong FastAPI:

• async def khi mọi thứ bên trong đều async (httpx.AsyncClient, driver DB async).
• def khi dùng thư viện blocking (requests, ORM đồng bộ). FastAPI sẽ chạy hàm này trong threadpool, nên không chặn loop.
• Gọi song song: await asyncio.gather(fetch_a(), fetch_b()).

Hay sai: viết async def rồi gọi requests.get() hoặc time.sleep() bên trong. Cả server đứng hình trong lúc chờ. Nếu buộc phải gọi code blocking, dùng await asyncio.to_thread(func).

Người phỏng vấn muốn nghe: async tăng khả năng xử lý đồng thời cho I/O, không làm code CPU nhanh hơn.

Trả lời thật nhưng hướng về phía trước: nói điều bạn đang tìm kiếm, không kể xấu nơi cũ.

Lý do chấp nhận được: muốn thử thách mới, muốn làm sản phẩm, dự án kết thúc, công ty tái cấu trúc, thu nhập chưa tương xứng (nói khéo).

Câu mẫu: "Em đã làm 2 năm ở dự án outsourcing, học được nhiều về quy trình và làm việc với khách nước ngoài. Giờ em muốn gắn bó lâu dài với một sản phẩm để thấy được tác động của những gì mình làm, và vị trí bên mình đúng hướng đó."

Hay sai: chê sếp, chê đồng nghiệp, kể chuyện drama. Người phỏng vấn sẽ nghĩ bạn cũng sẽ nói về công ty họ như vậy. Nếu nhảy việc nhiều, chuẩn bị lời giải thích cho từng lần.