Databases 17 min read

MySQL Indexes, ACID, Raft, and gRPC: Technical Interview Insights

This article combines a Meituan salary update with detailed explanations of MySQL indexing strategies, B‑tree variations, ACID transaction properties, isolation levels, caching, handling high‑traffic queries, the Raft consensus algorithm, and an overview of gRPC, providing comprehensive backend development knowledge for interview preparation.

Java Tech Enthusiast
Java Tech Enthusiast
Java Tech Enthusiast
MySQL Indexes, ACID, Raft, and gRPC: Technical Interview Insights

Recently Meituan announced a bi‑annual salary adjustment for frontline teams, typically ranging from 5% to 10% depending on performance, illustrating real‑world compensation trends for developers.

Meituan Interview Experience

The interview focused on backend fundamentals rather than language specifics; candidates were evaluated on MySQL, Redis, project experience, data structures, and algorithms.

1. What is an index?

An index works like a book's table of contents, reducing the amount of data scanned and improving query speed.

If a query does not use an index, it performs a full table scan (O(n)).

When an index is used, MySQL typically employs a B+‑tree, allowing binary‑search‑like lookups with O(log N) complexity.

MySQL classifies indexes by data structure, physical storage, field characteristics, and field count (e.g., B+‑tree, hash, primary, unique, composite).

2. Why are index queries fast?

B+‑trees are balanced, storing all data in leaf nodes linked together, which makes range queries and sorting efficient while minimizing I/O.

Example: WHERE age = 25 can directly locate matching rows via the index without scanning the entire table.

3. Differences among binary tree, B‑tree, and B+‑tree

Binary tree: each node has at most two children; worst‑case depth can degrade to O(n).

B‑tree: a multi‑way balanced search tree where each node holds multiple keys and children; operations are O(log n).

B+‑tree: a variant of B‑tree that stores data only in leaf nodes and links leaves for efficient range scans.

4. What is a “back‑table” (回表) operation?

Secondary indexes store only the primary key; to retrieve full rows, the engine first uses the secondary index to get the primary key, then looks up the primary (clustered) index.

CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    age INT,
    INDEX idx_age (age) -- secondary index
);
SELECT * FROM users WHERE age = 25;

The query uses idx_age to find matching primary keys, then fetches the complete rows from the clustered index.

5. Do all secondary indexes require a back‑table lookup?

If a secondary index contains all columns needed by the query, it can be used as a covering index, avoiding any back‑table access and improving performance.

6. What is ACID?

Atomicity : all operations in a transaction succeed or none do.

Consistency : data remains valid according to defined rules before and after the transaction.

Isolation : concurrent transactions do not interfere with each other.

Durability : once committed, changes survive crashes.

In InnoDB, durability is ensured by redo logs, atomicity by undo logs, isolation by MVCC or locks, and consistency by the combination of the other three properties.

7. How is isolation implemented?

Isolation relies on lock mechanisms, MVCC, and configurable isolation levels (read uncommitted, read committed, repeatable read – the default in InnoDB, and serializable).

8. Caching

Redis can serve as an in‑memory cache layer for MySQL to accelerate read‑heavy workloads.

9. Handling massive MySQL traffic

Add appropriate indexes.

Implement read‑write splitting with master‑slave replication.

Split large tables into smaller ones.

Introduce a cache layer (e.g., Redis) with appropriate consistency strategies.

10. Raft Algorithm Overview

Raft achieves consensus via a leader that replicates log entries to followers; once a majority acknowledges, the entry is committed.

11. Raft Election Process

Follower times out, increments its term, and becomes a Candidate.

Candidate votes for itself and requests votes from other nodes.

Peers grant a vote if they haven’t voted in the current term and the candidate’s log is at least as up‑to‑date.

If the candidate receives a majority, it becomes the Leader and starts sending heartbeats.

Election conflicts are resolved by new timeouts and re‑elections.

12. gRPC Overview

gRPC is a high‑performance, open‑source RPC framework built on HTTP/2, using Protocol Buffers (.proto) for service definitions and serialization, offering strong‑typed interfaces and multi‑language support.

HTTP/2 provides multiplexing, header compression, and server push.

Protobuf defines messages and services in *.proto files.

Generated code ensures type safety across client and server.

Supports languages such as Go, Java, Python, C++, Node.js.

The article concludes with brief interview anecdotes and a “hand‑written” programming challenge.

backendDatabasegRPCMySQLIndexesACIDRaft
Java Tech Enthusiast
Written by

Java Tech Enthusiast

Sharing computer programming language knowledge, focusing on Java fundamentals, data structures, related tools, Spring Cloud, IntelliJ IDEA... Book giveaways, red‑packet rewards and other perks await!

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.