Mastering Spring Boot, MySQL Indexes, and Redis: Interview Insights & Performance Tips

Hikvision, a reputable company, offers competitive salaries for software development positions; examples include 14k×15 months (≈210k) for a 985 bachelor in Wuhan, 15k×15 months (≈225k) for a dual‑first‑class master in Hangzhou, and up to 19k×15 months (≈285k) for top‑tier graduates.

The interview process consists of one technical round and one HR round, with typical questions covering Java, MySQL, and Redis fundamentals.

Java

Spring Boot startup process

Locate the main method and instantiate a SpringApplication object before invoking run().

Enter run() and create SpringApplicationRunListeners to start listening.

Load the ConfigurableEnvironment and add it to the listeners.

Load the ConfigurableApplicationContext, which becomes the return value of run().

Refresh the context to create the Spring container, completing starter auto‑configuration and bean instantiation.

Spring MVC execution flow

All requests arrive at the front‑controller DispatcherServlet. DispatcherServlet uses HandlerMapping to locate a matching handler.

The mapping returns a HandlerExecutionChain containing the handler and any interceptors.

The appropriate HandlerAdapter is found for the handler.

The handler is executed, producing a ModelAndView.

The result is returned to DispatcherServlet.

If the view name is logical, DispatcherServlet resolves it via configured ViewResolver s. ViewResolver creates the concrete View object.

The view renders the model data into the request scope. DispatcherServlet sends the response back to the client.

MySQL

MySQL index mechanisms and types

Indexes can be classified from four perspectives:

By data structure: B+Tree, Hash, Full‑text .

By physical storage: Clustered (primary) index, secondary (auxiliary) index .

By field characteristics: Primary, unique, ordinary, prefix .

By column count: Single‑column, composite (multiple‑column) index .

Data‑structure classification

InnoDB, the default engine since MySQL 5.5, primarily uses B+Tree indexes. Primary keys become clustered indexes; other indexes are secondary.

Creating a primary key:

CREATE TABLE table_name (
  ...
  PRIMARY KEY (index_column_1) USING BTREE
);

Creating a unique index:

CREATE TABLE table_name (
  ...
  UNIQUE KEY (index_column_1, index_column_2, ...)
);

Adding a unique index after table creation:

CREATE UNIQUE INDEX index_name ON table_name(index_column_1, index_column_2, ...);

Creating an ordinary index:

CREATE TABLE table_name (
  ...
  INDEX (index_column_1, index_column_2, ...)
);

Adding an ordinary index after table creation:

CREATE INDEX index_name ON table_name(index_column_1, index_column_2, ...);

Creating a prefix index:

CREATE TABLE table_name(
    column_list,
    INDEX (column_name(length))
);

Adding a prefix index after table creation:

CREATE INDEX index_name ON table_name(column_name(length));

Creating a composite index:

CREATE INDEX index_product_no_name ON product(product_no, name);

Composite indexes follow the left‑most matching principle; queries must use the leftmost columns to benefit from the index.

Index failure detection

Use EXPLAIN to view the execution plan. Important fields include possible_keys, key, key_len, rows, and type. Scan types from worst to best: All → index → range → ref → eq_ref → const . The extra column highlights issues such as Using filesort, Using temporary, and Using index.

Common scenarios causing index loss:

LIKE patterns with leading wildcards (e.g., %xx).

Applying functions or expressions to indexed columns.

Implicit type conversion between strings and numbers.

Violating the left‑most rule in composite indexes.

OR conditions where only one side uses an indexed column.

Redis

Why Redis is so fast

Most operations run entirely in memory using efficient data structures.

Single‑threaded design avoids context‑switch overhead and lock contention.

Uses I/O multiplexing (select/epoll) to handle many client sockets with one thread.

Why multithreading was introduced after Redis 6.0

Redis still executes commands in a single thread, but background threads handle time‑consuming tasks such as file closing, AOF flushing, and lazy memory freeing. Since Redis 4.0, three background threads exist for these tasks.

From Redis 6.0 onward, additional I/O threads can process network requests, improving throughput when network I/O becomes the bottleneck.

Configuration example:

// Enable I/O threads for read requests
io-threads-do-reads yes

// Set number of I/O threads (N‑1 worker threads + main thread)
io-threads 4

Typical recommendations: use 2–3 I/O threads on a 4‑core CPU, 5–6 on an 8‑core CPU, ensuring the thread count is less than the number of CPU cores.

Redis distributed lock for preventing overselling

A distributed lock ensures that only one instance can modify inventory at a time, preventing stock from dropping below zero. The trade‑off is reduced concurrency for the locked product.