数据库 on 吾爱主机

MySQL深度调优实战：从SQL到架构的全面优化

Fri, 26 Jun 2026 17:00:00 +0000

前言

MySQL 是最流行的关系型数据库之一，但在生产环境中，性能问题往往是开发和运维面临的最大挑战。本文将从 SQL 优化、索引设计、配置调优、架构优化四个维度，全面介绍 MySQL 性能调优的实战技巧。

一、SQL 优化

1.1 EXPLAIN 执行计划分析

EXPLAIN SELECT * FROM users WHERE age > 25 AND city = 'Beijing';

关键字段说明：

字段	说明	优化目标
type	访问类型	至少达到 range 级别
key	使用的索引	避免 NULL
rows	扫描行数	越小越好
Extra	额外信息	避免 Using filesort/temporary

type 访问类型（从好到差）：

system > const > eq_ref > ref > range > index > ALL

1.2 索引优化技巧

最左前缀原则

-- 联合索引 (a, b, c)
-- ✅ 命中索引
SELECT * FROM table WHERE a = 1;
SELECT * FROM table WHERE a = 1 AND b = 2;
SELECT * FROM table WHERE a = 1 AND b = 2 AND c = 3;

-- ❌ 无法使用索引
SELECT * FROM table WHERE b = 2;
SELECT * FROM table WHERE c = 3;
SELECT * FROM table WHERE b = 2 AND c = 3;

覆盖索引

-- 创建覆盖索引
ALTER TABLE users ADD INDEX idx_name_age (name, age);

-- 查询只需要索引字段，无需回表
SELECT name, age FROM users WHERE name = 'John';

索引失效场景

-- ❌ 函数操作
SELECT * FROM users WHERE YEAR(create_time) = 2024;
-- ✅ 改为范围查询
SELECT * FROM users WHERE create_time >= '2024-01-01' 
 AND create_time < '2025-01-01';

-- ❌ 隐式类型转换
SELECT * FROM users WHERE phone = 13800138000;
-- ✅ 类型匹配
SELECT * FROM users WHERE phone = '13800138000';

-- ❌ LIKE 左模糊
SELECT * FROM users WHERE name LIKE '%John';
-- ✅ 前缀匹配
SELECT * FROM users WHERE name LIKE 'John%';

-- ❌ OR 条件
SELECT * FROM users WHERE age = 25 OR name = 'John';
-- ✅ 使用 UNION
SELECT * FROM users WHERE age = 25
UNION
SELECT * FROM users WHERE name = 'John';

1.3 查询优化

分页查询优化

-- ❌ 慢查询（深分页）
SELECT * FROM orders ORDER BY id LIMIT 1000000, 10;

-- ✅ 延迟关联
SELECT o.* FROM orders o
INNER JOIN (
 SELECT id FROM orders ORDER BY id LIMIT 1000000, 10
) t ON o.id = t.id;

-- ✅ 游标分页
SELECT * FROM orders WHERE id > 1000000 ORDER BY id LIMIT 10;

JOIN 优化

-- 确保关联字段有索引
ALTER TABLE orders ADD INDEX idx_user_id (user_id);

-- 小表驱动大表
SELECT o.* FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE u.status = 1;

子查询优化

-- ❌ 子查询
SELECT * FROM orders WHERE user_id IN (
 SELECT id FROM users WHERE status = 1
);

-- ✅ JOIN 优化
SELECT o.* FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE u.status = 1;

二、索引设计原则

2.1 索引设计规范

-- 1. 选择区分度高的列
SELECT 
 COUNT(DISTINCT city) / COUNT(*) AS selectivity
FROM users;
-- 区分度 > 0.1 才考虑建索引

-- 2. 联合索引字段顺序
-- 区分度高的字段在前
-- 查询频率高的字段在前
-- 排序字段在最后

-- 3. 避免过多索引
-- 每张表索引不超过 5 个
-- 单个索引字段不超过 5 个

2.2 索引监控

-- 查看索引使用情况
SELECT 
 object_schema,
 object_name,
 index_name,
 count_read,
 count_fetch
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_database'
ORDER BY count_read DESC;

-- 查看未使用的索引
SELECT 
 object_schema,
 object_name,
 index_name
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_database'
 AND index_name IS NOT NULL
 AND count_star = 0;

三、配置调优

3.1 InnoDB Buffer Pool

# my.cnf
[mysqld]
# Buffer Pool 大小，建议物理内存的 70-80%
innodb_buffer_pool_size = 8G

# Buffer Pool 实例数，减少锁竞争
innodb_buffer_pool_instances = 8

# Buffer Pool 预热
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_load_at_startup = ON

3.2 日志配置

[mysqld]
# Redo Log 大小
innodb_log_file_size = 1G
innodb_log_buffer_size = 64M

# 刷盘策略
# 1：每次提交都刷盘（最安全）
# 2：每次提交写入OS缓存
# 0：每秒刷盘
innodb_flush_log_at_trx_commit = 1

# 双1配置（生产推荐）
sync_binlog = 1

3.3 连接配置

[mysqld]
# 最大连接数
max_connections = 500

# 连接超时
wait_timeout = 600
interactive_timeout = 600

# 线程缓存
thread_cache_size = 64

# 表缓存
table_open_cache = 4096
table_definition_cache = 2048

3.4 查询缓存（MySQL 8.0 已移除）

# MySQL 5.7 及以下
[mysqld]
query_cache_type = 0 # 建议关闭
query_cache_size = 0

3.5 排序和临时表

[mysqld]
# 排序缓冲区
sort_buffer_size = 4M

# JOIN 缓冲区
join_buffer_size = 4M

# 临时表大小
tmp_table_size = 64M
max_heap_table_size = 64M

# 读缓冲区
read_buffer_size = 2M
read_rnd_buffer_size = 8M

四、架构优化

4.1 读写分离

 ┌─────────────┐
 │ 应用程序 │
 └──────┬──────┘
 │
 ┌──────▼──────┐
 │ 代理层 │
 │ (ProxySQL) │
 └──────┬──────┘
 │
 ┌──────────────┼──────────────┐
 │ │ │
 ┌──────▼──────┐ ┌────▼────┐ ┌───────▼──────┐
 │ Master │ │ Slave 1 │ │ Slave 2 │
 │ (写) │ │ (读) │ │ (读) │
 └─────────────┘ └─────────┘ └──────────────┘

ProxySQL 配置示例：

-- 添加后端MySQL服务器
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES
(10, '10.0.0.1', 3306), -- 写组
(20, '10.0.0.2', 3306), -- 读组
(20, '10.0.0.3', 3306); -- 读组

-- 配置读写分离规则
INSERT INTO mysql_query_rules (rule_id, match_pattern, destination_hostgroup) VALUES
(1, '^SELECT.*FOR UPDATE', 10), -- 写操作
(2, '^SELECT', 20); -- 读操作

4.2 分库分表

垂直分库

用户库 (user_db)
├── users
├── user_profiles
└── user_settings

订单库 (order_db)
├── orders
├── order_items
└── payments

商品库 (product_db)
├── products
├── categories
└── inventory

水平分表

-- 按用户ID分表
orders_0 -- user_id % 4 = 0
orders_1 -- user_id % 4 = 1
orders_2 -- user_id % 4 = 2
orders_3 -- user_id % 4 = 3

-- ShardingSphere 配置
spring.shardingsphere.datasource.names=ds0,ds1
spring.shardingsphere.sharding.tables.orders.actual-data-nodes=ds$->{0..1}.orders_$->{0..3}
spring.shardingsphere.sharding.tables.orders.table-strategy.inline.sharding-column=user_id
spring.shardingsphere.sharding.tables.orders.table-strategy.inline.algorithm-expression=orders_$->{user_id % 4}

4.3 缓存策略

┌──────────┐ ┌──────────┐ ┌──────────┐
│ 应用程序 │───▶│ Redis │───▶│ MySQL │
└──────────┘ └──────────┘ └──────────┘
 │ │ │
 │ 1.查询缓存 │ │
 │──────────────▶│ │
 │ 2.返回缓存 │ │
 │◀──────────────│ │
 │ │ │
 │ 3.缓存未命中│ │
 │──────────────────────────────▶│
 │ 4.查询数据库│ │
 │◀──────────────────────────────│
 │ │ │
 │ 5.写入缓存 │ │
 │──────────────▶│ │

缓存更新策略：

// Cache Aside Pattern
public User getUser(Long userId) {
 // 1. 先查缓存
 String key = "user:" + userId;
 User user = redis.get(key);
 if (user != null) {
 return user;
 }
 
 // 2. 缓存未命中，查数据库
 user = userMapper.selectById(userId);
 if (user != null) {
 // 3. 写入缓存
 redis.setex(key, 3600, user);
 }
 return user;
}

4.4 表设计优化

-- 1. 选择合适的数据类型
-- ❌ 不推荐
CREATE TABLE users (
 id BIGINT,
 name VARCHAR(1000),
 age INT,
 status VARCHAR(20)
);

-- ✅ 推荐
CREATE TABLE users (
 id BIGINT UNSIGNED AUTO_INCREMENT,
 name VARCHAR(50) NOT NULL,
 age TINYINT UNSIGNED,
 status TINYINT NOT NULL DEFAULT 1,
 PRIMARY KEY (id),
 INDEX idx_name (name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 2. 避免NULL
-- 使用 NOT NULL + DEFAULT

-- 3. 主键设计
-- 使用自增ID作为主键
-- 避免使用UUID作为主键（无序，影响插入性能）

五、监控与诊断

5.1 慢查询日志

[mysqld]
# 开启慢查询日志
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1 # 超过1秒记录
log_queries_not_using_indexes = ON

# 分析慢查询日志
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

# 使用 pt-query-digest
pt-query-digest /var/log/mysql/slow.log > slow_report.txt

5.2 性能监控SQL

-- 查看当前连接
SHOW PROCESSLIST;

-- 查看InnoDB状态
SHOW ENGINE INNODB STATUS;

-- 查看表大小
SELECT 
 table_schema,
 table_name,
 ROUND(data_length / 1024 / 1024, 2) AS data_mb,
 ROUND(index_length / 1024 / 1024, 2) AS index_mb
FROM information_schema.tables
WHERE table_schema = 'your_database'
ORDER BY data_length DESC;

-- 查看索引使用统计
SELECT 
 object_schema,
 object_name,
 index_name,
 count_star,
 count_read,
 count_fetch
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_database';

5.3 诊断工具

# Percona Toolkit
# 安装
apt install percona-toolkit

# 分析慢查询
pt-query-digest /var/log/mysql/slow.log

# 检查重复/冗余索引
pt-duplicate-key-checker --host=localhost --user=root --password=xxx

# 查看索引使用情况
pt-index-usage --host=localhost --user=root --password=xxx /var/log/mysql/slow.log

六、调优清单

6.1 SQL 层面

所有查询都使用了合适的索引
避免了 SELECT *，只查询需要的字段
分页查询使用了延迟关联
避免了深分页（LIMIT offset 过大）
JOIN 查询关联字段有索引
避免了索引失效的写法

6.2 索引层面

高频查询字段都有索引
联合索引遵循最左前缀原则
区分度低的字段不建索引
定期清理未使用的索引
使用覆盖索引减少回表

6.3 配置层面

Buffer Pool 设置为物理内存的 70-80%
开启慢查询日志
设置合理的连接数
配置合适的日志刷盘策略

6.4 架构层面

读写分离（读多写少场景）
分库分表（数据量大场景）
引入缓存层（热点数据）
表设计规范化

总结

MySQL 调优是一个系统工程，需要从多个维度综合考虑：

SQL 优化是基础：写好 SQL 是最直接的优化手段
索引设计是核心：合理的索引能提升查询性能数倍
配置调优是保障：正确的配置能最大化硬件利用率
架构优化是根本：当单机瓶颈时，架构扩展是必由之路

建议按照本文的调优清单逐步检查，结合监控数据持续优化。

2025 Java MySQL 面试高频题汇总

Thu, 25 Jun 2026 10:05:00 +0000

前言

本文整理了 2025 年 Java 后端开发面试中 MySQL 相关的高频考点，涵盖索引优化、事务隔离、锁机制、SQL 调优等核心内容，帮助候选人系统复习、高效备战。

一、MySQL 索引相关

1.1 为什么 MySQL 使用 B+ 树而不是 B 树？

B+ 树叶子节点形成有序链表，范围查询效率更高
非叶子节点只存储索引，单个页能容纳更多索引，树高更矮，IO 次数更少
所有查询都落到叶子节点，查询性能稳定

1.2 聚簇索引和非聚簇索引的区别？

特性	聚簇索引	非聚簇索引（二级索引）
数据存储	叶子节点存储完整数据行	叶子节点存储主键值
查询方式	直接获取数据	需要回表查询
数量限制	一张表只有一个	可以有多个

1.3 什么是覆盖索引？

覆盖索引是指查询的列全部在索引中，不需要回表查询主键索引就能获取数据，显著提升查询性能。

-- 假设有联合索引 idx_name_age(name, age)
SELECT name, age FROM user WHERE name = '张三';
-- 此查询走覆盖索引，无需回表

1.4 索引失效的常见场景

使用 LIKE '%xxx' 左模糊查询
对索引列使用函数或表达式
隐式类型转换
使用 OR 连接非索引列
联合索引未遵循最左前缀原则
NOT IN、NOT EXISTS、!=、<> 可能导致失效

二、事务与隔离级别

2.1 事务的 ACID 特性

A（原子性）：undo log 实现，事务要么全部成功，要么全部回滚
C（一致性）：由其他三个特性共同保证
I（隔离性）：锁机制 + MVCC 实现
D（持久性）：redo log 实现

2.2 四种隔离级别

隔离级别	脏读	不可重复读	幻读
READ UNCOMMITTED	✓	✓	✓
READ COMMITTED	✗	✓	✓
REPEATABLE READ（默认）	✗	✗	✗*
SERIALIZABLE	✗	✗	✗

InnoDB 在 RR 级别下通过 MVCC + Next-Key Lock 解决了大部分幻读问题。

2.3 MVCC 实现原理

MVCC（多版本并发控制）通过以下机制实现：

隐藏列：每行数据包含 DB_TRX_ID（事务ID）、DB_ROLL_PTR（回滚指针）
undo log：形成版本链
Read View：根据事务启动时机判断可见性

RC 与 RR 的区别：RC 每次查询生成新的 Read View，RR 只在事务第一次查询时生成。

三、锁机制

3.1 InnoDB 锁类型

共享锁（S Lock）：读锁，多个事务可共享
排他锁（X Lock）：写锁，互斥
意向锁（IS/IX）：表级锁，标识事务意图
间隙锁（Gap Lock）：锁定索引间隙，防止幻读
临键锁（Next-Key Lock）：记录锁 + 间隙锁，左开右闭区间

3.2 死锁如何产生和解决？

产生条件：两个或多个事务互相等待对方持有的锁。

排查方法：

SHOW ENGINE INNODB STATUS; -- 查看最近死锁信息
SELECT * FROM information_schema.INNODB_TRX; -- 查看当前事务

解决方案：

按固定顺序访问表和行
大事务拆小事务
设置合理的锁等待超时 innodb_lock_wait_timeout
使用低隔离级别（业务允许时）

四、SQL 优化

4.1 EXPLAIN 执行计划关键字段

EXPLAIN SELECT * FROM user WHERE name = '张三';

重点关注字段：

type：访问类型，性能从好到差 system > const > eq_ref > ref > range > index > ALL
key：实际使用的索引
rows：预估扫描行数
Extra：Using index（覆盖索引）、Using filesort（文件排序）、Using temporary（临时表）

4.2 慢查询优化思路

开启慢查询日志定位问题 SQL
使用 EXPLAIN 分析执行计划
合理添加索引（遵循最左前缀原则）
避免 SELECT *，只查询需要的列
分页优化：深分页使用延迟关联

-- 深分页优化：先查主键再关联
SELECT * FROM user u
INNER JOIN (
 SELECT id FROM user ORDER BY id LIMIT 1000000, 10
) t ON u.id = t.id;

4.3 JOIN 优化

小表驱动大表
被驱动表关联字段加索引
避免 LEFT JOIN 时 ON 条件使用 OR

五、MySQL 架构

5.1 InnoDB 架构核心组件

Buffer Pool：缓存数据页和索引页
Change Buffer：缓存非唯一二级索引的写操作
Log Buffer：缓存 redo log
redo log：保证事务持久性（WAL 机制）
undo log：保证事务原子性，支持 MVCC

5.2 binlog、redo log、undo log 区别

特性	binlog	redo log	undo log
层级	Server 层	InnoDB 引擎	InnoDB 引擎
内容	逻辑日志	物理日志	逻辑日志
作用	主从复制、数据恢复	崩溃恢复	事务回滚、MVCC
写入方式	追加写入	循环写入	追加写入

5.3 两阶段提交（2PC）

为了保证 binlog 和 redo log 的一致性：

prepare 阶段：redo log 写入磁盘，标记为 prepare
commit 阶段：binlog 写入磁盘后，redo log 标记为 commit

六、高频场景题

6.1 分库分表方案

垂直分库：按业务拆分（订单库、用户库）
水平分表：按行拆分（取模、范围、时间）
常用中间件：ShardingSphere、MyCat

6.2 如何设计一个高并发的秒杀数据库方案？

热点数据缓存到 Redis
库存扣减使用 Redis 原子操作预扣
订单写入异步队列
数据库层面乐观锁更新
分库分表减少单表压力

-- 乐观锁扣减库存
UPDATE goods SET stock = stock - 1 
WHERE id = 1001 AND stock > 0;

总结

2025 年 Java MySQL 面试依然围绕 索引原理、事务隔离、锁机制、SQL 优化 四大核心主题展开。理解底层原理比死记硬背更重要，建议结合源码和实际项目经验深入学习。

推荐书籍：《高性能 MySQL》《MySQL 技术内幕：InnoDB 存储引擎》

Docker 安装达梦 DM8

Tue, 28 Apr 2026 10:00:00 +0000

背景

近期开源项目 SmartAdmin 的很多用户反馈需要支持达梦数据库，现在将 docker 安装达梦数据库记录下来，以便让更多有需要的技术人员看到，节省时间。

1、提前准备

环境为：Linux 系统 CentOS 8，达梦数据库为达梦 DM8 版本，单机版。

2、下载达梦镜像

达梦官方下载地址为：eco.dameng.com/download/，可能已经不提供 Docker 镜像下载。

所以请从笔者百度网盘下载：

链接: pan.baidu.com/s/1SsQK7mlJ
提取码: d83h
下载文件：dm8_20240715_x86_rh6_rq_single.tar.zip

3、上传并解压

1）将 dm8_20240715_x86_rh6_rq_single.tar.zip 上传到 Linux 服务器 CentOS 中

2）将其解压：

unzip dm8_20240715_x86_rh6_rq_single.tar.zip

4、加载 DM8 镜像到 Docker 中

1）进入镜像 dm8_20240715_x86_rh6_rq_single.tar 文件所在目录

2）执行加载命令：

docker load -i dm8_20240715_x86_rh6_rq_single.tar

3）检查是否成功加载 DM8 镜像：

docker images

5、明确启动容器参数

端口 15236
容器名字 dm8
不开启大小写敏感 -e CASE_SENSITIVE=0
数据映射目录：/home/database/dm8/data
字符集 UTF-8 -e UNICODE_FLAG=1
实例名称 -e INSTANCE_NAME=dm8_smartadmin

最终明确启动参数如下：

docker run -dit \
-p 15236:5236 \
--restart=always \
--name dm8 \
--privileged=true \
-e PAGE_SIZE=16 \
-e LD_LIBRARY_PATH=/opt/dmdbms/bin \
-e EXTENT_SIZE=32 \
-e BLANK_PAD_MODE=1 \
-e LOG_SIZE=1024 \
-e UNICODE_FLAG=1 \
-e LENGTH_IN_CHAR=1 \
-e CASE_SENSITIVE=0 \
-e INSTANCE_NAME=dm8_smartadmin \
-v /home/database/dm8/data:/opt/dmdbms/data \
dm8_single:dm8_20240715_rev232765_x86_rh6_64

6、启动容器

将上面的启动参数命令进行执行，查看是否启动成功：

docker ps

7、启动/停止/重启

docker stop dm8
docker start dm8
docker restart dm8

8、进入容器

进入容器命令为：

docker exec -it dm8 bash

9、其他注意事项

Docker 镜像中数据库默认用户名/密码为 SYSDBA/SYSDBA001