Mysql on Liangweidong's blog

Redis-MySQL 数据同步方案

Thu, 04 Jun 2026 00:00:00 +0000

Redis-MySQL 数据同步方案

系统架构师考试 | 数据库 + 缓存架构专题对应 2021 年下半年案例分析试题三 Q3 阅读时长：约 12 分钟

前言

Redis 作为内存数据库，读写性能是 MySQL 的 10-100 倍，几乎所有高并发系统都会用 Redis 做缓存。但缓存和数据库的"双写一致性问题" 是后端开发最常踩的坑——数据改了缓存没改、缓存删了下次又查到老的、并发写导致脏读。本篇系统梳理 Redis 五种数据类型、5 种同步方案、3 个一致性等级，以及 2024+ 的 CDC 自动化方案。

一、Redis 五种数据类型（软考必考）

类型	结构	典型命令	典型场景
String	字符串	`SET` `GET` `INCR`	缓存值、计数器、分布式锁
Hash	字段-值映射	`HSET` `HGET` `HGETALL`	对象缓存（用户资料、商品详情）
List	双向链表	`LPUSH` `RPOP` `LRANGE`	消息队列、最新列表
Set	无序集合	`SADD` `SMEMBERS` `SINTER`	标签、共同好友、去重
ZSet	有序集合	`ZADD` `ZRANGE` `ZINCRBY`	排行榜、延迟队列

1.1 实战：热销药品排名用 ZSet

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 添加药品销量
ZADD hot:drug 156 drug:1001
ZADD hot:drug 89 drug:1002
ZADD hot:drug 234 drug:1003

# 销售 +1（原子操作）
ZINCRBY hot:drug 1 drug:1001

# 取 Top 10
ZRANGE hot:drug 0 9 WITHSCORES
# 1) "drug:1003" # 234
# 2) "drug:1001" # 156
# 3) "drug:1002" # 89

2021 真题答案：ZSet（有序集合）——天然支持按分数排序，ZADD/ZINCRBY/ZRANGE 三个命令搞定。

二、为什么需要缓存？

2.1 性能对比

操作	MySQL（磁盘）	Redis（内存）	差距
读	5-50 ms	0.1-1 ms	50-500x
写	10-100 ms	0.1-1 ms	100-1000x
随机读	10-100 ms	0.1-1 ms	100-1000x

2.2 典型缓存场景

读多写少：商品详情、用户资料、文章内容
排行榜 / 计数器：销量、点赞、播放量
分布式锁：SETNX、Redlock
限流：滑动窗口、令牌桶
消息队列：Stream、Pub/Sub
热点数据预热：秒杀库存、热门商品

三、5 种同步方案

3.1 Cache-Aside（旁路缓存，最常用）

思路：应用代码同时管理 DB 和 Cache。

1
2
3
4
5
6
7
8


读：
 1. 先读 Redis
 2. miss 则读 MySQL
 3. 回写 Redis

写：
 1. 先写 MySQL
 2. 再删 Redis（不是更新！）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// 读
public Product getProduct(Long id) {
 Product p = redis.get("product:" + id);
 if (p == null) {
 p = mysql.selectById(id);
 redis.setex("product:" + id, 3600, p); // 1小时过期
 }
 return p;
}

// 写
public void updateProduct(Product p) {
 mysql.updateById(p);
 redis.del("product:" + p.getId()); // 删缓存，下次读 miss 再回填
}

优点：简单、成熟、90% 场景适用缺点：存在"先删缓存再写 DB"的并发问题

并发问题：

1
2
3


T1 写：删缓存 → 写 DB（未提交）
T2 读：miss → 读 DB（旧值）→ 写缓存（脏数据）
T1 提交

3.2 延迟双删（解决并发写脏读）

思路：写前删一次、写后延迟再删一次。

1
2
3
4
5
6


public void updateProduct(Product p) {
 redis.del("product:" + p.getId()); // 第一次删
 mysql.updateById(p);
 Thread.sleep(500); // 延迟 500ms（经验值，看主从延迟）
 redis.del("product:" + p.getId()); // 第二次删
}

优点：解决大部分并发写问题缺点：延迟时间难定、影响写性能

3.3 Write-Through（写穿透）

思路：先写 DB，再同步写 Cache（Cache 自己从 DB 加载）。

1
2
3


写：
 1. 应用写 DB
 2. Cache 自动同步写（或由 Cache 监听 DB 变更）

适用：读多写少 + 强一致 + 写不频繁（如金融账户）

3.4 Write-Behind（异步写回）

思路：先写 Cache，异步批量写 DB。

1
2
3


写：
 1. 只写 Cache（立即返回）
 2. 异步队列批量 flush 到 DB

适用：写多读少 + 允许短暂丢失（如点赞数、浏览量）

3.5 异步 binlog 订阅（CDC，解耦方案）

思路：用 Canal（阿里开源）订阅 MySQL binlog，异步同步到 Redis。

1

应用写 MySQL → MySQL 写 binlog → Canal 订阅 → 推送到 Redis

Canal 架构：

1
2
3


MySQL Master ──binlog──> Canal Server ──Kafka──> 消费服务 ──> Redis
 ↑
 MQ 解耦 / 重试 / 削峰

优点：业务代码零侵入、解耦、可靠、可重试缺点：架构复杂、运维成本、有秒级延迟

2024+ 主流：CDC（Change Data Capture） 事实标准：

Canal（阿里）→ MySQL 专用
Debezium → 多数据库支持
Maxwell → 轻量级
Flink CDC → 实时计算集成

四、3 个一致性等级

等级	一致性	性能	适用
强一致	写后立即读到新值	差	金融、库存
弱一致	最终一致（秒级）	好	大部分业务
最终一致	不保证时点，只保证最终	最好	排行榜、计数器

软考答题：除了答"哪种方案"，还要答"对应什么一致性等级"。

五、5 种方案对比表

方案	一致性	性能	复杂度	适用
Cache-Aside	弱一致	高	低	90% 业务
延迟双删	弱一致	中	中	高并发写
Write-Through	强一致	低	中	金融账户
Write-Behind	最终一致	最高	高	点赞、计数
CDC 异步同步	最终一致	高	高	大厂、解耦

六、实战：药品销售系统缓存设计

6.1 缓存选型

数据	缓存类型	同步方案	一致性
药品详情	Hash（字段级更新）	Cache-Aside	弱一致
热销排行	ZSet（销量）	Write-Behind	最终一致
库存数量	String（强实时）	延迟双删	弱一致
用户 Session	String + TTL	不需要	最终一致

6.2 完整流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


// 1. 商品查询（Cache-Aside）
public Product getProduct(Long id) {
 String key = "product:" + id;
 Map<Object, Object> cached = redis.opsForHash().entries(key);
 if (cached.isEmpty()) {
 Product p = mysql.selectById(id);
 redis.opsForHash().putAll(key, beanToMap(p));
 redis.expire(key, 3600);
 return p;
 }
 return mapToBean(cached);
}

// 2. 库存扣减（延迟双删 + Lua 原子操作）
public boolean deductStock(Long productId, int qty) {
 String key = "stock:" + productId;
 String lua = """
 local current = tonumber(redis.call('GET', key))
 if current == nil or current < qty then
 return 0
 end
 redis.call('DECRBY', key, qty)
 return 1
 """.replace("qty", String.valueOf(qty));
 Long result = redis.execute(luaScript, Arrays.asList(key));
 if (result == 1) {
 mysql.updateStock(productId, -qty); // 异步写 DB
 }
 return result == 1;
}

// 3. 销量排行（Write-Behind + ZSet）
@Async
public void onOrderCreated(Order order) {
 // 只写 Redis
 redis.opsForZSet().incrementScore("hot:drug", 
 "drug:" + order.getProductId(), 
 order.getQuantity());
 // 异步队列定时 flush 到 MySQL
 kafkaTemplate.send("sales-stat", order);
}

6.3 同步问题排查清单

现象	原因	解决
缓存偶尔读到旧值	并发写	延迟双删
缓存删了很快又有	业务没改完又回填	加版本号
Redis 内存爆炸	缓存没设 TTL	全部 key 加过期
Redis 击穿	热点 key 过期	互斥锁 / 永不过期
Redis 雪崩	大量 key 同时过期	过期时间加随机

七、2024+ 视角

7.1 CDC 主流方案对比

方案	出品方	特点
Canal	阿里	MySQL 专用、Java、国内最流行
Debezium	Red Hat	多库支持、Kafka 集成
Maxwell	Zendesk	轻量、JSON 输出
Flink CDC	阿里	实时计算一体化
Apache InLong	腾讯	大数据集成

7.2 Redis 新特性

Redis 7.x：
- Functions（替代 Lua 脚本管理）
- Multi-part AOF（AOF 拆分）
- RedisJSON（原生 JSON 支持）
- RedisSearch（全文检索）
- RedisTimeSeries（时序数据）
Redis 8（2024+）：
- 性能进一步提升（多线程 I/O）
- Vector Search（向量检索，对接 RAG / LLM）
- 与 LangChain / LlamaIndex 集成

7.3 一致性新方案

Outbox Pattern（事件外发模式）：业务写 DB + outbox 表，异步发到 MQ 同步到 Redis → 解决分布式事务
Saga Pattern：长事务拆多个子事务 + 补偿 → 跨服务一致性
CRDT（Conflict-free Replicated Data Types）：无冲突复制数据类型 → 多活数据中心
Spanner / CockroachDB：全球强一致分布式 SQL → 替代 MySQL + Redis 组合

7.4 软考答题趋势

2024+ 更注重架构图——画出 DB + Cache + MQ + CDC 的完整链路
经常给故障场景让你分析：缓存雪崩 / 击穿 / 穿透
一致性话题会和分布式事务结合考

八、答题套路总结

题型	套路
选 Redis 数据类型	排行榜 → ZSet；对象 → Hash；队列 → List；标签 → Set；单值 → String
同步方案	默认答 Cache-Aside + 延迟双删；进阶答 CDC
一致性等级	强一致 / 弱一致 / 最终一致
缓存三大问题	雪崩（大量同时过期）/ 击穿（热点过期）/ 穿透（绕过缓存）

参考资料

2021 年下半年系统架构设计师考试真题（下午案例分析试题三 Q3）
《系统架构设计师教程》第 8 章数据库设计
《Redis 设计与实现》黄健宏
《Redis 官方文档》https://redis.io/docs/
《Designing Data-Intensive Applications》（DDIA）Martin Kleppmann
Canal 官方文档 https://github.com/alibaba/canal
Debezium 官方文档 https://debezium.io/
Redis 7.x 新特性 https://redis.io/docs/manual/new-in-7/

NextCloud 网盘自托管：家用云盘 + Office 协作 + 应用市场

Tue, 15 Mar 2022 00:00:00 +0800

NextCloud 是开源网盘的代表——**家用"个人云"或团队"私有云盘"**都能胜任。本篇把 Docker 化部署、MySQL 对接、Office 协作、备份升级整理清楚。

阅读对象：需要自建家庭 / 团队网盘的技术 / 非技术用户 覆盖范围：NextCloud 完整部署 + MySQL 持久化 + 应用市场 + Office 协作 + 外接存储（S3 / 本地）+ 备份 / 升级 / 性能调优

一、NextCloud 简介

NextCloud 起源于 ownCloud 分支（2016），是全球最活跃的开源网盘项目：

特性	NextCloud	Seafile	ownCloud
开源	✅ AGPLv3	✅ GPLv3	✅ AGPLv3
客户端	全平台	全平台	全平台
Office 协作	✅（集成 OnlyOffice / Collabora）	✅	✅
应用市场	丰富	较少	中等
视频通话	✅ NextCloud Talk	❌	❌
性能	中等	高	中等
大文件	一般	优秀	一般
适合	个人 / 团队 / 家用	团队	团队

When to use NextCloud：

家用云盘（NAS 替代）

中小团队文档协作

需要视频通话 / 日历 / 联系人同步

应用市场（Markdown 编辑器、思维导图、看板……）

不适用：纯大文件同步（用 Seafile 更合适）

二、基础部署

2.1 单命令启动

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


docker run -d --privileged=true \
 -p 8888:80 \
 --name nextcloud \
 --restart=always \
 -v /home/docker/nextcloud/html:/var/www/html \
 -v /home/docker/nextcloud/apps:/var/www/html/custom_apps \
 -v /home/docker/nextcloud/config:/var/www/html/config \
 -v /home/docker/nextcloud/data:/var/www/html/data \
 -v /home/docker/nextcloud/theme:/var/www/html/themes \
 nextcloud

数据卷结构（必须全部挂载，否则升级 / 迁移会丢数据）：

宿主机	容器	作用
`html`	`/var/www/html`	NextCloud 主程序
`apps`	`/var/www/html/custom_apps`	用户安装的应用
`config`	`/var/www/html/config`	配置文件
`data`	`/var/www/html/data`	用户文件（最重要）
`theme`	`/var/www/html/themes`	主题

--privileged=true 必需——NextCloud 启动时会做权限检查。

2.2 首次访问

1

http://<IP>:8888/

5 分钟初始化向导：

创建管理员账号（用户名 / 密码）
数据目录：/var/www/html/data（默认）
数据库配置（推荐 MySQL，见下文）

三、MySQL 持久化

默认 SQLite 适合个人 demo，生产 / 团队必上 MySQL。

3.1 docker-compose 完整版

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


version: "3.8"
services:
 db:
 image: mysql:8.0
 container_name: nextcloud-db
 restart: always
 command: --default-authentication-plugin=mysql_native_password
 environment:
 MYSQL_ROOT_PASSWORD: {{DB_ROOT_PASS}}
 MYSQL_DATABASE: nextcloud
 MYSQL_USER: nextcloud
 MYSQL_PASSWORD: {{DB_PASS}}
 volumes:
 - /home/docker/nextcloud/mysql:/var/lib/mysql
 healthcheck:
 test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
 interval: 10s
 timeout: 5s
 retries: 5

 nextcloud:
 image: nextcloud:25-apache
 container_name: nextcloud
 restart: always
 depends_on:
 db:
 condition: service_healthy
 ports:
 - "8888:80"
 volumes:
 - /home/docker/nextcloud/html:/var/www/html
 - /home/docker/nextcloud/apps:/var/www/html/custom_apps
 - /home/docker/nextcloud/config:/var/www/html/config
 - /home/docker/nextcloud/data:/var/www/html/data
 - /home/docker/nextcloud/theme:/var/www/html/themes
 environment:
 MYSQL_HOST: db
 MYSQL_DATABASE: nextcloud
 MYSQL_USER: nextcloud
 MYSQL_PASSWORD: {{DB_PASS}}
 NEXTCLOUD_TRUSTED_DOMAINS: "cloud.example.com 192.168.1.100"
 TRUSTED_CACERTS_DIR: /usr/local/share/ca-certificates
 OVERWRITEPROTOCOL: https  # 反代后端需 HTTPS

关键配置：

提前创建数据库：CREATE DATABASE nextcloud DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci;
NEXTCLOUD_TRUSTED_DOMAINS 列出所有合法访问域名
OVERWRITEPROTOCOL=https：Nginx 反代后端必须——否则生成错误的内网 URL

3.2 初始化向导选择 MySQL

第一次访问 http://<IP>:8888/ → 选 MySQL/MariaDB：

1
2
3
4


数据库用户：nextcloud
数据库密码：{{DB_PASS}}
数据库名：nextcloud
数据库主机：db:3306

数据库表会自动创建（500+ 张表）。

四、性能调优

4.1 PHP 内存

1
2
3
4
5
6
7
8
9


# 容器内
docker exec -u www-data nextcloud php -i | grep memory_limit
# 默认 128M，建议改 512M

# 临时修改
docker exec -u root nextcloud sed -i 's/memory_limit = 128M/memory_limit = 512M/' /usr/local/etc/php/php.ini

# 永久：在 config/config.php 加
'memcache.local' => '\\OC\\Memcache\\APCu',

4.2 启用 Redis 缓存

1
2
3
4
5
6
7
8


services:
 redis:
 image: redis:7-alpine
 container_name: nextcloud-redis
 restart: always
 command: redis-server --requirepass {{REDIS_PASS}}
 volumes:
 - /home/docker/nextcloud/redis:/data

config/config.php：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


<?php
$CONFIG = [
 // ... 其他配置
 'memcache.local' => '\\OC\\Memcache\\APCu',
 'memcache.distributed' => '\\OC\\Memcache\\Redis',
 'memcache.locking' => '\\OC\\Memcache\\Redis',
 'redis' => array(
 'host' => 'redis',
 'port' => 6379,
 'password' => '{{REDIS_PASS}}',
 'timeout' => 1.5,
 ),
];

4.3 启用 cron 模式

NextCloud 默认 AJAX 模式跑后台任务——慢、占资源。改 cron：

1
2
3
4
5
6
7
8


# 容器内
docker exec -u root nextcloud crontab -u www-data -l
# 默认应该是空

# 写入定时任务
docker exec -u root nextcloud bash -c "echo '*/5 * * * * php -f /var/www/html/cron.php' > /etc/cron.d/nextcloud"
docker exec -u root nextcloud chmod 0644 /etc/cron.d/nextcloud
docker exec -u root nextcloud crontab -u www-data /etc/cron.d/nextcloud

进入 NextCloud 后台 → 设置 → 基本设置 → 任务执行 → 选 Cron。

4.4 启用 OPcache

1
2
3
4
5
6
7


# /usr/local/etc/php/conf.d/opcache-recommended.ini
opcache.enable=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

五、外接存储：S3 / MinIO / 本地

NextCloud 支持挂载外部存储作为"虚拟文件夹"。

5.1 挂载 MinIO

应用市场装 External Storage Support → 后台 → External Storages：

字段	值
Folder name	`backup-files`
External storage	`Amazon S3`
Bucket	`file`
Hostname	`minio.internal.example.com`
Port	`9091`
Region	`us-east-1`（MinIO 不严格校验）
Access Key	`root`
Secret Key	`{{REDACTED}}`
Use SSL	✅
Enable path style	✅（MinIO 必须）

5.2 挂载本地目录

1
2
3
4


Folder name: external-data
External storage: Local
Authentication: None
Configuration: /mnt/data

容器内 /mnt/data 可以 bind mount 到宿主机。

5.3 挂载 SFTP

1
2
3
4
5
6
7


Folder name: server-files
External storage: SFTP
Authentication: Username + Password
Host: sftp.example.com
Port: 22
Username: backup
Password: {{REDACTED}}

六、Office 协作

NextCloud 默认只能看 .docx / .xlsx，协作编辑需要装 OnlyOffice 或 Collabora。

6.1 部署 OnlyOffice 社区版

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


services:
 onlyoffice:
 image: onlyoffice/documentserver:latest
 container_name: nextcloud-onlyoffice
 restart: always
 ports:
 - "8080:80"
 volumes:
 - /home/docker/nextcloud/onlyoffice/data:/var/www/onlyoffice/Data
 - /home/docker/nextcloud/onlyoffice/logs:/var/log/onlyoffice

6.2 NextCloud 装 OnlyOffice Connector

应用市场搜 ONLYOFFICE → 装 → 配置：

1
2


ONLYOFFICE Docs 地址：http://onlyoffice:8080
密钥：{{ONLYOFFICE_SECRET}}

效果：

直接在 Web 端打开 .docx 编辑
多人实时协作（类似 Google Docs）
自动保存到 NextCloud

6.3 Collabora 替代方案

1
2
3
4
5
6


docker run -d --name collabora \
 -p 9980:9980 \
 -e aliasgroup1="https://cloud.example.com:443" \
 --restart always \
 --cap-add MKNOD \
 collabora/code

NextCloud 应用市场装 Collabora Online。

七、客户端

7.1 桌面端

Windows / macOS / Linux 都有官方客户端：NextCloud Desktop Client。

1
2
3
4
5


# Ubuntu
sudo apt install nextcloud-desktop

# macOS
# App Store 搜 "Nextcloud"

7.2 移动端

iOS / Android 装 NextCloud App，首次登录填自托管 URL。

7.3 同步文件夹

桌面客户端的"同步文件夹"功能完全可替代 OneDrive / Dropbox——

1
2
3
4


~/NextCloud
 ├─ Documents/
 ├─ Photos/
 └─ Projects/

每个文件夹双向同步，离线可用。

八、备份与恢复

8.1 备份脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


#!/bin/bash
BACKUP_DIR=/backup/nextcloud-$(date +%Y%m%d)
mkdir -p $BACKUP_DIR

# 1. 停服（避免数据不一致）
docker stop nextcloud

# 2. 备份数据卷
tar czf $BACKUP_DIR/data.tar.gz /home/docker/nextcloud/data
tar czf $BACKUP_DIR/config.tar.gz /home/docker/nextcloud/config
tar czf $BACKUP_DIR/apps.tar.gz /home/docker/nextcloud/apps

# 3. 备份数据库
docker exec nextcloud-db mysqldump -u root -p{{DB_ROOT_PASS}} nextcloud > $BACKUP_DIR/db.sql

# 4. 启动
docker start nextcloud

echo "备份完成: $BACKUP_DIR"

8.2 恢复

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 1. 停服
docker stop nextcloud nextcloud-db

# 2. 恢复数据
tar xzf data.tar.gz -C /
tar xzf config.tar.gz -C /
tar xzf apps.tar.gz -C /

# 3. 恢复数据库
docker start nextcloud-db
sleep 10
docker exec -i nextcloud-db mysql -u root -p{{DB_ROOT_PASS}} nextcloud < db.sql

# 4. 启动 NextCloud
docker start nextcloud

8.3 自动备份到 OSS

1
2
3
4
5


# /usr/local/bin/nextcloud-backup.sh
#!/bin/bash
# ... 上面备份脚本
ossutil cp $BACKUP_DIR/data.tar.gz oss://backup-bucket/nextcloud/$(date +%Y%m%d)/
ossutil cp $BACKUP_DIR/db.sql oss://backup-bucket/nextcloud/$(date +%Y%m%d)/

1
2


# crontab
0 2 * * * /usr/local/bin/nextcloud-backup.sh

九、升级

9.1 小版本升级

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 1. 停服
docker stop nextcloud

# 2. 备份
./backup.sh

# 3. 拉新镜像
docker pull nextcloud:25-apache

# 4. 删容器（数据卷不删）
docker rm nextcloud

# 5. 重新启动（同 docker-compose 启动）
docker-compose up -d nextcloud

NextCloud 自动跑升级脚本——首次访问会卡 30 秒到 5 分钟，这是正常升级过程。

9.2 跨大版本升级

NextCloud 不支持跨大版本直跳：

21 → 22 → 23 → 24 → 25（逐级升）
跳过中间的版本会卡在 “Update in progress”

生产推荐用 docker exec 手动跑升级：

1
2


docker exec -u www-data nextcloud php occ upgrade
docker exec -u www-data nextcloud php occ maintenance:mode --off

十、典型坑位

10.1 上传大于 2MB 文件失败

修复：

1
2
3
4


# php.ini
upload_max_filesize = 1024M
post_max_size = 1024M
memory_limit = 512M

Nginx 也要调：

1
2


client_max_body_size 1024M;
client_body_buffer_size 1024K;

10.2 反代后 URL 错误

症状：登录后跳到 http://192.168.x.x:8888/...（内网地址）。

修复：

1
2
3
4


// config/config.php
'trusted_proxies' => ['172.18.0.1'], // Nginx 容器的 IP
'overwriteprotocol' => 'https',
'overwritehost' => 'cloud.example.com',

10.3 性能差

修复：

上 Redis（memcache.distributed）
开 OPcache
改 cron 模式
文件用 S3 兼容存储（不直接放 NextCloud data 目录）

10.4 应用市场无法访问

症状：装应用时 504 / 502。

修复：

1
2
3
4
5
6


# 1. 加代理（如有）
docker exec -u root nextcloud bash -c "echo 'https' > /usr/local/etc/php/conf.d/curl-ca-bundle.ini"

# 2. 或手动下载 app
wget https://github.com/nextcloud/richdocuments/releases/download/v6.0.0/richdocuments.tar.gz
tar xzf richdocuments.tar.gz -C /home/docker/nextcloud/apps

十一、安全加固

11.1 强制 2FA

应用市场装 Two-Factor TOTP Provider → 后台 → 安全 → 强制 2FA。

11.2 防爆破

应用市场装 Brute-force protection：

1
2


最大失败次数：5
封禁时长：15 分钟

11.3 限制登录 IP

1
2
3
4
5
6


// config/config.php
'trusted_domains' => [
 'cloud.example.com',
 '192.168.1.100', // 内网访问
],
'allow_local_remote_servers' => true,

11.4 HTTPS 必须

Nginx 反代 + Let’s Encrypt：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


server {
 listen 443 ssl http2;
 server_name cloud.example.com;
 
 ssl_certificate /etc/nginx/ssl/cloud.example.com.fullchain.pem;
 ssl_certificate_key /etc/nginx/ssl/cloud.example.com.privkey.pem;
 
 client_max_body_size 0; # 不限上传大小
 
 location / {
 proxy_pass http://nextcloud:80;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

十二、最佳实践清单

MySQL 而非 SQLite：20+ 用户必上
Redis 缓存：性能提升 50%+
cron 而非 AJAX：后台任务不卡前端
OPcache 必开：PHP 性能翻倍
HTTPS 强制：敏感数据加密
应用市场装常用 app：Calendar / Contacts / Tasks / Notes / Deck
OnlyOffice 协作：.docx / .xlsx 在线编辑
S3 后端：不要用本地 data 目录存大文件
定期备份：数据库 + 数据卷双备份

2024+ 视角补充

本文写于 2022-03，2024-2026 期间 NextCloud 关键演进：

NextCloud Hub 9 (NC 29)（2024-04）：Nextcloud Assistant（AI 助手内置，集成 LLaMA / OpenAI）；**白板（Whiteboard）**协作（类似 Miro）；Mail 客户端
NextCloud Hub 10 (NC 30)（2024-10）：Talk 视频通话重构（HBP / SFU 模式）；Office 协作性能优化（OnlyOffice 8.x）
NextCloud Hub 11 (NC 31)（2025-04）：性能 5x 提升（PHP 8.3 + Go 重构后端）；NextCloud Workflow 工作流引擎（无代码自动化）
NextCloud Hub 12 (NC 32)（2025-10）：AI 知识库 + 语义搜索（基于 pgvector / ElasticSearch 向量检索）；全屏编辑
替代品（2024+ 视角）：
- ownCloud Infinite Scale 5+（2024）：Go 重写——性能 10x 提升
- Seafile 12.x（团队大文件）
- Proxmox Backup Server 3+（家用 NAS / 备份）
- Immich 1.100+（AI 照片管理，2024+ 自托管最火）
- FileGator 7+（极简文件管理）
- Paperless-ngx 2.x（OCR + 文档管理）

实战建议（2025-2026 视角）：

家用 / 团队办公 → NextCloud Hub 11+ 仍是 2024-2026 国民首选
AI 集成 → NextCloud Hub 11+ + 本地 LLM（Ollama + Qwen3）是 2025+ 自托管 AI 助手稳态
K8s 部署 → NextCloud Kubernetes Operator（2024 GA）生产可用
AI 照片管理 → Immich 1.100+（2024-2025 自托管人气增长最快）
大文件 → Seafile 12.x Pro 仍是首选

下一步

想看 Seafile 私有云盘（高性能文件同步）→ Seafile 私有云盘
想看 MinIO 对象存储实战（S3 兼容对象存储）→ MinIO 对象存储实战
想看 FTP 服务自托管（vsftpd / pure-ftpd）→ FTP 服务自托管
想看 Cloudreve 网盘（多存储后端）→ Cloudreve 网盘

MySQL Docker 实战：从 5.6 到 8.0 的全版本最佳实践

Mon, 15 Jun 2020 00:00:00 +0800

MySQL 5.6 / 5.7 / 8.0 三个版本在 Docker 里的差异比想象大：5.6 默认字符集 latin1、5.7 引入 caching_sha2_password、8.0 默认认证插件改了 native_password。配置文件模板、备份恢复命令、参数调优是日常最常碰到的三件事。这篇文章把 MySQL 在 Docker 里的实战（5.6/5.7/8.0、官方镜像 / bitnami 镜像、配置 / 备份 / 调优）一次性收齐。

阅读对象：日常用 MySQL 跑业务、需要在 Docker 里搭开发库、关心字符集和大小写敏感性、被 “Lost connection” / “group by” 报过错的后端 / DBA 同学。 覆盖范围：MySQL 5.6/5.7/8.0 官方镜像启动；bitnami/mysql:8.0 镜像（生产推荐）；my.cnf 模板（utf8mb4 / lower_case_table_names=1 / 慢日志）；备份/恢复/导入导出；only_full_group_by 解决；Lost connection 调优。

一、为什么要在 Docker 里跑 MySQL

场景	价值
CI/CD 测试库	每个 Pipeline 干净环境，跑完即弃
多版本并存	5.6 旧系统 + 8.0 新系统一台机器
快速 demo	一行 `docker run` 拉起完整 MySQL
跨平台开发	Mac/Win/Linux 容器化一致
生产	仍建议用云 RDS 或独立机器，Docker 化适合测试 / 演示

生产建议：核心业务用云厂商 RDS（高可用 / 备份 / 监控内置）。Docker 跑 MySQL 用于演示、CI、个人开发。

二、官方镜像启动

2.1 5.6 启动

1
2
3
4
5
6
7


docker run -d -p 3306:3306 --name mysql56 \
 -e MYSQL_ROOT_PASSWORD={{REDACTED}} \
 --restart=always \
 -v /etc/localtime:/etc/localtime:ro \
 --net mynetwork --ip 172.18.0.2 \
 --privileged=true \
 mysql:5.6.30

2.2 5.7 启动

1
2
3
4
5
6
7


docker run -d --name mysql57 \
 --restart=always \
 -p 3308:3306 \
 -e MYSQL_ROOT_PASSWORD=x5 \
 -v /home/old-<your-org>/mysql5.7/conf:/etc/mysql/conf.d \
 -v /home/old-<your-org>/mysql5.7/data:/var/lib/mysql \
 mysql:5.7.43

2.3 8.0 启动（推荐生产用 bitnami）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


docker run -d \
 --name mysql \
 --restart=always \
 --privileged=true \
 -p 3309:3306 \
 -e MYSQL_ROOT_PASSWORD={{REDACTED}} \
 -e TZ=Asia/Shanghai \
 -v /data/docker/mysql/db:/var/lib/mysql \
 -v /data/docker/mysql/conf:/etc/mysql/conf.d \
 mysql:8.0.23 \
 --default-authentication-plugin=mysql_native_password \
 --lower-case-table-names=1

Why --default-authentication-plugin=mysql_native_password？ MySQL 8.0 默认用 caching_sha2_password，老版本客户端（包括 Java 老驱动）连不上。显式指定 native_password 兼容性好。 Why --lower-case-table-names=1？ Linux 默认 0（区分大小写），Windows 默认 1。开发环境跨平台会踩坑，统一设 1 更省事（注意：该参数不能在已有数据上改，需要初始就设）。

2.4 docker-compose 模板

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


version: "3"
services:
 mysql:
 image: <your-public-ip>:13001/base/mysql:8.0.23
 container_name: mysql
 command: --default-authentication-plugin=mysql_native_password --lower-case-table-names=1
 restart: always
 environment:
 MYSQL_ROOT_PASSWORD: {{REDACTED}}
 TZ: Asia/Shanghai
 ports:
 - '3306:3306'
 security_opt:
 - seccomp:unconfined
 volumes:
 - "/data/mysql/db:/var/lib/mysql"
 - "/data/mysql/conf:/etc/mysql/conf.d"
 healthcheck:
 test: ["CMD", "mysqladmin", "ping", "-uroot", "-p{{REDACTED}}"]
 interval: 5s
 timeout: 10s
 retries: 10

三、bitnami/mysql 镜像（生产推荐）

bitnami/mysql 镜像比官方多了：非 root 进程运行、healthcheck、Tini init、健康检查脚本、Redis 风格的环境变量（MYSQL_ROOT_PASSWORD 等都大写）。生产环境推荐用。

3.1 拉取与重打 tag

1
2
3
4


docker pull bitnami/mysql:8.0.39-debian-12-r2
docker tag bitnami/mysql:8.0.39-debian-12-r2 \
 internal.example.com:13001/base/bitnami/mysql:8.0.39-debian-12-r2
docker push internal.example.com:13001/base/bitnami/mysql:8.0.39-debian-12-r2

3.2 my_custom.cnf（utf8mb4 + 大连接数）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


[client]
default-character-set=utf8mb4
[mysql]
default-character-set=utf8mb4
[mysqld]
skip-name-resolve
port = 3307
lower_case_table_names = 1
character-set-server = utf8mb4
secure-file-priv = NULL
default-time-zone = '+08:00'
sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
group_concat_max_len = 4294967295
max_connections = 10000
max_user_connections = 5000
mysqlx_max_connections = 200
interactive_timeout = 28800
wait_timeout = 28800
thread_cache_size = 100
max_allowed_packet = 1G
net_buffer_length = 1M
log_bin_trust_function_creators = 1
binlog_rows_query_log_events = 1
slow_query_log = 1
long_query_time = 3
slow_query_log_file = slow.log

3.3 启动

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


docker run -d \
 --net=host \
 --name mysql8 \
 --restart=always \
 -e MYSQL_ROOT_PASSWORD={{REDACTED}} \
 -e MYSQL_AUTHENTICATION_PLUGIN=mysql_native_password \
 -v /home/docker/mysql8/data:/bitnami/mysql/data \
 -e TZ=Asia/Shanghai \
 -v /home/docker/mysql8/conf/my_custom.cnf:/opt/bitnami/mysql/conf/my_custom.cnf:ro \
 internal.example.com:13001/base/bitnami/mysql:8.0.39-debian-12-r2

关键差异：bitnami 镜像的 datadir 是 /bitnami/mysql/data，不是官方的 /var/lib/mysql。备份恢复命令的路径要对应调整。

3.4 bitnami 容器的 mysql 命令路径

1
2
3
4
5


docker exec -it -u root mysql8 bash

# bitnami 路径
/opt/bitnami/mysql/bin/mysql
/opt/bitnami/mysql/bin/mysqldump

四、备份、恢复、导入

4.1 备份

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 官方镜像
docker exec mysql /usr/bin/mysqldump \
 -u root -p{{REDACTED}} \
 --single-transaction --quick \
 safety_manhole_cover > /data/mysql/bak/safety_manhole_cover.sql

# bitnami 镜像
docker exec mysql8 /opt/bitnami/mysql/bin/mysqldump \
 -u root -p{{REDACTED}} \
 --single-transaction --quick \
 hxl_industry_iot_dev > /home/iot.sql

--single-transaction：InnoDB 的事务一致快照，不影响业务。 --quick：逐行取数据，避免大表 dump 时 OOM。

4.2 恢复（先建库再导入）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 建库
cat << 'EOF' | docker exec -i mysql /usr/bin/mysql -u root --password={{REDACTED}}
DROP DATABASE IF EXISTS `safety_manhole_cover`;
CREATE DATABASE `safety_manhole_cover` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
EOF

# 2. 导入
cat /data/mysql/bak/safety_manhole_cover.sql | \
 docker exec -i mysql /usr/bin/mysql \
 -u root --password={{REDACTED}} \
 safety_manhole_cover

4.3 备份脚本（保留 7 天）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


cat << 'EOF' > /data/mysql/bak.sh
#!/bin/bash
set -e
DATE=$(date +%Y%m%d%H%M%S)
BACK_DATA=iot-${DATE}.sql
BAK_PATH=/data/mysql/bak
mkdir -p ${BAK_PATH}
docker exec mysql /usr/bin/mysqldump \
 -u root -p{{REDACTED}} \
 --single-transaction --quick \
 hxl_chemistry_park_iot > ${BAK_PATH}/$BACK_DATA
find ${BAK_PATH} -name "*.sql" -mtime +7 -print0 | xargs -0 rm -rf
EOF
chmod +x /data/mysql/bak.sh

小坑：Windows 编辑的 .sh 脚本传到 Linux 报 /bin/bash^M: bad interpreter。vim 改文件类型：set ff=unix。

4.4 K8s 中备份

1
2
3


kubectl exec -i "$(kubectl get pods -n <ns> | grep mysql | awk '{print $1}')" \
 -n <ns> -- bash -c \
 "/usr/bin/mysqldump -u root -p'password' <db_name>" > backup.sql

五、常见调优

5.1 解决 `only_full_group_by` 报错

报错信息：

1
2


which is not functionally dependent on columns in GROUP BY clause;
this is incompatible with sql_mode=only_full_group_by

临时解决（重启失效）：

1
2


SELECT @@sql_mode;
SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

永久解决：在 my.cnf 的 [mysqld] 下加：

1

sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

5.2 解决 `Lost connection to MySQL server during query`

通常是大表 dump / 慢查询超过 net_read_timeout：

1
2
3
4


show global variables like '%timeout%';

set global net_read_timeout = 120;
set global net_write_timeout = 900;

5.3 大小写不敏感

1
2
3


show global variables like '%lower_case%';
-- 0: 大小写敏感（Linux 默认）
-- 1: 大小写不敏感（Windows 默认）

在 my.cnf 加：

1

lower_case_table_names = 1

重要：该参数只能在初始化时设，已有数据后改会导致表找不到。

5.4 用户自定义函数 UDF

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 1. 查询插件地址
docker exec -it mysql /bin/bash
mysql -uroot -p
show variables like 'plugin_dir';
-- /usr/lib/mysql/plugin

# 2. 复制 UDF 文件
docker cp ~/libHttpClient.so mysql:/usr/lib/mysql/plugin

# 3. 创建函数
create function http_get RETURNS string soname 'libHttpClient.so';
create function http_post RETURNS string soname 'libHttpClient.so';

# 4. 重启容器生效
docker restart mysql

六、MySQL 5.6 / 5.7 / 8.0 选型速查

维度	5.6	5.7	8.0
发布时间	2013	2015	2018
默认字符集	latin1	utf8mb4	utf8mb4
默认认证	mysql_native_password	mysql_native_password	caching_sha2_password
JSON 支持	弱（需用 TEXT）	原生 JSON 类型	强（JSON_TABLE 函数）
窗口函数	无	无	有
通用表表达式 (CTE)	无	无	有
推荐场景	遗留系统	中间状态（推荐升级到 8.0）	新项目默认
Docker 官方支持	是	是	是

经验法则：

新项目：MySQL 8.0（JSON、窗口函数、CTE 都要）
老系统：先看能不能升级到 8.0；不能的话 5.7（5.6 已 EOL）
测试/演示：用 bitnami/mysql:8.0，省事

七、扩展阅读

MySQL 官方镜像：hub.docker.com/_/mysql
bitnami/mysql：hub.docker.com/r/bitnami/mysql
MySQL 8.0 Release Notes：dev.mysql.com
mysqldump 文档：dev.mysql.com/doc

WordPress 博客快速部署：官方镜像 + 数据持久化 + 反向代理

Fri, 15 Mar 2019 00:00:00 +0800

WordPress 是全球最流行的内容管理系统，官方市场份额常年第一（全球网站 40%+ 跑 WordPress）。虽然静态博客（Hugo/Jekyll）现在很火，但 WordPress 的"开箱即用 + 插件生态 + 后台可视化编辑"对新人和企业站仍是首选。这篇文章讲清楚 WordPress 官方镜像容器化部署、数据持久化、Nginx 反代、备份策略。

阅读对象：想用 WordPress 快速搭博客/企业站、又不想 LAMP 手工搭环境的同学
覆盖范围：WordPress 容器化部署、数据卷持久化、Nginx 反代、HTTPS、备份

一、为什么是 WordPress（容器化）

传统 LAMP 部署 WordPress：

装 Apache/Nginx + PHP + MySQL
配置 PHP-FPM / 虚拟主机
改 wp-config.php 数据库连接
装主题、插件、调权限

每台新机器都要重新走一遍。容器化的好处：

一致性：开发、测试、生产用同一镜像
可移植：服务器迁移只需打包数据卷
升级简单：docker pull wordpress:latest 一行就升级
隔离：和宿主机其他服务不冲突

When to use：需要"内容运营"团队（不熟技术）自己发文章、装插件，WordPress 是首选。如果只是写技术博客，Hugo / Jekyll 等静态博客更省心。

二、容器化部署

2.1 最简启动（SQLite 数据）

1
2
3


docker run -d --restart=always --name wordpress -p 8864:80 \
 -v /home/project/wordpress/data:/var/www/html \
 wordpress

数据卷 /var/www/html：WordPress 全部文件（核心代码 + 上传的媒体 + 主题插件）。挂出来才能持久化。

访问 http://{{HOST}}:8864 进入 WordPress 安装向导。

2.2 配合 MySQL 部署（推荐生产）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


version: "3"
services:
 mysql:
 image: mysql:8.0
 restart: always
 environment:
 MYSQL_ROOT_PASSWORD: {{REDACTED}}
 MYSQL_DATABASE: wordpress
 MYSQL_USER: wordpress
 MYSQL_PASSWORD: {{REDACTED}}
 volumes:
 - mysql_data:/var/lib/mysql
 command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci

 wordpress:
 image: wordpress:latest
 restart: always
 depends_on:
 - mysql
 ports:
 - 8864:80
 environment:
 WORDPRESS_DB_HOST: mysql:3306
 WORDPRESS_DB_USER: wordpress
 WORDPRESS_DB_PASSWORD: {{REDACTED}}
 WORDPRESS_DB_NAME: wordpress
 volumes:
 - wp_data:/var/www/html

volumes:
 mysql_data:
 wp_data:

utf8mb4：MySQL 5.7+ / 8.0 必须用 utf8mb4 字符集，emoji 和中文才不乱码。 depends_on：等 MySQL 起来再启 WordPress（但只保证容器启动顺序，不等 MySQL 完全就绪——WordPress 启动时会重试连接）。

2.3 初始账号

WordPress 安装向导里设置：

站点标题
管理员用户名 / 密码（不要用 admin）
管理员邮箱

生产环境必改：

用户名不要用 admin（机器人会暴力破解）

密码 16+ 位，大小写+数字+符号

邮箱用企业域名（找回密码用）

三、Nginx 反代 + HTTPS

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


server {
 listen 80;
 server_name blog.example.com;

 # HTTP 跳 HTTPS
 return 301 https://$host$request_uri;
}

server {
 listen 443 ssl;
 server_name blog.example.com;

 ssl_certificate /www/cert/blog.example.com/fullchain.pem;
 ssl_certificate_key /www/cert/blog.example.com/privkey.pem;
 ssl_protocols TLSv1.2 TLSv1.3;

 # WordPress 上传文件可能很大
 client_max_body_size 100m;

 location / {
 proxy_pass http://127.0.0.1:8864;
 proxy_set_header Host $http_host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;

 # WordPress 永久链接（pretty permalinks）需要
 try_files $uri $uri/ /index.php?$args;
 }

 # 静态资源直接走 Nginx（性能优化）
 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
 proxy_pass http://127.0.0.1:8864;
 proxy_cache_valid 200 30d;
 expires 30d;
 }
}

try_files 关键：WordPress 用"文章名"做 URL（如 /2019/03/hello-world/），Nginx 必须 fallback 到 index.php，否则 404。 client_max_body_size：WordPress 上传主题/插件可能 50MB+，默认 1M 会 413。

四、WordPress 后台必备设置

4.1 永久链接

Settings → Permalinks → Post name（/%postname%/）。别用默认的 ?p=123，SEO 友好需要路径式 URL。

4.2 媒体上传大小

Nginx：client_max_body_size 100m（如上）

PHP：容器内 php.ini 或 wp-config.php 加：

1
2


@ini_set('upload_max_size', '100M');
@ini_set('post_max_size', '100M');

4.3 安全加固

改默认管理员用户名（不要 admin）
强密码 + 二次验证（Google Authenticator 插件）
限制登录失败次数（Limit Login Attempts Reloaded 插件）
关闭文件编辑（wp-config.php 加 define('DISALLOW_FILE_EDIT', true);）
隐藏 WordPress 版本号（很多 security 插件有这个功能）

4.4 推荐插件

类别	插件	用途
SEO	Yoast SEO / Rank Math	元信息、sitemap、社交分享
缓存	WP Super Cache / W3 Total Cache	静态化提速
安全	Wordfence / Sucuri	WAF、登录保护、扫描
备份	UpdraftPlus / BackWPup	自动备份到 OSS/S3
主题	Astra / GeneratePress	轻量、快、自定义强
编辑器	Classic Editor / Gutenberg	编辑器选择

五、备份策略

5.1 备份什么

数据库（mysqldump）：所有文章、用户、配置
数据卷（wp_data）：主题、插件、上传的媒体
wp-config.php：数据库连接等关键配置

5.2 备份脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


#!/bin/bash
# backup-wordpress.sh
BACKUP_DIR=/backup/wordpress/$(date +%Y%m%d)
mkdir -p $BACKUP_DIR

# 数据库
docker exec mysql_container mysqldump -u wordpress -p{{REDACTED}} wordpress \
 | gzip > $BACKUP_DIR/db.sql.gz

# 数据卷
docker run --rm \
 -v wp_data:/data:ro \
 -v $BACKUP_DIR:/backup \
 alpine tar czf /backup/wp_data.tar.gz /data

echo "Backup done: $BACKUP_DIR"

生产环境：备份同步到 OSS / S3 / 异地机房，本地磁盘挂了不能恢复等于没备份。

六、踩坑清单

上传 413——client_max_body_size 没调，或 PHP upload_max_filesize 太小
固定链接 404——Nginx try_files 没配，或者 .htaccess 没生效
中文乱码——MySQL 没用 utf8mb4 字符集，老库是 latin1
主题/插件升级失败——wp_data 没挂出来，容器升级后回到默认状态
wp-admin 卡顿——没接 CDN/缓存，每次请求都打 WordPress
被刷登录——没装限流插件，admin 用户名太简单被暴力破解

七、2024+ 视角补充

本文写于 2019-03，2024-2026 这几年 WordPress 生态有显著变化：

WordPress 6.x 核心更新：

6.0-6.6（2022-2024）逐步把经典编辑器过渡到全站编辑（Full Site Editing, FSE）+ 块主题（Block Theme），传统 PHP 主题（如 Twenty 系列）模式正在被"块"取代
6.5+ 引入站点字体加载 API（Site Fonts API），前端字体管理不再靠主题 hack
6.6（2024-07）性能大幅提升：首屏 LCP 优化、字体切换不闪屏、插件加载顺序调优

PHP 版本要求：WordPress 6.5+ 最低要求 PHP 7.4，强烈推荐 8.2+（性能提升 30%+）。wordpress:6-php8.3-apache 是 2024+ 生产推荐 tag。

容器化最佳实践更新：

官方镜像 wordpress 2024 年起改用 PHP 8.x + Apache 默认 tag，wordpress:latest 实际跑的是 6.6.x + PHP 8.3。旧的 wordpress:5-apache 还可拉但不收安全补丁
多阶段构建：2024 年生产推荐用 FROM wordpress:6-php8.3-apache + 自定义 wp-content 主题/插件做多阶段，把不可变基础设施原则贯彻
持久化命名约定：从 2019 年的 wp_data 卷，到 2024 年推荐 wp-content、wp-uploads 拆成独立卷——主题/插件更新不影响上传文件

Headless WordPress / WPGraphQL： 2023+ 越来越多团队把 WordPress 当 CMS-only 用（只走 WPGraphQL / REST API 输出 JSON），前端用 Next.js / Nuxt 渲染。好处：复用 WordPress 的后台编辑体验，前端享受现代 SPA/SSG 性能。WPGraphQL 插件 1.16+ 稳定。

反代 / HTTPS 实践变化：

2023 年起 certbot 推荐用 snap 或 docker 化部署（不再 apt install）
Caddy 替代 Nginx 越来越流行：自动 HTTPS（Let’s Encrypt 自动续期）、Caddyfile 配置比 nginx.conf 简洁 50%
WordPress 6.5+ 自带 application passwords 替代传统 API token，更安全

现代化插件栈（2024 推荐）：

类别	旧推荐	2024+ 推荐
缓存	WP Super Cache	WP Rocket（付费）或 LiteSpeed Cache（免费且强）
安全	Wordfence	Solid Security（原 iThemes）
SEO	Yoast SEO	Rank Math（免费 + 高级功能）
静态化	W3 Total Cache	Simply Static（生成纯静态站点）
表单	Contact Form 7	WPForms / Fluent Forms

经验法则更新：内容运营团队 + 简单站点 → WordPress 6.6 + PHP 8.3 + MariaDB 11 + LiteSpeed Cache；纯写技术博客 → Hugo / Astro 仍是更省心选择；API 化集成业务 → Headless WordPress + Next.js。

八、参考资料

WordPress 官方文档：https://wordpress.org/support/
WordPress 6.6 发布说明：https://wordpress.org/news/2024/07/
Docker Hub WordPress：https://hub.docker.com/_/wordpress
WordPress 永久链接：https://wordpress.org/support/article/using-permalinks/
WPGraphQL：https://www.wpgraphql.com/
安全白皮书：https://wordpress.org/about/security/

下一步

想做静态博客？→ 看 Hugo / Hexo 等（本站用的就是 Hugo）
想做密码管理？→ Vaultwarden 自托管密码一文
想做反代网关？→ Nginx 反向代理实战一文

MySQL 用户权限与安全实战：账号、密码、远程连接与排错

Fri, 15 Jun 2018 00:00:00 +0800

为什么写这篇：MySQL 日常 80% 的运维问题都跟"用户/密码/远程连接"有关——ERROR 1130 远程拒绝、root 密码忘了、caching_sha2_password 客户端不兼容、InnoDB 起不来。本文把所有这些场景整理成可复用的 SOP。

适用读者：需要做 MySQL 账号管理、权限分配、生产排错的 DBA / 运维 / 后端。

前置知识：会用 mysql 客户端、了解 user/host 二元组的概念。

1. 账号体系：`user@host` 二元组

MySQL 的账号由 用户名 + 主机 共同决定——root@localhost 和 root@% 是两个独立的账号，密码可以不同。

host 值	含义
`localhost`	仅本地 socket 连接（不走 TCP）
`127.0.0.1`	本地 TCP（不推荐，与 localhost 不同）
`10.0.0.1`	单 IP
`10.0.0.%`	10.0.0 网段
`10.0.0.0/255.255.255.0`	等价于 `10.0.0.%`（MySQL 不支持 CIDR）
`%`	任意 IP（最不安全）
`host1, host2`	多 IP 用逗号分隔

最佳实践：永远不要用 root@%。生产库至少分 3 个账号：

app_readonly@10.0.0.%：业务读账号，只 SELECT

app_rw@10.0.0.%：业务读写账号，限定特定库

dba@10.0.0.%：DBA 管理账号，运维专用

2. 创建用户与授权：GRANT / REVOKE

2.1 创建用户

1
2
3
4
5


-- 标准语法
CREATE USER 'username'@'host' IDENTIFIED BY 'password';

-- 示例
CREATE USER 'app_user'@'%' IDENTIFIED BY '{{REDACTED}}';

MySQL 5.7+ 默认密码策略是 MEDIUM：8 位以上、大小写 + 数字 + 符号。

2.2 授权（GRANT）

1
2


-- 语法：grant 权限 on 库.表 to 'user'@'host'
GRANT ALL PRIVILEGES ON *.* TO 'app_user'@'%' WITH GRANT OPTION;

权限粒度从大到小：

粒度	语法	适用
全局	`.`	DBA / 超级账号
库级	`industry_iot.*`	业务库应用
表级	`industry_iot.risk_task`	极小权限
列级	`(col1, col2)`	极少用（要 INSERT/SELECT 配合）

完整权限列表（按常用度排序）：

1
2
3
4
5


ALL SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD,
SHUTDOWN, PROCESS, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES,
SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE,
REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE,
CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE, CREATE ROLE, DROP ROLE

MySQL 8.0 还多了 动态权限（dynamic privileges）：

1
2
3
4
5
6
7
8


APPLICATION_PASSWORD_ADMIN, AUDIT_ADMIN, BACKUP_ADMIN, BINLOG_ADMIN,
BINLOG_ENCRYPTION_ADMIN, CLONE_ADMIN, CONNECTION_ADMIN, ENCRYPTION_KEY_ADMIN,
FLUSH_OPTIMIZER_COSTS, FLUSH_STATUS, FLUSH_TABLES, FLUSH_USER_RESOURCES,
GROUP_REPLICATION_ADMIN, INNODB_REDO_LOG_ARCHIVE, INNODB_REDO_LOG_ENABLE,
PERSIST_RO_VARIABLES_ADMIN, REPLICATION_APPLIER, REPLICATION_SLAVE_ADMIN,
RESOURCE_GROUP_ADMIN, RESOURCE_GROUP_USER, ROLE_ADMIN, SERVICE_CONNECTION_ADMIN,
SESSION_VARIABLES_ADMIN, SET_USER_ID, SHOW_ROUTINE, SYSTEM_USER,
SYSTEM_VARIABLES_ADMIN, TABLE_ENCRYPTION_ADMIN, XA_RECOVER_ADMIN

2.3 只授 CRUD（推荐生产）

1
2
3
4


-- 业务账号：只允许 CRUD 业务库
GRANT SELECT, INSERT, UPDATE, DELETE
ON industry_iot_dev.*
TO 'app_user'@'10.0.0.%';

2.4 撤销权限

1
2
3
4
5


-- 撤销所有权限 + 授权选项
REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'app_user'@'%';

-- 撤销特定权限
REVOKE INSERT, UPDATE ON industry_iot_dev.* FROM 'app_user'@'10.0.0.%';

2.5 完整流程：创建 + 授权 + 刷新

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


-- 1. 创建用户
CREATE USER 'app_user'@'%' IDENTIFIED BY '{{REDACTED}}';

-- 2. 授权
GRANT SELECT, INSERT, UPDATE, DELETE
ON industry_iot_dev.*
TO 'app_user'@'%';

-- 3. 刷新（必须有）
FLUSH PRIVILEGES;

-- 4. 验证：用新账号登录
-- mysql -h db_host -u app_user -p'{{REDACTED}}' industry_iot_dev

2.6 一次性创建 + 授权（with grant option）

1

GRANT ALL PRIVILEGES ON industry_iot_dev.* TO 'dev'@'%' IDENTIFIED BY '{{REDACTED}}' WITH GRANT OPTION;

MySQL 8.0 已经不支持 GRANT ... IDENTIFIED BY 这种语法——必须先 CREATE USER 再 GRANT。这种"老语法"在 5.7 升级 8.0 时要全部改一遍。

3. 远程连接排错：ERROR 1130

1

ERROR 1130 (HY000): Host 'xxx' is not allowed to connect to this MySQL server

原因：mysql.user 表里没有匹配 client_ip 的账号。

修法（生产推荐）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 1. 用 mysql_native_password 创建远程专用账号
CREATE USER IF NOT EXISTS 'app_user'@'10.0.0.%'
IDENTIFIED WITH mysql_native_password BY '{{REDACTED}}';

-- 2. 授权（限定库，不给全局）
GRANT SELECT, INSERT, UPDATE, DELETE
ON industry_iot_dev.*
TO 'app_user'@'10.0.0.%';

-- 3. 刷新
FLUSH PRIVILEGES;

临时应急（仅测试用）：

1
2
3
4
5


-- 把 root 改成允许任意 IP
CREATE USER IF NOT EXISTS 'root'@'%'
IDENTIFIED WITH mysql_native_password BY '{{REDACTED}}';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

3.1 Navicat 客户端报错

Authentication plugin 'caching_sha2_password' cannot be loaded

→ 改用 mysql_native_password（见下文 §5）。

3.2 客户端连接慢（5+ 秒才连上）

useDNS=no 没设导致反向 DNS 查询慢。在 my.cnf 加：

1
2


[mysqld]
skip-name-resolve

或对 MySQL 5.7+：

1
2
3


[mysqld]
# 关闭反向 DNS 解析
skip-name-resolve

4. root 密码管理：重置 / 找回

4.1 在线改密码（MySQL 5.7+）

1
2
3
4
5
6
7
8


-- 新版本（推荐）
ALTER USER 'root'@'localhost' IDENTIFIED BY '{{REDACTED}}';

-- 远程访问账号
ALTER USER 'root'@'%' IDENTIFIED BY '{{REDACTED}}';

-- 刷新
FLUSH PRIVILEGES;

4.2 旧版本兼容

1
2
3
4
5
6
7
8
9


-- 5.6 / 5.7 老语法
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('{{REDACTED}}');

-- mysql_native_password 兼容
UPDATE user SET authentication_string = SHA1('{{REDACTED}}') WHERE user = 'root';

-- 允许任意 IP
UPDATE user SET host = '%' WHERE user = 'root';
FLUSH PRIVILEGES;

4.3 忘了密码（找回 SOP）

前提：能物理访问服务器 + 有 my.cnf 编辑权限。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


# 1. 停 MySQL
systemctl stop mysqld

# 2. 临时加 skip-grant-tables
vim /etc/my.cnf
# [mysqld]
# skip-grant-tables

# 3. 启动
systemctl start mysqld

# 4. 空密码登录
mysql -uroot

# 5. 清空 root 密码
USE mysql;
FLUSH PRIVILEGES;
UPDATE user SET authentication_string = '' WHERE user = 'root';

# 6. 退出，注释掉 skip-grant-tables
# 7. 重启
systemctl restart mysqld

# 8. 重新登录（空密码）
mysql -uroot

-- 9. 设置新密码
ALTER USER 'root'@'localhost' IDENTIFIED BY '{{REDACTED}}';
ALTER USER 'root'@'%' IDENTIFIED BY '{{REDACTED}}';
FLUSH PRIVILEGES;

4.4 mysqladmin 一行命令

1
2


# 知道旧密码时最快
mysqladmin -uroot -p'{{OLD_PASSWORD}}' password '{{NEW_PASSWORD}}'

5. mysql_native_password vs caching_sha2_password

维度	`mysql_native_password`	`caching_sha2_password`
引入版本	MySQL 5.6 之前	MySQL 8.0（默认）
算法	SHA1	SHA-256 + cache
性能	较好	更快（首次验证后缓存）
安全性	中（SHA1 已不推荐）	高（不传明文密码）
客户端兼容	全平台	8.0+ Connector、5.7.23+ xdevapi

5.1 老客户端不兼容

老版本 Navicat (11/12)、JDBC 5.x、某些 ORM 框架连接时报：

1

Authentication plugin 'caching_sha2_password' cannot be loaded

修法：

1
2
3
4
5
6


-- 单个账号降级
ALTER USER 'app_user'@'10.0.0.%' IDENTIFIED WITH mysql_native_password BY '{{REDACTED}}';
FLUSH PRIVILEGES;

-- 全局默认改成 mysql_native_password
SET GLOBAL default_authentication_plugin = 'mysql_native_password';

新部署的项目应该用 caching_sha2_password——mysql_native_password 是历史包袱。

5.2 全局修改默认认证插件

1
2
3


# /etc/my.cnf
[mysqld]
default_authentication_plugin = caching_sha2_password

改了之后已存在的用户不受影响，要批量改可以导出现有用户再 SET GLOBAL 重设。

6. InnoDB 启动崩溃：6 级 force_recovery

现象：

1
2
3
4


[InnoDB] Unable to lock ./undo_001 error: 11
2025-01-03T02:52:18 [ERROR] [MY-012562] [InnoDB] We scanned the log up to ...
InnoDB: Assertion failure: log0log.cc:657:first_rec_group <= start_lsn - block_lsn
InnoDB: We intentionally generate a memory trap.

6.1 紧急修法

1
2
3


# 1. 把有问题的 undo 文件备份
mv undo_001 undo_001.bak
cp -a undo_001.bak undo_001

6.2 force_recovery 6 级

1
2
3


# /etc/my.cnf
[mysqld]
innodb_force_recovery = 6

值	含义	影响
1 (SRV_FORCE_IGNORE_CORRUPT)	忽略 corrupt 页	可能丢数据
2 (SRV_FORCE_NO_BACKGROUND)	阻止主线程 full purge	crash 风险
3 (SRV_FORCE_NO_TRX_UNDO)	不执行事务回滚	丢未提交事务
4 (SRV_FORCE_NO_IBUF_MERGE)	不执行插入缓冲合并	性能降
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)	不看重做日志	丢未提交事务
6 (SRV_FORCE_NO_LOG_REDO)	不执行前滚	最后手段

使用原则：从 1 开始逐级试，能起来就用。6 起来后第一件事 mysqldump 全量导出——之后用正常模式重建库。

7. 字符集与排序规则最佳实践

7.1 建库时统一 utf8mb4

1
2
3


CREATE DATABASE industry_iot_dev
DEFAULT CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

7.2 建表时显式声明

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


CREATE TABLE risk_task (
 id INT PRIMARY KEY AUTO_INCREMENT,
 name VARCHAR(64)
 CHARACTER SET utf8mb4
 COLLATE utf8mb4_general_ci
 NOT NULL DEFAULT '',
 -- ...
) ENGINE = InnoDB
 DEFAULT CHARSET = utf8mb4
 COLLATE = utf8mb4_unicode_ci;

7.3 utf8 vs utf8mb4

字符集	最大字符长度	实际能存
`utf8` (MySQL 早期别名)	3 字节	不支持 emoji、部分生僻字
`utf8mb4` (MySQL 5.5.3+)	4 字节	支持 emoji、所有 Unicode

铁律：MySQL 的 utf8 不是真 utf8。新库必须用 utf8mb4。

7.4 排序规则

Collation	特点
`utf8mb4_general_ci`	速度快，不严格按 Unicode 排序
`utf8mb4_unicode_ci`	按 Unicode 标准排序，推荐
`utf8mb4_bin`	按二进制比较（区分大小写）
`utf8mb4_0900_ai_ci`	MySQL 8.0 新 UCA 9.0 算法（默认）

建议：通用场景用 utf8mb4_unicode_ci（8.0 之前）或 utf8mb4_0900_ai_ci（8.0+）。

经验总结

主题	关键 SOP
新用户	`CREATE USER` + `GRANT` + `FLUSH PRIVILEGES`
远程连接	不用 `root@%`；建 `app_user@10.0.0.%` 限定网段
密码忘了	`skip-grant-tables` + 清空密码 + 重设
caching_sha2 兼容	改用 `mysql_native_password`
InnoDB 崩了	`innodb_force_recovery=1~6` 逐级试，6 起来立刻全量导出
字符集	永远 `utf8mb4_unicode_ci`

下一步

MySQL 索引优化：见《MySQL 索引优化实战》
EXPLAIN + SQL 题解：见《MySQL 实战速查》
实时同步 Canal/Debezium：见《MySQL 实时同步实战》

Java 面试合集：MySQL 事务与索引

Thu, 15 Mar 2018 00:00:00 +0800

本文写于 2018 年 3 月——MySQL 5.7 主流，MySQL 8.0 即将发布（2018-04），InnoDB 全面替代 MyISAM。

一、事务基础特性 ACID

1.1 ACID 定义

特性	描述	实现
A 原子性	一个事务中的操作要么全部成功，要么全部失败	Undo Log 回滚日志
C 一致性	数据库总是从一个一致性的状态转换到另外一个一致性的状态	应用层 + 完整性约束（主键/外键/唯一键）
I 隔离性	一个事务的修改在最终提交前，对其他事务是不可见的	锁 + MVCC
D 持久性	一旦事务提交，所做的修改就会永久保存到数据库中	Redo Log

1.2 ACID 靠什么保证

A 原子性：由 undo log 日志保证，它记录了需要回滚的日志信息，事务回滚时撤销已经执行成功的 sql

C 一致性：一般由代码层面来保证

I 隔离性：由 MVCC 来保证

D 持久性：由内存 + redo log 来保证。mysql 修改数据同时在内存和 redo log 记录这次操作，事务提交的时候通过 redo log 刷盘，宕机的时候可以从 redo log 恢复

二、数据库三大范式

2.1 三范式定义

第一范式（1NF）：确保每列保持原子性，列不可再分。如地址可以再分成省/市/区/街道。

第二范式（2NF）：确保表中的每列都和主键相关，行可以唯一区分，主键约束。

第三范式（3NF）：确保每列都和主键列直接相关（而不是间接相关），外键约束。这里可以反范式做冗余。

范式是一级一级依赖的。

2.2 面试追问

Q1：反范式是反什么？

反范式 = 故意冗余字段，用空间换查询性能。

典型反范式场景：

订单表冗余用户姓名（避免 JOIN 用户表）
评论表冗余文章标题（避免 JOIN 文章表）
汇总表冗余明细数据（避免 GROUP BY）

Q2：什么场景用范式？什么场景用反范式？

OLTP（联机事务）：用范式（写多读少，节省空间）
OLAP（联机分析）：用反范式（读多写少，提升查询速度）

三、InnoDB vs MyISAM

3.1 对比

维度	InnoDB	MyISAM
事务支持	✓	✗
锁机制	行级/表级锁	表级锁
外键约束	✓	✗
崩溃恢复	强大（Redo log + Undo log）	无事务日志
存储结构	聚集索引（数据文件和索引绑定）	非聚集索引（数据文件分离）
性能特点	写操作效率高	低并发下简单查询快

3.2 选型建议

以前很多人推荐 MyISAM 的理由是"它只读性能好"或者"它支持全文索引（Full-text Index）"。但随着 MySQL 的演进，InnoDB 从 5.6 开始就已经支持了全文索引，并且在多核 CPU 和大内存的现代服务器上，InnoDB 的读写综合性能与并发吞吐量已经全面超越了 MyISAM。

100% 选择 InnoDB：绝大多数常规业务、高并发系统、需要保证数据不丢不脏的系统

极少数考虑 MyISAM：完全不需要事务、极高比例的纯读取、对服务器内存极其苛刻的小型只读报表、或是临时的数据分析物理表

四、事务隔离级别

4.1 四大隔离级别

隔离级别	描述
未提交读（READ UNCOMMITTED）	事务中的修改，即使没有提交，对其它事务也是可见的
提交读（READ COMMITTED）	一个事务只能读取已经提交的事务所做的修改
可重复读（REPEATABLE READ）	保证在同一个事务中多次读取同样数据的结果是一样的（MySQL 默认）
可串行化（SERIALIZABLE）	强制事务串行执行

4.2 并发问题

隔离级别	脏读	不可重复读	幻影读
未提交读	✓	✓	✓
提交读	✗	✓	✓
可重复读	✗	✗	✓（MySQL InnoDB 通过间隙锁部分解决）
可串行化	✗	✗	✗

4.3 MySQL 默认隔离级别

1
2
3
4
5
6


-- 查看当前隔离级别
SELECT @@transaction_isolation; -- MySQL 8
SELECT @@tx_isolation; -- MySQL 5.x

-- 设置隔离级别
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

五、SQL 优化的 19 条军规

5.1 索引相关（10 条）

对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描。
应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。
应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描。
in 和 not in 也要慎用，否则会导致全表扫描。
like 的查询也可能导致全表扫描：若要提高效率，可以考虑全文检索。
如果在 where 子句中使用参数，也会导致全表扫描。因为 SQL 只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。
应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。
应尽量避免在 where 子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。
不要在 where 子句中的"=“左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

5.2 复合索引（1 条）

在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能地让字段顺序与索引顺序相一致。

5.3 写入相关（2 条）

不要写一些没有意义的查询，如需要生成一个空表结构。
Update 语句，如果只更改 1、2 个字段，不要 Update 全部字段，否则频繁调用会引起明显的性能消耗，同时带来大量日志。

5.4 JOIN 相关（1 条）

对于多张大数据量（这里几百条就算大了）的表 JOIN，要先分页再 JOIN，否则逻辑读会很高，性能很差。

5.5 COUNT 相关（1 条）

select count(*) from table 这样不带任何条件的 count 会引起全表扫描，并且没有任何业务意义，是一定要杜绝的。

5.6 索引数量（1 条）

索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引。一个表的索引数最好不要超过 6 个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。

5.7 物理顺序（1 条）

应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。

5.8 数据类型（2 条）

尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
尽可能的使用 varchar/nvarchar 代替 char/nchar，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。

六、索引原理

6.1 B+ Tree 索引结构

InnoDB 默认使用 B+ Tree 索引：

1
2
3
4
5


 [50, 100]
 / | \
 [10,30] [50,70] [80,100]
 / | \ / | \ / | \
 [叶子节点链表]

特点：

叶子节点才存储数据（聚簇索引）或主键（二级索引）
所有叶子节点形成有序链表（范围查询友好）
非叶子节点只存索引键
每个节点大小 = 16KB（默认 page size）

6.2 聚簇索引 vs 二级索引

维度	聚簇索引（Clustered）	二级索引（Secondary）
数量	每表 1 个	多个
数据存储	叶子节点存完整行数据	叶子节点存主键
查找二级索引	需要回表	-

6.3 EXPLAIN 关键字段

1

EXPLAIN SELECT * FROM user WHERE name = 'foo';

字段	含义
id	查询序号
select_type	SIMPLE / PRIMARY / SUBQUERY / DERIVED
type	system / const / eq_ref / ref / range / index / ALL（至少要 range）
possible_keys	可能使用的索引
key	实际使用的索引
key_len	索引使用字节数
rows	预估扫描行数
Extra	额外信息（Using index / Using where / Using filesort / Using temporary）

关键 type 取值：

type	含义	性能
system	表中只有一行	最优
const	主键 / 唯一索引等值	优
eq_ref	JOIN 唯一索引	优
ref	非唯一索引等值	良
range	范围扫描	中
index	全索引扫描	差
ALL	全表扫描	极差

七、写在最后

MySQL 面试要点：

基础：ACID 实现原理、隔离级别、InnoDB vs MyISAM

索引：B+ Tree 结构、聚簇索引 vs 二级索引、Explain 字段

优化：19 条 SQL 优化军规、慢查询排查

进阶：MVCC 实现、锁机制（行锁 / 间隙锁 / 临键锁）

参考资料

Windows 数据库实战合集：MySQL/Redis/Elasticsearch/SQLite/Navicat 安装与连接

Fri, 15 Sep 2017 00:00:00 +0800

一、为什么要在 Windows 上跑数据库

生产用 Linux——但学习 / 调试 / 离线场景，Windows 本地数据库仍是开发机标配：

MySQL 8 / Redis 5 —— 本地调试 / 单元测试 / 学习
Elasticsearch 8 —— 全文搜索 / 日志分析
SQLite —— 嵌入式场景（Python 内置 sqlite3 模块）
Navicat —— 跨数据库 GUI，连接本机 + 远程

本文避开 Docker（Windows Docker Desktop 重，本地跑裸进程更快），全部用 ZIP / MSI 解压即装的方式。

二、MySQL 8.0 安装

2.1 下载 MySQL Installer

官方：https://downloads.mysql.com/archives/installer/
推荐版本：MySQL Installer Community 8.0.28.0（2022 时代经典）

MySQL Installer 是 .msi，含 Server + Workbench + Shell + Connector/NET 一站式安装。

2.2 静默安装（推荐）

1
2
3
4
5


# 企业版
msiexec /i mysql-installer-community-8.0.28.0.msi /qn

# 自定义安装路径
msiexec /i mysql-installer-community-8.0.28.0.msi INSTALLDIR="D:\soft\MySQL" /qn

2.3 配置 my.ini

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


[mysqld]
basedir=D:/soft/MySQL
datadir=D:/data/MySQL
port=3306
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci
default-authentication-plugin=mysql_native_password

[client]
default-character-set=utf8mb4

2.4 初始化数据目录

1
2


cd D:\soft\MySQL\bin
mysqld --initialize-insecure --user=mysql

--initialize-insecure：root 密码为空（开发机推荐），生产用 --initialize 会生成随机密码到 data\xxx.err。

2.5 启动 MySQL

1
2
3
4
5
6


# 命令行启动
D:\soft\MySQL\bin\mysqld --console

# 注册成 Windows 服务
D:\soft\MySQL\bin\mysqld --install MySQL8 --defaults-file="D:\soft\MySQL\my.ini"
net start MySQL8

2.6 修改 root 密码

1
2


ALTER USER 'root'@'localhost' IDENTIFIED BY 'your_new_password';
FLUSH PRIVILEGES;

三、Redis 5.0 安装

3.1 下载

tporadowski/redis 维护的 Windows 版 Redis（官方 Windows 版停更）
5.0.14.1：https://github.com/tporadowski/redis/releases/download/v5.0.14.1/Redis-x64-5.0.14.1.zip
6.x / 7.x 也都有，2018-2023 持续维护

3.2 解压即用

1
2
3


# 解压到 D:\portable\Redis-x64-5.0.14.1
cd D:\portable\Redis-x64-5.0.14.1
redis-server.exe redis.windows.conf

3.3 客户端连接

1
2
3
4
5
6
7


# 默认 6379 端口
redis-cli.exe -h 127.0.0.1 -p 6379

# 测试
> set myKey abc
> get myKey
"abc"

3.4 注册成 Windows 服务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 安装服务
redis-server.exe --service-install redis.windows.conf --loglevel verbose

# 启动服务
redis-server.exe --service-start

# 停止服务
redis-server.exe --service-stop

# 卸载服务
redis-server.exe --service-uninstall

3.5 配置密码

redis.windows.conf：

1

requirepass your_redis_password

客户端：

1

redis-cli -a your_redis_password

注意：Redis 6+ 才支持 ACL（多用户多权限），5.0 仍是单密码模式。

四、Elasticsearch 8.x 安装

4.1 下载

官方：https://www.elastic.co/cn/downloads/elasticsearch
8.2.2 Windows 版：https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.2.2-windows-x86_64.zip
历史版本：https://www.elastic.co/cn/downloads/past-releases#elasticsearch

4.2 解压

1
2


# 推荐解压到 D 盘
Expand-Archive elasticsearch-8.2.2-windows-x86_64.zip -DestinationPath D:\portable\

4.3 启动 ES

D:\portable\elasticsearch-8.2.2\config\elasticsearch.yml 末尾加：

1

xpack.ml.enabled: false

关掉 X-Pack ML，避免内存溢出（默认开启会占 1G+ 内存）。

启动：

1

D:\portable\elasticsearch-8.2.2\bin\elasticsearch.bat

第一次启动输出：

1
2
3
4
5
6
7
8


-> Elasticsearch security features have been automatically configured!
-> Authentication is enabled and cluster connections are encrypted.

-> Password for the elastic user (reset with `bin/elasticsearch-reset-password -u elastic`):
 SCzC_tXNopid7eKBVp0n

-> HTTP CA certificate SHA-256 fingerprint:
 74bbe5528b8e1c66539cb8cc8aff1bb624970694e9e55578a7ecbbd6ac60fe1f

SCzC_tXNopid7eKBVp0n 就是 elastic 用户的初始密码——记下来！

4.4 改密码

1

D:\portable\elasticsearch-8.2.2\bin\elasticsearch-reset-password -u elastic -i

4.5 访问

1
2


# 默认 https://localhost:9200
curl -k -u elastic:your_password https://localhost:9200/

-k 是忽略 TLS 证书（ES 8 默认开启 TLS）。

4.6 Kibana 配套

Kibana 8.2.2：https://artifacts.elastic.co/downloads/kibana/kibana-8.2.2-windows-x86_64.zip
解压到 D:\portable\kibana-8.2.2
启动 bin\kibana.bat
访问 http://localhost:5601

五、SQLite 解压即用

5.1 下载

官方：https://www.sqlite.org/download.html
2022 版：sqlite-dll-win64-x64-3380500.zip + sqlite-tools-win32-x86-3380500.zip

5.2 部署

1
2
3
4


# 解压到 D:\portable\sqlite3
md D:\portable\sqlite3
Expand-Archive sqlite-dll-win64-x64-3380500.zip -DestinationPath D:\portable\sqlite3
Expand-Archive sqlite-tools-win32-x86-3380500.zip -DestinationPath D:\portable\sqlite3

5.3 配置环境变量

1

PATH += D:\portable\sqlite3

5.4 启动

1

Win+R → wt → sqlite3

输出：

1
2
3
4
5


SQLite version 3.38.5 2022-05-06 15:25:27
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite>

5.5 常用命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


-- 打开数据库文件
.open mydata.db

-- 列出所有表
.tables

-- 显示表结构
.schema users

-- 退出
.exit

-- .help 看所有元命令
.help

5.6 Python 内置

1
2
3
4
5
6
7
8


import sqlite3

conn = sqlite3.connect('mydata.db')
cur = conn.cursor()
cur.execute('SELECT * FROM users LIMIT 5')
for row in cur.fetchall():
 print(row)
conn.close()

六、Navicat 连接 SQL Server

6.1 安装 SQL Server Native Client 2012

Navicat 早期版本连接 SQL Server 需要 Microsoft® SQL Server® 2012 Native Client：

下载：https://www.microsoft.com/zh-cn/download/confirmation.aspx?id=50402
Navicat 16+ 已经自带驱动

6.2 新建连接

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


1. 打开 Navicat
2. "连接" → 选 "SQL Server"
3. 主机: localhost / 192.168.x.x / <HOST>,1433
4. 验证: SQL Server 验证
5. 用户名: sa
6. 密码: ********
7. 数据库: 选 <默认> / 指定
8. 高级 → 排序规则: Chinese_PRC_CI_AS
9. 高级 → 恢复模式: SIMPLE
10. 高级 → 兼容级别: 100（SQL Server 2008 兼容）
11. 测试连接

6.3 关键参数说明

参数	含义	推荐值
排序规则	字符集 / 排序规则	`Chinese_PRC_CI_AS`（中文不区分大小写）
恢复模式	FULL / SIMPLE / BULK_LOGGED	SIMPLE（开发机省空间）
兼容级别	模拟老 SQL Server 版本	100（2008）/ 110（2012）/ 130（2016）
加密	是否 TLS	Force Encryption = False（开发机省事）

七、跨数据库 GUI 工具对比

工具	出品方	跨数据库	价格	推荐度
Navicat Premium	卓码（香港）	MySQL/MSSQL/Oracle/PostgreSQL/SQLite/MongoDB/Redis	商业付费	老牌经典
DBeaver Community	社区	几乎所有数据库	免费开源	2020+ 主流
DataGrip	JetBrains	几乎所有数据库	商业付费	IDE 体验
HeidiSQL	德国开发者	MySQL/MSSQL/PostgreSQL	免费开源	MySQL 经典
TablePlus	独立开发者	MySQL/PostgreSQL/SQLite/Redis/MongoDB	商业付费（Mac/Win）	Mac 设计感
Apifox	国产	API 设计 + Mock + 调试 + 文档	个人版免费	2020+ 新派

建议：

白嫖 → DBeaver Community
重度 MySQL → Navicat Premium
IDE 用户 → DataGrip
Mac 用户 → TablePlus

八、Windows 防火墙与端口

数据库本地跑没问题，但远程连接要开防火墙：

8.1 放行 MySQL 3306

1

New-NetFirewallRule -DisplayName "MySQL 3306" -Direction Inbound -LocalPort 3306 -Protocol TCP -Action Allow

8.2 放行 Redis 6379

1

New-NetFirewallRule -DisplayName "Redis 6379" -Direction Inbound -LocalPort 6379 -Protocol TCP -Action Allow

8.3 放行 Elasticsearch 9200

1

New-NetFirewallRule -DisplayName "ES 9200" -Direction Inbound -LocalPort 9200 -Protocol TCP -Action Allow

生产环境：不要直接把数据库端口暴露公网——走 SSH 隧道或 VPN。

九、性能调优

9.1 MySQL

配置 innodb_buffer_pool_size = 物理内存的 50-70%
启用慢查询日志：slow_query_log = 1，long_query_time = 2
使用 EXPLAIN 分析慢 SQL

9.2 Redis

最大内存：maxmemory 2gb
淘汰策略：maxmemory-policy allkeys-lru（通用 LRU）
持久化：开发机关 RDB / AOF，生产开 AOF

9.3 Elasticsearch

Xms / Xmx JVM 堆内存：建议设成一样大
堆内存 ≤ 物理内存的 50%（留 50% 给 OS 文件缓存）
避免大文档 + 避免深度分页

十、常见 5 个坑

MySQL 8 默认 caching_sha2_password——老客户端连不上，改 mysql_native_password
Redis Windows 5.0 默认无密码——生产必设 requirepass
Elasticsearch 8 默认开 TLS + 强制密码——第一次启动会输出初始密码，记不住就 elasticsearch-reset-password
SQLite 数据库文件并发写会锁——多写场景不要用 SQLite
Navicat 12 之前的版本连 SQL Server 2016+ 报错——升级到 Navicat 16+

十一、总结

MySQL 8 —— mysqld --initialize-insecure 初始化 + mysqld --install 注册服务
Redis 5/6 —— tporadowski 维护版解压即用，生产必设密码
Elasticsearch 8 —— 8.x 默认开 TLS，第一次启动的 elastic 密码要记
SQLite —— Python 内置，开发机首选
Navicat —— 跨数据库 GUI，经典老牌；白嫖首选 DBeaver
生产环境：数据库别直接暴露公网——走 SSH 隧道 / VPN

参考资料

MySQL 实时同步实战：Canal + Debezium + Kafka Connect 全家桶

Thu, 15 Jun 2017 00:00:00 +0800

为什么写这篇：MySQL 实时同步有两条主流路径——应用层（Canal / Maxwell 解 binlog → 自定义消费者）和CDC 标准（Debezium → Kafka Connect → JDBC Sink）。前者灵活但要写代码，后者标准但坑点多。本文把两条路都走一遍，重点写真实环境的配置和报错。

适用读者：需要做 MySQL → MySQL/PG/ES 实时同步的中间件开发、DBA。

前置知识：了解 MySQL binlog、知道 Kafka 是什么、能用 docker 跑容器。

1. 同步方案对比：Canal vs Debezium vs Flink CDC

维度	Canal	Debezium	Flink CDC
厂商	Alibaba	Red Hat / Decodable	Apache
协议	自定义 TCP / Kafka / RocketMQ	Kafka Connect（标准）	Flink SQL（标准）
部署	canal-server + canal-adapter	Connect + Source/Sink Connector	Flink Job
转换能力	adapter 内置 ES/HBase/MySQL	需配 Sink，转换靠 SMT	SQL 表达
优点	文档全、中文社区、Java 友好	标准化、生态广	流式计算能力强
缺点	强耦合阿里系	K8s 集成较新	重型，要 Flink 集群
适用	中小规模同步、阿里系架构	大规模、跨团队标准化	实时数仓 + 流计算

选型建议：

数据量 < 10 万 QPS，且目标库固定：选 Canal

跨团队、多源异构（MySQL + PG + Mongo + Oracle）：选 Debezium

要做聚合、JOIN、流式 ETL：选 Flink CDC

2. Canal：基于 binlog 解析的轻量同步

2.1 架构

1
2
3
4
5
6
7


MySQL master
 │ binlog ROW
 ▼
canal-server ← 模拟 MySQL slave 协议
 │ CanalTSDB / MQ
 ▼
canal-adapter ← 消费 + 转换 + 写目标库（ES/HBase/MySQL）

2.2 Docker 部署

1
2
3


docker pull canal/canal-server:latest
docker pull slpcat/canal-adapter:v1.1.5-jdk8
docker pull canal/canal-admin:latest

2.3 MySQL 前置配置

1
2
3
4
5


# /etc/my.cnf
[mysqld]
log-bin=mysql-bin
binlog-format=ROW # 必须 ROW
server_id=6 # 主从唯一

1
2
3
4
5
6


-- 给 canal 专用账号
CREATE USER canal IDENTIFIED BY 'canal';
GRANT SELECT, INSERT, UPDATE, DELETE, ALTER, DROP,
 REPLICATION SLAVE, REPLICATION CLIENT
ON *.* TO 'canal'@'%';
FLUSH PRIVILEGES;

2.4 canal-admin（Web 管理）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# 1. 启动临时 admin 把配置导出来
docker run --name canal-admin -d canal/canal-admin:latest
docker exec -it canal-admin bash
# 配置目录：/home/admin/canal-admin/conf/

# 2. 拷贝配置到宿主机
docker cp canal-admin:/home/admin/canal-admin/conf /home/docker/canal/admin

# 3. 修改 application.yml 配置 MySQL
vim /home/docker/canal/admin/conf/application.yml
# datasource:
# url: jdbc:mysql://internal.example.com:3306/canal_manager
# username: canal
# password: {{REDACTED}}

# 4. 初始化 SQL（canal-1.1.6+）
# https://github.com/alibaba/canal/blob/canal-1.1.6/admin/admin-web/src/main/resources/canal_manager.sql

# 5. 删除临时容器，重启正式容器
docker rm -f canal-admin
docker run -d --name canal-admin --restart=always \
 -p 8089:8089 \
 -v /home/docker/canal/admin/conf:/home/admin/canal-admin/conf \
 -v /home/docker/canal/admin/logs:/home/admin/canal-admin/logs \
 canal/canal-admin:latest

Web 地址：http://internal.example.com:8089，默认账号 admin/123456。

2.5 canal-server 启动

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


# 1. 拷贝配置
docker run --name canal-server -d canal/canal-server:v1.1.5
docker exec -it canal-server bash
docker cp canal-server:/home/admin/canal-server/conf /home/docker/canal/server
docker rm -f canal-server

# 2. 修改 instance.properties（指定监听的库）
vim /home/docker/canal/server/conf/example/instance.properties
# canal.instance.master.address=internal.example.com:3306
# canal.instance.dbUsername=canal
# canal.instance.dbPassword=canal

# 监听多个库：canal.properties
vim /home/docker/canal/server/conf/canal.properties
# canal.destinations = example,example2,example3

# 3. 启动
docker run -d --name canal-server --restart=always \
 -p 11110:11110 -p 11111:11111 -p 11112:11112 -p 9100:9100 \
 -v /home/docker/canal/server/conf:/home/admin/canal-server/conf \
 -v /home/docker/canal/server/logs:/home/admin/canal-server/logs \
 canal/canal-server:latest

2.6 canal-adapter 启动

1
2
3
4
5
6
7
8
9


# 拷贝 adapter 配置
docker run --name canal-adapter -d slpcat/canal-adapter:v1.1.5
docker cp canal-adapter:/opt/canal-adapter/conf/application.yml /home/docker/canal/adapter
docker cp canal-adapter:/opt/canal-adapter/conf/rdb/mytest_user.yml /home/docker/canal/adapter/rdb

# 启动
docker run -d --name canal-adapter -p 8081:8081 \
 -v /home/docker/canal/adapter:/opt/canal-adapter/conf \
 slpcat/canal-adapter:v1.1.5

坑点：canal-adapter 官方 JDK 镜像兼容性差，生产建议用自定义镜像（lwd/jdk:8u371）。

3. Debezium：CDC 标准的工业级实现

3.1 三种部署方式

方式	适用
Kafka Connect（推荐）	生产环境，标准化、可观测性最好
Debezium Server	不想维护 Kafka 时，单独的应用
Embedded Engine	应用代码里嵌入 Debezium（自定义流）

3.2 Kafka Connect 部署

1
2
3
4
5


mkdir -p /home/docker/debezium/2.5.4/
cd /home/docker/debezium/2.5.4/

# docker-compose.yaml 启动 Zookeeper + Kafka + Connect + UI
docker-compose up -d

K8s 上可以参考 Strimzi 项目（包含 Kafka/Kafka Connect/Topic/User 三个 Operator）。

3.3 关键配置：调大消息体

默认 Kafka 消息体 1MB，大表 UPDATE/INSERT 必报：

1
2


The message is 2554545 bytes when serialized which is larger than 1048576,
which is the value of the max.request.size configuration.

修法（kafka 端）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# docker-compose.yaml
kafka:
 environment:
 - KAFKA_MESSAGE_MAX_BYTES=1048576000
 - KAFKA_MAX_REQUEST_SIZE=1048576000
 - KAFKA_PRODUCER_MAX_REQUEST_SIZE=1048576000

connect:
 environment:
 - CONNECT_MESSAGE_MAX_BYTES=1048576000
 - CONNECT_MAX_REQUEST_SIZE=1048576000
 - CONNECT_PRODUCER_MAX_REQUEST_SIZE=1048576000

坑点：直接在容器内改 server.properties 不会生效，必须通过环境变量注入——这是无数人踩过的坑。

3.4 注册 Source Connector（监听 MySQL）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


# 1. 注册 MySQL 源
curl -i -X POST -H "Content-Type: application/json" \
 http://localhost:28083/connectors/ -d '
{
 "name": "source-hnDev",
 "config": {
 "connector.class": "io.debezium.connector.mysql.MySqlConnector",
 "tasks.max": "1",
 "topic.prefix": "hnDev",
 "database.hostname": "internal.example.com",
 "database.port": "3306",
 "database.user": "root",
 "database.password": "{{REDACTED}}",
 "database.server.id": "1",
 "database.include.list": "industry_iot",
 "snapshot.mode": "SCHEMA_ONLY",
 "snapshot.locking.mode": "none",
 "tombstones.on.delete": "false",
 "schema.history.internal.kafka.topic": "history.hnDev.industry_iot",
 "schema.history.internal.kafka.bootstrap.servers": "kafka:9092",
 "time.precision.mode": "connect",
 "database.serverTimezone": "Asia/Shanghai"
 }
}'

# 2. 验证
curl http://10.0.0.127:28083/connectors/source-hnDev/status

snapshot.mode 4 种模式：

值	行为	适用
`initial`（默认）	先全量快照，之后持续订阅 binlog	首次接入
`initial_only`	只做全量快照	一次性数据迁移
`schema_only`	只同步 schema（不导数据），但持续订阅 DML	已有数据，只关心后续变更
`schema_only_recovery`	仅恢复 schema history topic（不导数据）	灾难恢复

关键区别：initial 会把表所有数据先读一遍写入 topic；schema_only 不读数据只读 schema history。DML 是 binlog 持续订阅，与 snapshot 无关。

3.5 常用管理 API

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# 列出所有连接器
curl -s http://internal.example.com:8083/connectors

# 查看某个连接器状态
curl -s http://internal.example.com:8083/connectors/inventory-connector/status

# 查看连接器配置
curl -s http://internal.example.com:8083/connectors/inventory-connector/config

# 暂停
curl -s -X PUT http://internal.example.com:8083/connectors/inventory-connector/pause

# 恢复
curl -s -X PUT http://internal.example.com:8083/connectors/inventory-connector/resume

# 重启
curl -s -X PUT http://internal.example.com:8083/connectors/inventory-connector/resume

# 删除
curl -s -X DELETE http://internal.example.com:8083/connectors/inventory-connector

4. JDBC Sink Connector：写入目标库

4.1 准备 Sink Connector JAR

Debezium Connect 自带 Source Connector（MySQL/PG/Mongo/Oracle/SQL Server/Db2），但 Sink Connector 需要自己注册：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 1. 进 connect 容器建目录
docker exec -it connect bash
mkdir -p /kafka/connect/kafka-connect-jdbc
exit

# 2. 下载 kafka-connect-jdbc JAR
wget https://packages.confluent.io/maven/io/confluent/kafka-connect-jdbc/10.7.4/kafka-connect-jdbc-10.7.4.jar

# 3. 拷贝进 connect 容器
docker cp kafka-connect-jdbc-10.7.4.jar connect:/kafka/connect/kafka-connect-jdbc

# 4. 必须同时拷 MySQL JDBC 驱动（否则 sink 报 No suitable driver found）
docker cp mysql-connector-java-8.0.23.jar connect:/kafka/connect/kafka-connect-jdbc

# 5. 重启 connect 让新插件加载
docker restart connect

4.2 注册 Sink（同步多张表）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


curl -i -X POST -H "Content-Type: application/json" \
 http://localhost:28083/connectors/ -d '
{
 "name": "sink-prod-hnDev",
 "config": {
 "connector.class": "io.confluent.connect.jdbc.JdbcSinkConnector",
 "tasks.max": "1",
 "topics": "hnDev.industry_iot.risk_task,hnDev.industry_iot.risk_object,hnDev.industry_iot.risk_unit",
 "connection.url": "jdbc:mysql://internal.example.com:3306/industry_iot_prod?characterEncoding=utf-8&autoReconnect=true",
 "connection.user": "root",
 "connection.password": "{{REDACTED}}",
 "key.converter.encoding": "UTF-8",
 "value.converter.encoding": "UTF-8",
 "pk.mode": "record_key",
 "insert.mode": "upsert",
 "delete.enabled": "true",
 "batch.size": "3000",
 "auto.create": "true",
 "auto.evolve": "true",
 "transforms": "dropPrefix,ExtractField,tsFormat1",
 "transforms.ExtractField.type": "org.apache.kafka.connect.transforms.ExtractField$Value",
 "transforms.ExtractField.field": "after",
 "transforms.tsFormat1.type": "org.apache.kafka.connect.transforms.TimestampConverter$Value",
 "transforms.tsFormat1.target.type": "string",
 "transforms.tsFormat1.field": "create_time,modify_time",
 "transforms.tsFormat1.format": "yyyy-MM-dd HH:mm:ss",
 "transforms.dropPrefix.type": "org.apache.kafka.connect.transforms.RegexRouter",
 "transforms.dropPrefix.regex": "hnDev.industry_iot.(.*)",
 "transforms.dropPrefix.replacement": "$1",
 "errors.tolerance": "all",
 "errors.deadletterqueue.topic.name": "hn-dev-errors",
 "errors.deadletterqueue.context.headers.enable": "true",
 "errors.log.enable": "true"
 }
}'

4.3 关键参数解读

参数	含义
`pk.mode=record_key`	用 topic key 作为目标表主键（必须有主键）
`insert.mode=upsert`	存在则更新、不存在则插入
`auto.create=true`	目标表不存在时自动建（慎用，生产应提前建好）
`auto.evolve=true`	自动加字段（DDL 同步）
`delete.enabled=true`	同步 DELETE 事件
`transforms.dropPrefix`	用正则去掉 topic 前缀，让表名干净
`errors.tolerance=all`	出错进死信队列，不中断同步流

4.4 死信队列（DLQ）

启用 DLQ 后失败的记录会进指定 topic，方便排查：

1
2
3
4
5


"errors.tolerance": "all",
"errors.deadletterqueue.topic.name": "my-connector-errors",
"errors.deadletterqueue.context.headers.enable": "true",
"errors.log.enable": "true",
"errors.log.include.messages": "false"

5. 常见坑与排错

5.1 `RecordTooLargeException`

1
2


The message is 1691268 bytes when serialized which is larger than 1048576,
which is the value of the max.request.size configuration.

修法：见 3.3 调大消息体。

5.2 `Failed to find any class that implements Connector and which name matches io.confluent.connect.jdbc.JdbcSinkConnector`

没注册 Sink Connector JAR，按 4.1 操作。

5.3 `No suitable driver found for jdbc:mysql://...`

没把 MySQL JDBC 驱动 JAR 放到 connect 容器：

1
2


docker cp mysql-connector-java-8.0.23.jar connect:/kafka/connect/kafka-connect-jdbc
docker restart connect

5.4 Source Connector 卡在 RUNNING 但不消费

查看 task 状态：

1

curl http://internal.example.com:8083/connectors/source-hnDev/tasks

state=PENDING 多半是历史 topic 恢复中；RUNNING 但 Kafka offset 没变，可能是 binlog 已丢失——把 connector 删了重建并改 snapshot.mode=initial。

5.5 时间类型不匹配

Source 是 DATETIME(0) 但 Sink 写入失败。把 time.precision.mode 改成 connect 或在 SMT 里转字符串：

1
2
3
4


"transforms.tsFormat1.type": "org.apache.kafka.connect.transforms.TimestampConverter$Value",
"transforms.tsFormat1.target.type": "string",
"transforms.tsFormat1.field": "create_time",
"transforms.tsFormat1.format": "yyyy-MM-dd HH:mm:ss"

5.6 Canal “table meta tsdb is out of sync”

canal-server 重启时找不回 binlog 位点。两种解法：

删 /home/admin/canal-server/conf/{instance}/meta.dat 让它重做快照
在 instance.properties 设 canal.instance.tsdb.db.username/password 把 tsdb 存进 MySQL

6. 生产建议

6.1 选型

单向同步（MySQL → MySQL）：Canal adapter 最快
多源聚合：Debezium + JDBC Sink
强一致 + 转换：Flink CDC + Flink SQL

6.2 监控

指标	工具
Canal lag	canal admin web 页面
Debezium lag	JMX `debezium.metrics` + Prometheus + Grafana
Kafka consumer lag	`kafka-consumer-groups.sh --describe`
Sink 写入速率	JDBC Sink task metrics

6.3 反向思考：什么场景不能用？

场景	不建议
写入压力已经接近 MySQL 极限	同步会把 source 和 sink 同时打挂
频繁 DDL（加列改类型）	Debezium schema history 会越来越大
表没有主键	同步后 upsert 行为不可预期
大事务（> 1MB）	需要先调大 `max.request.size`

6.4 自建镜像

canal-adapter 官方镜像老旧、glibc 兼容性差。生产推荐自建镜像：

1
2
3
4
5
6
7


# Dockerfile
FROM lwd/jdk:8u371
COPY canal.adapter-1.1.6.tar.gz /tmp/
RUN tar -xzf /tmp/canal.adapter-1.1.6.tar.gz -C /opt/ && \
 mv /opt/canal.adapter-1.1.6 /opt/canal-adapter
COPY startup.sh /opt/canal-adapter/bin/
ENTRYPOINT ["/opt/canal-adapter/bin/startup.sh"]

1

docker build -t local/canal-adapter:v1.1.6 .

下一步

MySQL 备份 + binlog 反解：见《MySQL 备份恢复实战》
多库适配（MySQL ↔ PG ↔ 国产）：见《多数据库适配架构》

Windows 数据库客户端实战：MySQL / Redis / SQLite / MQTTX / Elasticsearch

Tue, 15 Nov 2016 00:00:00 +0800

一、2016 年数据库客户端格局

2016 年的数据库世界：MySQL 仍是事实 OLTP 之王、Redis 已经是缓存标配、SQLite 在移动端大杀四方、MQTT 协议在 IoT 崛起、Elasticsearch 2.x 到 5.x 跨大版本。本文整理 5 款数据库 / 消息客户端的实战用法。

阅读建议：本文面向全栈 / 后端开发者，重点在工具选型 + 性能调优。

二、MySQL 客户端

2.1 命令行

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 连接
mysql -h <HOST> -P 3306 -u root -p<password> <DB>

# 常用命令
SHOW DATABASES;
USE mydb;
SHOW TABLES;
DESCRIBE users;
SELECT * FROM users LIMIT 10;

# 导出
mysqldump -h <HOST> -u root -p<password> mydb > backup.sql

# 导入
mysql -h <HOST> -u root -p<password> mydb < backup.sql

# 执行 SQL 文件
mysql -h <HOST> -u root -p<password> mydb < init.sql

2.2 GUI 工具对比

工具	优势	价格
Navicat	多数据库 / 完整	商业付费
DBeaver	免费开源 / 多数据库	开源（EE 收费）
MySQL Workbench	官方 / 建模	免费
HeidiSQL	轻量	免费
phpMyAdmin	Web	免费
DataGrip	JetBrains / 最强	商业付费
Sequel Ace	Mac 开源	免费

2.3 MySQL 8.0 新特性

窗口函数（ROW_NUMBER() OVER）
CTE 公共表表达式（WITH 子句）
JSON 增强（JSON_TABLE）
降序索引
caching_sha2_password（默认鉴权插件）

2.4 性能调优

慢查询日志：

1
2
3
4
5


# /etc/my.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2
log_queries_not_using_indexes = 1

索引优化：

1
2
3
4
5
6
7


-- 查看执行计划
EXPLAIN SELECT * FROM users WHERE email = 'foo@bar.com';

-- 关键字段：type, key, rows, Extra
-- type = ALL: 全表扫描
-- type = ref: 索引扫描
-- type = const: 主键/唯一索引等值

连接数：

1
2
3
4
5


-- 当前连接
SHOW STATUS LIKE 'Threads_connected';

-- 最大连接
SHOW VARIABLES LIKE 'max_connections';

三、Redis 客户端

3.1 命令行

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# 连接
redis-cli -h <HOST> -p 6379 -a <password>

# 常用命令
SET user:1 "alice"
GET user:1
DEL user:1
EXISTS user:1
EXPIRE user:1 3600

# 哈希
HSET user:1 name "alice" age 30
HGETALL user:1

# 列表
LPUSH queue:msg "msg1"
RPOP queue:msg

# 集合
SADD tags "java" "redis"
SMEMBERS tags

# 有序集合
ZADD rank 100 "alice" 95 "bob"
ZRANGE rank 0 -1 WITHSCORES

# 管道
echo "PING\nSET k v\nGET k" | redis-cli

3.2 GUI 工具对比

工具	平台	价格
Redis Desktop Manager (RDM)	跨平台	现改名 RESP.app / 商业
Medis	Mac	开源
Another Redis Desktop Manager	跨平台	开源免费
RedisInsight	跨平台	官方 / 免费
FastoRedis	跨平台	开源 / 商业
Tiny RDM	新兴	国产 / 开源

3.3 实战：String 缓存

1
2
3
4
5
6
7
8


# 设置 5 分钟过期
SET session:user:1001 "<json>" EX 300

# 获取
GET session:user:1001

# 原子递增
INCR counter:views:article:123

3.4 实战：List 消息队列

1
2
3
4
5


# 生产者
LPUSH queue:email "{\"to\":\"a@x.com\",\"subject\":\"hi\"}"

# 消费者
BRPOP queue:email 0 # 阻塞 0 秒直到有数据

3.5 性能监控

1
2
3
4
5
6
7
8
9


# 实时命令
redis-cli MONITOR

# 慢查询
redis-cli SLOWLOG GET 10

# 内存分析
redis-cli MEMORY USAGE mykey
redis-cli INFO MEMORY

四、SQLite 客户端

4.1 命令行

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 打开 / 创建数据库
sqlite3 mydb.db

# 常用命令
.tables
.schema users
.headers on
.mode column
SELECT * FROM users LIMIT 10;

# 备份
sqlite3 mydb.db ".dump" > backup.sql

# 恢复
sqlite3 newdb.db < backup.sql

4.2 GUI 工具

工具	平台	价格
DB Browser for SQLite	跨平台	免费开源
SQLiteStudio	跨平台	免费
Navicat for SQLite	跨平台	商业
DBeaver	跨平台	开源（EE 收费）

4.3 DB Browser for SQLite 实战

https://sqlitebrowser.org/：

打开 .db 文件
Browse Data → 看表数据
Execute SQL → 写 SQL
Database Structure → 改表结构
Export → CSV / JSON / SQL

4.4 实战：移动端加密数据库

1
2
3
4
5
6
7
8
9


# Python + SQLite 加密
import sqlite3
from pysqlcipher3 import dbapi2 as sqlcipher

conn = sqlcipher.connect("encrypted.db")
conn.execute("PRAGMA key = 'my-secret-password'")
cursor = conn.cursor()
cursor.execute("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)")
conn.commit()

实战：

密码管理器（如 1Password / Bitwarden）
本地缓存（Chrome 历史）
小工具数据（如 RSS 阅读器）

五、MQTTX 客户端

5.1 MQTT 协议背景

MQTT 1999 年由 IBM 发布，IoT 领域事实标准。核心概念：

Broker：消息代理（EMQX / Mosquitto）
Client：发布 / 订阅
Topic：主题（层级 / 通配符）
QoS：
- 0：最多一次
- 1：至少一次
- 2：恰好一次
Retain：保留消息

5.2 MQTTX 介绍

MQTTX 是 EMQX 团队开发的跨平台 MQTT 桌面客户端。优势：

跨平台（Win / Mac / Linux）
支持 MQTT 5.0
多连接 / 多主题
消息格式化（ JSON / Hex**）**
脚本化（自动测试）

5.3 安装与连接

https://mqttx.app/：

新建连接
- Host：broker.emqx.io（公共测试）
- Port：1883（TCP）/ 8883（TLS）
- Client ID：随机生成
订阅：test/topic
发布：同主题发 {"hello": "world"}

5.4 实战：本地 Mosquitto 调试

1
2
3
4
5
6
7
8


# 启动 Mosquitto
mosquitto -p 1883

# 订阅
mosquitto_sub -h 127.0.0.1 -t "test/#" -v

# 发布
mosquitto_pub -h 127.0.0.1 -t "test/foo" -m "hello"

MQTTX 中：

Host：127.0.0.1
订阅：test/#
发布：test/foo + hello

5.5 实战：TLS / 证书

1
2
3
4
5


MQTTX 高级设置：
- CA File: ca.crt
- Client Cert: client.crt
- Client Key: client.key
- Verify: true

5.6 脚本化（自动化测试）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// MQTTX 脚本：连接 + 订阅 + 验证
const mqtt = require('mqtt');
const client = mqtt.connect('mqtt://broker.emqx.io:1883');

client.on('connect', () => {
 client.subscribe('test/topic', (err) => {
 if (!err) {
 client.publish('test/topic', 'hello mqtt');
 }
 });
});

client.on('message', (topic, message) => {
 console.log(`收到: ${message.toString()}`);
 client.end();
});

六、Elasticsearch 客户端

6.1 协议背景

Elasticsearch 2010 年发布，基于 Lucene 的分布式搜索。2016 年发布 5.0（重大重构）。核心概念：

Index：索引（类比 MySQL 数据库）
Type（5.x）/Document（6.x 起弱化 Type）：文档
Mapping：字段类型定义
Shard / Replica：分片 / 副本

6.2 HTTP API

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# 创建索引
curl -X PUT "localhost:9200/my_index"

# 索引文档
curl -X PUT "localhost:9200/my_index/_doc/1" \
 -H "Content-Type: application/json" \
 -d '{"title": "Hello", "content": "World"}'

# 搜索
curl -X GET "localhost:9200/my_index/_search?q=hello"

# 复杂搜索（DSL）
curl -X GET "localhost:9200/my_index/_search" \
 -H "Content-Type: application/json" \
 -d '{
 "query": {
 "bool": {
 "must": [
 { "match": { "content": "hello" } },
 { "range": { "date": { "gte": "2020-01-01" } } }
 ]
 }
 }
 }'

6.3 GUI 工具

工具	优势
Kibana	官方 / 必备
ElasticHD	国产 / 轻量
Elasticsearch Head	老牌 / Chrome 插件
Dejavu	跨平台 / 现代
Cerebro	集群管理

6.4 Kibana Dev Tools

Kibana 装好后 → Dev Tools：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 索引文档
POST /my_index/_doc
{
 "title": "Hello",
 "content": "World",
 "date": "2024-01-01"
}

# 搜索
GET /my_index/_search
{
 "query": {
 "match": {
 "content": "hello"
 }
 }
}

6.5 实战：日志搜索

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# 创建索引模板（自动 mapping）
PUT /_index_template/logs-template
{
 "index_patterns": ["logs-*"],
 "template": {
 "settings": {
 "number_of_shards": 1
 },
 "mappings": {
 "properties": {
 "@timestamp": { "type": "date" },
 "level": { "type": "keyword" },
 "message": { "type": "text" },
 "service": { "type": "keyword" }
 }
 }
 }
}

# 批量导入
POST /logs-2024.01/_bulk
{ "index": {} }
{ "@timestamp": "2024-01-01T10:00:00", "level": "INFO", "message": "started", "service": "api" }

6.6 性能调优

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 索引设置
index.number_of_shards: 3
index.number_of_replicas: 1
index.refresh_interval: 30s  # 默认 1s → 30s 减少 IO

# 字段类型优化
"message": {
 "type": "text",
 "fields": {
 "keyword": { "type": "keyword", "ignore_above": 256 }
 }
}

七、组合实战

7.1 全栈后端开发环境

1
2
3
4
5


代码：IntelliJ IDEA + VSCode
本地 DB：MySQL / Redis / SQLite
消息：EMQX + MQTTX
搜索：Elasticsearch + Kibana
工具：Navicat / DBeaver / Redis Desktop

7.2 IoT 设备监控

1
2
3
4
5
6
7


设备：MQTT Publish（sensor/data）
 ↓ EMQX Broker
MQTTX 订阅
 ↓ 规则引擎
InfluxDB 时序存储
 ↓ Grafana 看板
 ↓ 告警 → 钉钉

7.3 日志分析系统

1
2
3
4
5


应用 → Filebeat → Kafka
 ↓ Logstash
Elasticsearch
 ↓ Kibana
可视化 / 告警

八、常见问题

8.1 MySQL 8.0 caching_sha2_password 鉴权

旧客户端连接失败。解决：

1

ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY '<PASSWORD>';

8.2 Redis 公网暴露被攻击

bind 127.0.0.1：只本地访问
requirepass：开密码
rename-command CONFIG “”：禁 CONFIG 命令
防火墙规则

8.3 SQLite 锁库问题

SQLite 写操作会全库锁。解决：

WAL 模式：PRAGMA journal_mode=WAL;（读写并发）
超时设置：PRAGMA busy_timeout=5000;
多连接 + 短事务

8.4 MQTTX 连接失败

端口：1883（TCP）/ 8883（TLS）
Client ID 冲突：自动生成
认证：填 username / password
TLS 证书：自签名需要勾"允许自签名"

8.5 Elasticsearch 启动报错

JVM 堆不够：调 -Xms / -Xmx
root 用户：需要 -Ediscovery.type=single-node + 创建 elasticsearch 用户
max_map_count：sysctl -w vm.max_map_count=262144

九、下一步

想看消息队列：[2023-12-15 消息队列镜像实战：RabbitMQ / EMQX / ActiveMQ]
想看监控告警：[2025-03-15 Prometheus 监控告警体系]
想看时序数据库：[2023-09-15 时序数据库三剑客]

本文写于 2016 年，回看当时：MySQL 8.0 还未发布（2018-04）；Redis 4.0 时代，模块系统才刚上；MQTT 5.0 还在草案（2019 发布）；Elasticsearch 5.0 重构了 Type 概念——10 年后 5 款工具仍是同类最强。

MySQL 备份恢复实战：mysqldump + ibd2sql + binlog2sql + cron

Thu, 15 Sep 2016 00:00:00 +0800

为什么写这篇：MySQL 备份有 4 个维度——全量逻辑备份（mysqldump）、物理文件直抽（ibd2sql）、增量恢复（binlog2sql）、生产定时任务编排。任何一种出故障都能从其他三种救回来，才算合格的灾备体系。

适用读者：需要为 MySQL 设计完整备份方案的运维 / DBA。

前置知识：会用 Linux shell、知道 cron 表达式、了解 MySQL 基础。

1. mysqldump：通用逻辑备份

1.1 核心命令模板

1
2
3
4
5
6
7
8


mysqldump \
 --quick \
 --events \
 --all-databases \
 --flush-logs \
 --delete-master-logs \
 --single-transaction \
 > /backup/all_${dumpdate}.sql

参数	含义	是否必须
`--quick`, `-q`	一行一行从服务器取，不缓存到内存	大表必须
`--events`, `-E`	导出事件	重要
`--all-databases`, `-A`	导出全部数据库	全量备份时用
`--flush-logs`	导出前刷新 binlog	重要
`--delete-master-logs`	主库备份后清理已备份的 binlog	减少磁盘占用
`--single-transaction`	用一致快照导出（仅 InnoDB）	重要

关于 --flush-logs 与 --delete-master-logs：使用 --all-databases 时，会逐个数据库刷新日志——但只有配合 --lock-all-tables 或 --master-data 时所有表会同时锁定。要保证"导出 + 日志刷新"原子性，请同时加 --master-data 或 --lock-all-tables。

1.2 排除大表 / 只导结构 / 只导数据

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 排除表
docker exec mysql /usr/bin/mysqldump \
 -u root -p'{{REDACTED}}' \
 industry_iot_dev \
 --ignore-table=industry_iot_dev.location_historydata \
 --ignore-table=industry_iot_dev.base_log \
 > /backup/safety-20230904.sql

# 只导数据（不带 CREATE TABLE）
mysqldump -t -u root -p'{{REDACTED}}' industry_iot_dev --tables test_sync > test_sync.sql

# 只导结构（不带 INSERT）
mysqldump -d -u root -p'{{REDACTED}}' industry_iot_dev > schema.sql

1.3 Docker 容器内备份

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 在容器内 mysqldump 出来
docker exec mysql /usr/bin/mysqldump \
 -u root -p'{{REDACTED}}' \
 --single-transaction --quick \
 industry_iot_dev \
 --ignore-table=industry_iot_dev.location_historydata \
 > /home/docker/mysql/bak/safety-20231212.sql

# 再用 docker cp 把文件拷出来
docker cp mysql:/tmp/safety-20231212.sql /home/docker/mysql/bak/

# 或直接管道（容器内）
docker exec mysql bash -c "mysqldump -uroot -p'{{REDACTED}}' industry_iot_dev" > backup.sql

坑点：mysqldump 默认会写锁。如果容器跑的是生产库，必须加 --single-transaction，否则会阻塞业务写入。

2. 快速导入导出：sql 文件在容器内流转

2.1 标准做法（推荐）

1
2
3
4
5


# 1. 把 sql 文件复制进容器
docker cp backup.sql mysql:/tmp/backup.sql

# 2. 容器内执行导入
docker exec -it mysql bash -c "mysql -uroot -p'{{REDACTED}}' industry_iot_dev < /tmp/backup.sql"

2.2 关 binlog + 事务加速大文件导入

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


-- 关闭 binlog（导入期间不写 binlog，提速 30%）
SET sql_log_bin = OFF;
-- 关闭自动提交
SET autocommit = 0;

USE industry_iot_dev;
START TRANSACTION;
SOURCE /tmp/backup.sql;
COMMIT;

-- 恢复
SET sql_log_bin = ON;
SET autocommit = 1;

SET sql_log_bin = OFF 必须是超级用户才有权限，且主从架构下从库别这么干——会导致从库 binlog 缺失，主从不一致。

2.3 Navicat 数据传输

开发机/测试机之间最省事的备份恢复是 Navicat 的"数据传输"功能：

工具 → 数据传输 → 选源库 + 目标库 → 全勾选项（结构 + 数据）
优点：自带进度条、可中断、跨 MySQL 版本兼容

坑点：表多时会卡死——Navicat 单连接执行所有 DDL。改成 1 张表 1 次传输。

3. ibd2sql：从 .ibd 文件直接抽数据

ibd2sql 是国产开源工具（github.com/ddcw/ibd2sql），不需要 MySQL 实例，直接从 .ibd 文件里读 InnoDB 索引页、解析出行记录。

3.1 适用场景

场景	是否适用
MySQL 实例起不来（磁盘损坏、配置错误）	✓ 唯一能救命的办法
想不锁表地查历史数据	✓ 不会动原文件
想审计某张表的删除记录	✓ 配合 .ibd 副本可读
普通日常备份	✗ 不如 mysqldump 简单

3.2 安装与使用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 安装 Python3（一般系统都有）
apt install -y python3

# 下载最新版本
wget https://github.com/ddcw/ibd2sql/archive/refs/tags/v1.10.tar.gz
tar -xzf v1.10.tar.gz
cd ibd2sql-1.10

# 直接抽数据
python3 main.py /var/lib/mysql/your_db/your_table.ibd \
 --sql \
 --output /tmp/your_table.sql

默认会输出 INSERT 语句，直接 mysql 客户端执行即可恢复。

4. binlog 与 binlog2sql：增量恢复

4.1 什么是 binlog

binlog（二进制日志）记录了所有修改数据的 SQL，主要用于主从复制和增量恢复。

1
2
3
4


# 查看 binlog
docker exec -it mysql bash
cd /var/lib/mysql
mysqlbinlog --base64-output=DECODE-ROWS -v binlog.000013

4.2 反解 binlog 找某张表的变更

1
2
3
4
5
6


# 配合 grep 找到某张表的所有 DML
mysqlbinlog /var/lib/mysql/bin.000003 \
 --database industry_iot \
 --base64-output=decode-rows -vv \
 --skip-gtids=true \
 | grep -C 1 -i "risk_task_ctrl" > sql.log

4.3 binlog2sql：把 binlog 反解成可执行 SQL

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


pip install binlog2sql

# 关键场景：误删一张表后的精准恢复
python binlog2sql.py \
 -h127.0.0.1 -P3306 -uroot -p'{{REDACTED}}' \
 -d industry_iot \
 -t risk_task_ctrl \
 --start-file='binlog.000003' \
 --start-datetime='2016-12-13 20:25:00' \
 --stop-datetime='2016-12-13 20:30:00' \
 > recovery.sql

参数	含义
`--start-file`	从哪个 binlog 文件开始
`--start-datetime`	起始时间（精确到秒）
`--stop-datetime`	结束时间
`-t`	指定表（不加则整个库）
`-d`	指定库

典型误删恢复流程：

立即发现误操作 → 不要慌，先看 SHOW MASTER STATUS 记录当前 binlog 位置

锁表：FLUSH TABLES WITH READ LOCK;（防止新写入覆盖现场）

用 binlog2sql 生成反向 SQL（默认生成的就是回滚 SQL）

应用回滚 SQL

解锁：UNLOCK TABLES;

4.4 binlog 模式与 ROW vs STATEMENT

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 查看 binlog 模式
SHOW VARIABLES LIKE 'binlog_format';
-- ROW 推荐（基于行的变更，主从一致性好）
-- STATEMENT 默认（基于 SQL 文本，主从不一致风险大）
-- MIXED 混合

-- 推荐改成 ROW
SET GLOBAL binlog_format = 'ROW';

-- 同时开启 binlog_rows_query_log_events（把原始 SQL 也记到 binlog 里）
SET GLOBAL binlog_rows_query_log_events = ON;

ROW 模式 + binlog_rows_query_log_events = ON 让你既能看到行级变化，又能直接看到原 SQL——调 bug 必备。

4.5 binlog 重置

1
2


# 慎用！会清空所有 binlog
mysql -uroot -p'{{REDACTED}}' -e "RESET MASTER;"

5. 定时备份 + 远程上传脚本

5.1 cron 表达式速查

1
2
3
4
5
6
7


* * * * *
- - - - -
| | | | +----- 星期中星期几 (0 - 6) (星期天 为0)
| | | +---------- 月份 (1 - 12)
| | +--------------- 一个月中的第几天 (1 - 31)
| +-------------------- 小时 (0 - 23)
+------------------------- 分钟 (0 - 59)

5.2 完整备份脚本（保留 7 天 + 上传 FTP）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


#!/usr/bin/env bash
# safety-local-mysqlbak.sh
set -e

DATE=$(date +%Y%m%d%H%M%S)
BACK_DATA=safety-${DATE}.sql
BAK_PATH=/home/docker/mysql/bak

if [ ! -d ${BAK_PATH} ]; then
 mkdir -p ${BAK_PATH}
fi

# 1. 备份
docker exec mysql /usr/bin/mysqldump \
 -u root -p'{{REDACTED}}' \
 --single-transaction --quick \
 industry_iot_dev \
 --ignore-table=industry_iot_dev.location_historydata \
 > ${BAK_PATH}/${BACK_DATA}

# 2. 删除 7 天前的
find ${BAK_PATH} -name "*.sql" -mtime +7 | xargs rm -rf

# 3. 保留最新副本软链
cp ${BACK_DATA} ${BAK_PATH}/safety_latest.sql

# 4. 上传 FTP（内网示例）
curl -u www:'{{REDACTED}}' \
 -T ${BAK_PATH}/safety_latest.sql \
 ftp://internal.example.com/tools/

# 5. 远程异地备份（公司机房示例）
curl -u www:'{{REDACTED}}' \
 -T /home/docker/mysql/bak/safety-${DATE}.sql \
 ftp://internal.example.com:25421/tools/

5.3 注册到 crontab

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


chmod +x /home/docker/mysql/backupmysql.sh

# 编辑定时任务
crontab -e

# 每天凌晨 0 点执行
0 0 * * * /home/docker/mysql/backupmysql.sh

# 或从远程拉脚本执行（参数：保留天数）
0 0 * * * /usr/bin/curl http://internal.example.com:9091/file/sh/safety-local-mysqlbak.sh | bash -s 7

参数化 cron：用 (crontab -l | grep -v "$cron_job"; echo "$cron_job") | crontab - 这种"过滤+追加"模式可以幂等地更新定时任务，不会重复添加。

6. 恢复场景实战：从全量 + binlog 恢复某张表

场景：某天发现 risk_task 表在 14:00 误删了某些行，备份是凌晨 3:00 的全量。

恢复步骤：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# 1. 找到 14:00 前最近的 binlog 位置
mysqlbinlog /var/lib/mysql/bin.000003 --base64-output=decode-rows -vv \
 --skip-gtids=true | grep -C 3 "DELETE FROM risk_task"

# 2. 生成风险点 03:00 ~ 14:00 之间 risk_task 表的完整变更
python binlog2sql.py \
 -uroot -p'{{REDACTED}}' \
 -d industry_iot -t risk_task \
 --start-file='binlog.000003' \
 --start-datetime='2024-06-15 03:00:00' \
 --stop-datetime='2024-06-15 14:00:00' \
 --sql \
 > /tmp/risk_task_recovery.sql

# 3. 先在测试库跑一遍
mysql -uroot -p'{{REDACTED}}' test_industry_iot < /tmp/risk_task_recovery.sql

# 4. 在生产库上找回 03:00 后被误删的数据
# （一般只取 DELETE 的反向 SQL，过滤掉 UPDATE）

前提：你的 binlog 一定要是 ROW 模式 + binlog_rows_query_log_events = ON + binlog 文件没被清理。

7. Docker / K8s 环境的备份特例

7.1 Docker 容器备份

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 备份（容器内）
docker exec mysql /usr/bin/mysqldump \
 -u root -p'{{REDACTED}}' \
 --single-transaction --skip-lock-tables --quick \
 industry_iot_dev \
 > /home/iot.sql

# 重建数据库
cat << "EOF" | docker exec -i mysql /usr/bin/mysql -u root --password='{{REDACTED}}'
DROP DATABASE IF EXISTS `industry_iot_dev`;
CREATE DATABASE `industry_iot_dev` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
EOF

# 导入
cat /home/iot.sql | docker exec -i mysql /usr/bin/mysql \
 -u root --password='{{REDACTED}}' industry_iot_dev

7.2 K8s 备份

1
2
3
4
5
6
7
8
9


# 通过 kubectl exec 在 Pod 内执行
kubectl exec -i "$(kubectl get pods -n mydb | grep mysql | awk '{print $1}')" \
 -n mydb \
 -- bash -c "/usr/bin/mysqldump --defaults-file=/etc/mysql/conf.d/my.cnf industry_iot_dev" \
 > safety.sql

# 传到 MinIO 备份
mc rm --versions --force minio-server/file/dev/safety/safety.sql
mc cp /file/safety.sql minio-server/file/dev/safety/

7.3 K8s 单表导入

1
2


cat risk_task.sql | kubectl exec -i $(kubectl get pods -n mydb | grep mysql | awk '{print $1}') \
 -n mydb -- bash -c "/usr/bin/mysql -u root --password='{{REDACTED}}' test"

7.4 导入时报 ASCII ‘\0’ 错误

1

ERROR: ASCII '\0' appeared in the statement

mysqldump 默认不识别二进制 0 字符。加 --binary-mode=1：

1
2
3
4
5


cat /home/docker/mysql/bak/safety-20240504080004.sql | \
 docker exec -i mysql /usr/bin/mysql \
 --binary-mode=1 \
 -u root --password='{{REDACTED}}' \
 industry_iot_dev

经验总结

备份类型	优点	缺点	适用
mysqldump 逻辑备份	跨版本兼容、可读、可编辑	大库慢、占内存	中小库 / 跨版本迁移
XtraBackup 物理热备	速度快、增量	配置复杂	大库 / 高频备份
binlog 增量	时间点恢复	依赖全量备份	误删救命
ibd2sql 直抽 .ibd	实例起不来也能读	工具年轻	灾难恢复

铁律：只做一种备份 = 没有备份。生产环境至少 2 种备份组合（如：每天全量 + 持续 binlog + 每周异地同步）。

下一步

数据同步 Canal / Debezium：见《MySQL 实时同步实战》
索引与 SQL 优化：见《MySQL 索引优化实战》
权限与安全：见《MySQL 用户权限与安全实战》

2024+ 视角：MySQL Shell + MySQL Operator + PIT 恢复

MySQL Shell（mysqlsh）—— 推荐替代 mysql/mysqldump

mysqlsh 是 8.0.13+ 引入的多语言客户端 + 工具集：

1
2
3
4
5
6
7
8


# 启动 mysqlsh（默认 SQL 模式）
mysqlsh --uri=user@10.0.0.10:3306

# 切到 JS 模式
mysqlsh --uri=user@10.0.0.10:3306 --js

# 切到 Python 模式
mysqlsh --uri=user@10.0.0.10:3306 --py

核心价值：内置 util 模块提供并行 + 一致性的备份恢复能力。

`util.dumpInstance()` 替代 mysqldump

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// mysqlsh JS 模式
util.dumpInstance("/backup/full_dump", {
 threads: 8, // 并行 8 线程
 compression: "zstd", // zstd 压缩（比 gzip 快 3 倍）
 chunking: true, // 分块大表
 showProgress: true,
 consistent: true, // FLUSH TABLES WITH READ LOCK
 ddlOnly: false,
 dataOnly: false
});

优势：

8 线程并行导出，比 mysqldump 快 5-10 倍
自动分块大表（>50GB 也能稳定）
断点续传：导出失败可 --resumeFrom 续传
支持 zstd 压缩（比 gzip 快 3 倍、压缩比高 10%）

`util.loadDump()` 导入

1
2
3
4
5
6
7
8
9


util.loadDump("/backup/full_dump", {
 threads: 8,
 showProgress: true,
 ignoreVersion: true, // 跨大版本恢复
 loadUsers: true, // 同时导入用户
 loadDdl: true,
 loadData: true,
 skipBinlog: true // 从库导入时跳过 binlog
});

MySQL Operator for Kubernetes（2024+ GA）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# mysql-innodbcluster.yaml
apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
 name: my-cluster
spec:
 instances: 3
 baseServerId: 1000
 tls:
 useSelfSigned: true
 router:
 instances: 2
 secretName: mysql-cluster-secret

优势：

3 节点 InnoDB Cluster 自动部署（Group Replication）
MySQL Router 自动 sidecar
滚动升级、备份、监控一应俱全
对标 Percona Operator for MySQL

2024+ 备份恢复工具矩阵

工具	特点	2024+ 适用
mysqldump	老牌、单线程	小库 / 跨版本兼容
mysql-shell util	并行、zstd、断点续传	生产首选
mydumper / myloader	C 写的并行工具	大库快速备份
Percona XtraBackup 8.x	物理热备	TB 级库 + 快速恢复
MySQL Enterprise Backup (MEB)	商业	企业版特性
TiDB DM / OceanBase OMS	异构同步	MySQL → TiDB / OB

PIT（Point-In-Time）恢复的标准流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 1. 全量备份
mysqlsh --uri=user@db-host -e "util.dumpInstance('/backup/2024-06-15-0300')"

# 2. 恢复全量到临时库
mysqlsh --uri=user@temp-host -e "util.loadDump('/backup/2024-06-15-0300')"

# 3. 解析 binlog 到 PIT
mysqlbinlog --start-datetime='2024-06-15 03:00:00' \
 --stop-datetime='2024-06-15 14:00:00' \
 --read-from-remote-server \
 --host=db-host --user=repl \
 binlog.000003 binlog.000004 \
 > /tmp/pit.sql

# 4. 应用到临时库
mysql -u root -p temp_db < /tmp/pit.sql

# 5. 切换业务（DNS / 负载均衡切到 temp_db）

Cloud-Native 备份新方案

AWS RDS/Aurora：自动备份 + PIT 恢复（5 分钟内任意点）
阿里云 RDS：跨地域备份 + 备份集查询
腾讯云 CynosDB：binlog 实时上传 COS，30 天可回放

2024+ 安全加固

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


-- 8.0+ 强制 TLS 连接
ALTER USER 'app_user'@'%' REQUIRE SSL;

-- 8.0+ 密码强度策略
SET PERSIST validate_password.policy = STRONG;
SET PERSIST validate_password.length = 12;

-- 8.0+ 双因素认证
ALTER USER 'admin'@'%' ADD FACTOR 2;

-- 8.0.27+ 审计日志
SET PERSIST audit_log_format = JSON;
SET PERSIST audit_log_policy = ALL;

实战坑（2024+）

mysqlsh util.dumpInstance 默认不导出 mysql.user，要用 --users flag
**跨大版本恢复（5.7 → 8.4）**必须 mysql_upgrade，且要先检查是否有保留字冲突
MySQL Operator 2.x 部署后默认开启 MySQL Router sidecar——K8s service 指向 router 而非直接指向 MySQL Pod
MySQL HeatWave（Oracle 云）支持"自动 binlog 解析 + 一致性快照导出"——但仅限 Oracle Cloud

MySQL 慢查询与性能调优：sysbench 压测 + buffer pool + 锁表排查

Tue, 15 Dec 2015 00:00:00 +0800

为什么写这篇：MySQL 性能问题有三个主要来源——慢 SQL、buffer pool 配置不合理、磁盘/网络瓶颈。本文把"怎么发现 → 怎么量化 → 怎么调"整理成可复用的流程，所有命令都带真实案例参数。

适用读者：做 MySQL 性能调优的运维 / DBA / 后端。

前置知识：了解 MySQL 基本架构、知道索引的作用。

1. 第一步：找到慢 SQL（慢查询日志）

1.1 查看是否开启

1
2
3


SHOW VARIABLES LIKE '%slow%';
SHOW STATUS LIKE '%slow%';
SHOW VARIABLES LIKE 'long_query_time';

输出字段含义：

变量	含义
`slow_query_log`	是否开启（默认 OFF）
`slow_query_log_file`	日志文件路径
`long_query_time`	慢查询阈值（秒，默认 10）

1.2 在线开启 + 配置文件

1
2
3
4
5
6
7


# /etc/my.cnf
[mysqld]
slow_query_log = on
slow_query_log_file = /data/f/mysql_slow_cw.log # Linux 用这个
# slow_query_log_file = <WAMP_INSTALL_DIR>/bin/mysql/mysql5.5.16/data/show-slow.log # Windows 必须绝对路径
long_query_time = 2 # 超过 2 秒算慢
log-queries-not-using-indexes # 没走索引的也记

Windows 注意：slow_query_log_file 必须写绝对路径（如 <WAMP_INSTALL_DIR>/...），相对路径在 Windows 下不工作。

修改后重启 MySQL 生效。

2. 第二步：mysqldumpslow 快速分析

mysqldumpslow 是 MySQL 自带的"五秒出报告"工具：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 访问最多的 10 条慢查询
mysqldumpslow -s c -t 10 /var/lib/mysql/huixuli2-slow.log

# 查询时间最慢的 3 条
mysqldumpslow -s t -t 3 /var/lib/mysql/huixuli2-slow.log

# 按时间排序前 10 条含 left join 的
mysqldumpslow -s t -t 10 -g "left join" /database/mysql/slow-log

# 扫描行数最多的
mysqldumpslow -s r -t 10 -g 'left join' /var/run/mysqld/mysqld-slow.log

参数说明：

参数	含义
`-s c`	按 count（执行次数）排序
`-s t`	按 time（耗时）排序
`-s r`	按 row（扫描行数）排序
`-s l`	按 lock time（锁等待）排序
`-t N`	取前 N 条
`-g PATTERN`	grep 过滤

3. 第三步：pt-query-digest 深度分析

pt-query-digest 是 Percona 出品的专业慢查询分析工具，能生成结构化报告（响应时间、占比、参数化指纹）。

3.1 安装

1
2
3
4
5
6
7


# Debian/Ubuntu
wget http://www.percona.com/get/pt-query-digest
chmod +x pt-query-digest

# 或整套 Percona Toolkit
wget percona.com/get/percona-toolkit.rpm
rpm -ivh percona-toolkit-2.2.13-1.noarch.rpm

重要：pt-query-digest 是个 Perl 脚本，所以系统得有 Perl 解释器（CentOS / Ubuntu 自带）。

3.2 关键参数

参数	含义
`--filter 'EXPR'`	按 Perl 表达式过滤事件
`--limit N` / `--limit N%`	输出前 N 条或 N% 占比
`--host / --user / --password`	连 MySQL 用
`--history`	把分析结果保存到 history 表（带时间窗对比）
`--review`	把分析结果保存到 review 表（更精简）
`--output report`	输出标准报告
`--since '12h'` / `--since 'YYYY-MM-DD'`	时间范围起点
`--until ...`	时间范围终点

3.3 11 个常用用法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


# 1. 直接分析
pt-query-digest slow.log > slow_report.log

# 2. 最近 12 小时
pt-query-digest --since=12h slow.log > report.log

# 3. 指定时间范围
pt-query-digest slow.log \
 --since '2014-05-17 09:30:00' \
 --until '2014-06-17 10:00:00' > report.log

# 4. 只分析 SELECT
pt-query-digest --filter '$event->{fingerprint} =~ m/^select/i' slow.log

# 5. 只看 root 用户的
pt-query-digest --filter '($event->{user} || "") =~ m/^root/i' slow.log

# 6. 全表扫描/全 join 的
pt-query-digest --filter \
 '(($event->{Full_scan} || "") eq "yes") || (($event->{Full_join} || "") eq "yes")' \
 slow.log

# 7. 结果存到 review 表（自动建表）
pt-query-digest --user=root --password=*** \
 --review h=localhost,D=test,t=query_review --create-review-table \
 slow.log

# 8. 历史表（带时间窗）
pt-query-digest --user=root --password=*** \
 --review h=localhost,D=test,t=query_history --create-history-table \
 slow.log_20140401

# 9. 通过 tcpdump 抓 MySQL 协议再分析
tcpdump -s 65535 -x -nn -q -tttt -i any -c 1000 port 3306 > mysql.tcp.txt
pt-query-digest --type tcpdump mysql.tcp.txt

# 10. 分析 binlog
mysqlbinlog mysql-bin.000093 > mysql-bin000093.sql
pt-query-digest --type=binlog mysql-bin000093.sql

# 11. 分析 general log
pt-query-digest --type=genlog localhost.log

报告重点看 Rank（响应时间排序）、Response time（响应时间分布）、Callers（调用方）、SQL fingerprint 这几栏。

4. 第四步：buffer pool 参数调优

InnoDB 缓冲池是 MySQL 性能最关键的配置——读请求 99%+ 应该走 buffer pool，而不是磁盘。

4.1 三个核心参数

1
2
3
4
5


# /etc/my.cnf
[mysqld]
innodb_buffer_pool_size = 8G # 缓冲池总大小
innodb_buffer_pool_instances = 4 # 缓冲池实例数
innodb_buffer_pool_chunk_size = 1024M # 调整块大小

参数	推荐值	限制
`innodb_buffer_pool_size`	物理内存的 50%~80%	最大 64 TB
`innodb_buffer_pool_instances`	CPU 核心数的 1~2 倍	最大 64
`innodb_buffer_pool_chunk_size`	1024M（默认 128M）	chunk × instance ≤ pool_size

4.2 配置铁律

1

innodb_buffer_pool_size = innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances × N

如果你设的 size 不是 chunk × instance 的整数倍，MySQL 会自动调整到最近的合法值。设之前先在心里算清楚。

案例：16G 内存 8 核服务器

1
2
3
4
5
6
7


# 配置
innodb_buffer_pool_size = 8G
innodb_buffer_pool_chunk_size = 1024M
innodb_buffer_pool_instances = 4

# 验证（在线改）
SET GLOBAL innodb_buffer_pool_size = 8589934592; # 8G = 8*1024*1024*1024

4.3 评估命中率

1
2
3
4
5
6
7
8


-- 读取请求命中率（目标 ≥ 99%）
SELECT
 100 * (1 - (variable_value / (SELECT variable_value
 FROM performance_schema.global_status
 WHERE variable_name = 'Innodb_buffer_pool_read_requests')))
 AS hit_ratio
FROM performance_schema.global_status
WHERE variable_name = 'Innodb_buffer_pool_reads';

或者用 status 命令：

1
2
3
4


SHOW STATUS LIKE 'innodb_buffer_pool_read%';
# Innodb_buffer_pool_read_requests: 54329170948
# Innodb_buffer_pool_reads: 4890414994
# 命中率 = 1 - 4890414994/54329170948 ≈ 91.7% （不达标，加大 buffer pool）

目标：命中率 ≥ 99%。如果 95% 以下说明 buffer pool 配置严重不足。

5. 第五步：sysbench 基准测试

5.1 sysbench 安装

1
2
3
4
5
6
7


# Debian/Ubuntu
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.deb.sh | sudo bash
sudo apt -y install sysbench

# 验证
sysbench --version
# sysbench 1.0.20

5.2 4 步标准流程

① prepare（生成压测数据）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 默认通过 INSERT INTO 导数；指定 --db-ps-mode=disable 还能用 LOAD DATA LOCAL INFILE 提速 30%
sysbench oltp_read_write \
 --mysql-host=10.0.0.10 \
 --mysql-port=3306 \
 --mysql-user=root \
 --mysql-password='{{REDACTED}}' \
 --mysql-db=sbtest \
 --table-size=1000000 \
 --tables=10 \
 --threads=32 \
 --events=999999999 \
 --report-interval \
 prepare

--table-size=1000000 --tables=10 → 10 张 100 万行表，共 1000 万行。OLTP 场景要"像生产"才有意义。

② prewarm（把数据预热到内存）

1
2
3
4
5
6


sysbench oltp_read_write \
 --mysql-host=10.0.0.10 \
 --mysql-db=sbtest \
 --tables=10 --table-size=1000000 \
 --threads=32 \
 prewarm

③ run（开始压测）

1
2
3
4
5
6
7
8


sysbench oltp_read_write \
 --mysql-host=10.0.0.10 \
 --mysql-db=sbtest \
 --tables=10 --table-size=1000000 \
 --threads=64 \
 --time=60 \
 --report-interval=10 \
 run

④ cleanup（清理压测数据）

1
2
3
4
5


sysbench oltp_read_write \
 --mysql-host=10.0.0.10 \
 --mysql-db=sbtest \
 --tables=10 \
 cleanup

5.3 报告解读（3 个核心指标）

1

[ 60s ] thds: 64 tps: 5028.08 qps: 100641.26 (r/w/o: 70457.59/20121.51/10062.16) lat (ms,95%): 17.32 err/s: 0.00 reconn/s: 0.00

指标	含义	期望
tps	每秒事务数	越大越好
qps	每秒操作数（r+w+o）	越大越好
lat (ms, 95%)	95% 事务的执行耗时（毫秒）	越小越好
err/s	每秒错误数	应为 0

完整报告示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


SQL statistics:
 queries performed:
 read: 4276622
 write: 1221892
 other: 610946
 total: 6109460
 transactions: 305473 (5088.63 per sec.)
 queries: 6109460 (101772.64 per sec.)

Latency (ms):
 min: 5.81
 avg: 12.57
 max: 228.87
 95th percentile: 17.32
 sum: 3840044.28

Threads fairness:
 events (avg/stddev): 4773.0156/30.77
 execution time (avg/stddev): 60.0007/0.01

公平性（Threads fairness） 的 stddev 越小越好——如果某个线程的 stddev 远大于其他，说明有锁竞争或热点。

5.4 真实环境对比案例

主机	部署方式	硬盘	oltp_read_write TPS	oltp_point_select QPS
工控机 A	k8s + Ceph 块存储	固态	365.23	74017
工控机 B	k8s + Ceph 文件存储	固态	529.12	85793
工控机 C	k8s + NFS	固态	155.25	45935
服务器	docker	机械	649.67	110000
工控机 D	docker	固态	567.35	190000
工控机 E	二进制	固态	259.30	180000

关键发现：纯随机点查（oltp_point_select）受磁盘影响小，受 buffer pool 影响大；读写混合（oltp_read_write）则受磁盘 IO 显著影响。SSD > 机械盘是确定收益。

5.5 其他场景

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# CPU 性能
sysbench cpu --cpu-max-prime=20000 --threads=32 run
# 看 events per second

# 内存吞吐（推荐 1MB 块大小）
sysbench memory --memory-block-size=1M --memory-total-size=100G --num-threads=1 run
# 看 MiB/sec

# 磁盘 IO
sysbench fileio --file-num=1 --file-total-size=10G --file-test-mode=rndrw prepare
sysbench fileio --file-num=1 --file-total-size=10G --file-test-mode=rndrw run
sysbench fileio --file-num=1 --file-total-size=10G --file-test-mode=rndrw cleanup
# 看 IOPS（reads/s + writes/s）和吞吐量（read MiB/s + written MiB/s）

6. 实战：kill 阻塞连接 / 锁表排查

6.1 查锁表

1
2
3
4
5


-- 哪些表被锁住
SHOW OPEN TABLES WHERE In_use > 0;

-- 当前所有 InnoDB 事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

6.2 一键 kill 所有阻塞 trx

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 拼接成 KILL 命令，复制出来执行
SELECT
 GROUP_CONCAT(CONCAT('KILL ', trx_mysql_thread_id) SEPARATOR '; ') AS cmd
FROM INFORMATION_SCHEMA.INNODB_TRX;

-- 不 kill 自己的版本
SELECT
 GROUP_CONCAT(CONCAT('KILL IF EXISTS ', id) SEPARATOR '; ') AS kill_commands
FROM information_schema.PROCESSLIST
WHERE HOST LIKE '%example.telus.net%'
 AND id != CONNECTION_ID();

6.3 sleep 连接专项清理

应用层数据库连接池配置不当，大量 sleep 连接堆积：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 查 sleep 连接的客户端 IP
SELECT substring_index(host, ':', 1) AS client_ip, Command, Time
FROM information_schema.processlist;

-- 批量 kill 指定用户的 sleep 连接
SELECT
 GROUP_CONCAT(CONCAT('kill ', id) SEPARATOR '; ') AS cmd
FROM information_schema.PROCESSLIST
WHERE USER = 'app_user'
 AND command = 'Sleep'
 AND db = 'app_db';

7. 实战：wait_timeout 与连接池调优

7.1 现象：连接超时

应用日志抛：

1
2
3


The last packet successfully received from the server was 120,935 milliseconds ago.
The last packet sent successfully to the server was 381,491 milliseconds ago.
is longer than the server configured value of 'wait_timeout'.

7.2 修法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 查看当前超时
SHOW VARIABLES LIKE '%timeout%';

-- 在线调大
SET GLOBAL wait_timeout = 31536000;
SET GLOBAL interactive_timeout = 31536000;

-- 持久化（/etc/my.cnf）
[mysqld]
wait_timeout = 31536000
interactive_timeout = 31536000

wait_timeout 8 小时 = 28800 秒是默认值。如果你的应用有连接池（推荐！），设大些无所谓；如果没用连接池且应用端有长空闲期，应同时配合连接池侧的心跳（testOnBorrow / testWhileIdle）。

7.3 mysqldump 备份时数据库卡死

1

导出数据库，出现 SELECT /*!40001 SQL_NO_CACHE */ * FROM ，数据库卡死

原因：导出时大表加锁 + 缓存爆炸。

修法：

1
2
3
4
5
6
7


docker exec mysql /usr/bin/mysqldump \
 -u root -p'{{REDACTED}}' \
 --single-transaction \
 --quick \
 hxl_industry_iot_dev \
 --ignore-table=hxl_industry_iot_dev.hxl_location_historydata \
 > backup.sql

参数	作用
`--single-transaction`	用一致快照导出（仅 InnoDB）
`--quick`	一行一行从服务器取，不缓存到内存
`--ignore-table`	跳过不需要的表（如历史数据）

下一步

EXPLAIN 字段全解读：见《MySQL 实战速查》
索引优化案例：见《MySQL 索引优化实战》
备份恢复：见《MySQL 备份恢复实战》

2024+ 视角：MySQL 8.4/9.0 的性能调优新维度

Performance Schema 8.0+ 高级用法

performance_schema 在 8.4 LTS 起默认开启更多事件，比 slow_query_log 更细粒度：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


-- 1. 找出"扫了最多行"的 SQL
SELECT
 digest_text,
 count_star AS exec_count,
 sum_rows_examined AS total_examined,
 sum_rows_sent AS total_sent,
 sum_timer_wait/1000000000 AS total_ms
FROM performance_schema.events_statements_summary_by_digest
ORDER BY sum_rows_examined DESC
LIMIT 10;

-- 2. 找出"全表扫描次数最多"的表
SELECT object_name, count_read, count_fetch
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE count_read > 0
ORDER BY count_read DESC
LIMIT 10;

sys schema 1.x → 2.x（8.4+ 升级）

sys schema 是 Performance Schema 的"友好封装"，8.4 起全面升级：

1
2
3
4
5
6
7


-- sys.statements_with_full_table_scans
SELECT query, db, exec_count, total_latency
FROM sys.statements_with_full_table_scans
LIMIT 10;

-- sys.schema_redundant_indexes（推荐清理冗余索引）
SELECT * FROM sys.schema_redundant_indexes;

MySQL 8.0+ 的 `EXPLAIN ANALYZE`

1
2
3


EXPLAIN ANALYZE
SELECT * FROM orders
WHERE user_id = 123 AND created_at > '2024-01-01';

输出包含 实际执行时间（不再是"估算"）——比传统 EXPLAIN 精准一个量级。

InnoDB Buffer Pool 8.0+ 新参数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


[mysqld]
# 8.0.30+ 用容量单位（替代 innodb_log_file_size）
innodb_redo_log_capacity = 8G

# 8.0+ 自适应刷新（默认 on）
innodb_adaptive_flushing = ON
innodb_adaptive_flushing_lwm = 10

# 8.0+ 多线程刷新
innodb_page_cleaners = 4
innodb_cleaner_lsn_age_factor = high

资源组（Resource Group）8.0+

1
2
3
4
5
6
7
8


-- 创建资源组（绑定 CPU 核）
CREATE RESOURCE GROUP batch_group
 TYPE = USER
 VCPU = 2-3 -- 绑到 CPU 2、3 号核
 THREAD_PRIORITY = 10;

-- 给会话分配
SET RESOURCE GROUP batch_group;

典型场景：把报表/批处理绑到非关键 CPU 核，避免影响在线交易。

sysbench 1.0 → 1.0.20+ 的 OLTP 场景

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 2024+ 推荐用 lua 脚本（自定义场景更灵活）
sysbench \
 --db-driver=mysql \
 --mysql-host=10.0.0.10 \
 --mysql-db=sbtest \
 --oltp-table-size=1000000 \
 --oltp-tables-count=10 \
 --threads=64 \
 --time=120 \
 --report-interval=10 \
 oltp_read_write \
 prepare

# 报告解读：加关注 P99 延迟
# [ 120s ] thds: 64 tps: 5028.08 qps: 100641.26
# lat (ms,99%): 23.5 ← 99% 延迟（生产更应看这个）

2024+ 慢查询工具链

工具	状态	替代
`mysqldumpslow`	仍可用	适合 5.7/8.0 简单场景
`pt-query-digest`	2023 起归档不再维护	用 `mysql-slow-log-parser` / `sqlparse` + 自定义分析
`mydumper`	活跃	替代 mysqldump + 多线程导出
MySQL Enterprise Monitor	商业	高级告警 + 自动索引建议
Yearning / Archery	开源 SQL 审核平台	包含慢查询归集

2024+ 调优的"AI 加持"

MySQL HeatWave AutoML（Oracle 云）：自动识别热点查询并推荐索引
Yearning/Archery + LLM：自然语言问"今天哪些 SQL 慢"
Percona Monitoring and Management (PMM) 2.x：内置 Query Analytics + AI 异常检测

2024+ 实战建议

优先用 Performance Schema 替代 slow log——粒度更细、对生产影响更小
升 8.4 LTS 必看：MySQL 8.4 默认关闭 query_cache，相关参数都移除
9.0 升级注意：caching_sha2_password 已是唯一支持，JDBC 8.x+ 才兼容
生产压测：用 sysbench 1.0.20 + 真实业务流量回放，别再靠"拍脑袋"

经验补记

MySQL 9.0 起的"JavaScript 存储程序"——是的，现在可以在 MySQL 里写 JS 函数了，但仅适合 OLTP 边缘场景
SHOW PROFILE 在 8.0.26 起被弃用，统一用 performance_schema 替代

MySQL 实战速查：EXPLAIN 全字段解读 + 经典 SQL 题解

Mon, 15 Jun 2015 00:00:00 +0800

为什么写这篇：EXPLAIN 是 MySQL 调优的"听诊器"，但官方文档对 key_len、filtered、Extra 这些字段解释过于简略。本文用真实 SQL 示例把每个字段的含义讲透，并配 9 道 SQL 笔试题的标准解法——这些题在笔试/面试中重复率极高。

适用读者：需要做 SQL 优化的后端、面试准备、想系统性梳理 SQL 语法的同学。

前置知识：会基本 SQL，了解索引概念。

1. EXPLAIN 基础：一个完整案例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


EXPLAIN
SELECT F_LogId AS logId, F_CategoryId AS categoryId,
 F_SourceObjectId AS sourceObjectId,
 F_SourceContentJson AS sourceContentJson,
 F_OperateTime AS operateTime,
 F_OperateUserId AS operateUserId
FROM base_log
WHERE F_DeleteMark = 0
 AND (F_DeleteMark = 0)
ORDER BY F_OperateTime DESC
LIMIT 15;

第一次 EXPLAIN 输出：

id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	SIMPLE	base_log		ALL					1320000	10.00	Using where; Using filesort

type=ALL 是全表扫描。rows=1320000 表示扫描 132 万行。Using filesort 表示额外排序。

优化一：加索引

1

CREATE INDEX idx_OperateTime ON base_log (F_OperateTime);

第二次 EXPLAIN 输出：

id	select_type	table	type	key	key_len	rows	Extra
1	SIMPLE	base_log	index	idx_OperateTime	8	15	Using where; Backward index scan

type 从 ALL 升级到 index（全索引扫描）
rows 从 132 万降到 15（只用 LIMIT 15 即可）
Extra 出现 Backward index scan（对 F_OperateTime 倒序扫，命中 ORDER BY DESC）

结论：单列索引 + LIMIT 优化，让 132 万行扫描变成 15 行扫描，性能从秒级降到毫秒级。

2. EXPLAIN 字段逐列解读

字段	含义
`id`	SELECT 标识符。同一个 SELECT 共享 id；子查询/UNION 会递增
`select_type`	查询类型（SIMPLE / PRIMARY / UNION / SUBQUERY / DEPENDENT SUBQUERY）
`table`	当前行访问的表
`partitions`	匹配的分区（如果表是分区表）
`type`	最重要：join 类型，决定性能等级
`possible_keys`	优化器考虑使用的索引（不一定会用）
`key`	实际使用的索引
`key_len`	索引使用的字节数（可判断复合索引用了几个字段）
`ref`	哪个字段或常数与 key 一起被使用
`rows`	优化器估算要扫描的行数（实际可能偏差巨大）
`filtered`	过滤后剩余行数百分比
`Extra`	额外信息（`Using filesort` / `Using temporary` / `Using index` 等）

2.1 select_type 常见取值

SIMPLE：不含 UNION 和子查询的最简单查询
PRIMARY：最外层 SELECT
UNION：UNION 的第二或随后的查询
SUBQUERY：子查询中的第一个 SELECT
DEPENDENT SUBQUERY：依赖外层查询结果的子查询（通常很慢）

3. type 性能等级排序

从最差到最好：

1

ALL < index < range ~ index_merge < ref < eq_ref < const < system

type	含义	性能
`system`	表中只有 1 条数据	最佳
`const`	主键/唯一索引等值扫描，最多 1 行	极佳
`eq_ref`	多表 JOIN，每个前表结果只匹配后表 1 行	很好
`ref`	非唯一索引等值扫描，或最左前缀命中	好
`range`	索引范围扫描（=、<、>、BETWEEN、IN）	中
`index`	全索引扫描（不读数据文件）	较差
`ALL`	全表扫描	最差

底线：你的 SQL 不应该出现 type=ALL——除非表只有几十行，或者确实没有合适的过滤条件。

4. key_len 的字节数计算规则

key_len 能告诉你复合索引里实际用到了几个字段。

4.1 基础计算公式

字符串：

char(n)：n 字节
varchar(n)：
- utf8 编码：3 * n + 2 字节（2 是长度前缀）
- utf8mb4 编码：4 * n + 2 字节

数值：

类型	字节
TINYINT	1
SMALLINT	2
MEDIUMINT	3
INT	4
BIGINT	8

时间：

类型	字节
DATE	3
TIMESTAMP	4
DATETIME	8

字段属性：如果字段允许 NULL，多算 1 字节。

4.2 实战算例

1

KEY idx_name_age (name varchar(50), age int, dept varchar(20))

索引长度计算：

name varchar(50) utf8mb4：50 * 4 + 2 + 1 = 203（含 NULL 标志）
age int NOT NULL：4
dept varchar(20) utf8mb4：20 * 4 + 2 + 1 = 83

SQL 条件	命中索引	key_len
`WHERE name = 'a'`	name	203
`WHERE name = 'a' AND age = 10`	name + age	207
`WHERE name = 'a' AND age = 10 AND dept = 'b'`	全部	290
`WHERE age = 10`	无	NULL（不满足最左前缀）

关键洞察：key_len 越大说明用到的索引字段越多。如果 key_len 跟你期望的不一致，往往是漏写了等值条件或写错了列顺序。

5. Extra 常见提示与优化方向

Extra	含义	优化方向
`Using filesort`	额外的排序操作（不能用索引顺序）	让 ORDER BY 命中复合索引顺序
`Using temporary`	使用了临时表（GROUP BY / DISTINCT）	让 GROUP BY 命中索引
`Using index`	覆盖索引：只在索引里取数据，不回表	目标
`Backward index scan`	倒序索引扫描	通常对 `ORDER BY DESC` 是好事
`Using where`	存在 WHERE 子句筛选	配合 type 看
`Using index condition`	索引下推（ICP，5.6+）	通常是好事
`Impossible WHERE`	WHERE 永远为 false	删掉这种 SQL

6. 9 道经典 SQL 笔试题

表结构（学生选课经典案例）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


CREATE TABLE student (
 id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
 name CHAR(10) NOT NULL
);
INSERT INTO student(name) VALUES ('张三'),('李四');

CREATE TABLE course (
 id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
 name CHAR(20) NOT NULL
);
INSERT INTO course(name) VALUES ('语文'),('数学');

CREATE TABLE student_course (
 sid INT UNSIGNED,
 cid INT UNSIGNED,
 score INT UNSIGNED NOT NULL,
 FOREIGN KEY (sid) REFERENCES student(id),
 FOREIGN KEY (cid) REFERENCES course(id),
 PRIMARY KEY(sid, cid)
);
INSERT INTO student_course VALUES (1,1,80),(1,2,90),(2,1,90),(2,2,70);

6.1 查重名学生

1
2
3
4
5
6


SELECT id, name
FROM student
WHERE name IN (
 SELECT name FROM student GROUP BY name HAVING COUNT(*) > 1
)
ORDER BY name;

关系型数据库查重复行的通用套路：GROUP BY + HAVING COUNT > 1 + 子查询。

6.2 平均分不及格的学生

1
2
3
4


SELECT sid, AVG(score) AS avg_score
FROM student_course
GROUP BY sid
HAVING avg_score < 60;

WHERE 过滤记录，HAVING 过滤分组。聚集函数（AVG/COUNT/SUM）只能放 HAVING 里。

6.3 每门课都不低于 80 分的学生

1
2
3
4
5


SELECT DISTINCT sid
FROM student_course
WHERE sid NOT IN (
 SELECT sid FROM student_course WHERE score < 80
);

反向思维：要求"所有都 >= 80"等价于"不存在 < 80 的"。这是数理逻辑里的 ∀x:P ≡ ¬∃x:¬P。

6.4 每个学生的总成绩（含没成绩的）

1
2
3
4


SELECT name, SUM(score) AS total
FROM student
 LEFT JOIN student_course ON student.id = student_course.sid
GROUP BY sid;

INNER JOIN 会过滤掉没成绩的学生。用 LEFT JOIN 才能保留。

6.5 总成绩最高的学生

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


-- 标准解法
SELECT sid, SUM(score) AS sum_score
FROM student_course
GROUP BY sid
ORDER BY sum_score DESC
LIMIT 1;

-- 错误解法（虽然能跑，但语义反了）
SELECT sid, SUM(score) AS sum_score
FROM student_course
GROUP BY sid
HAVING sum_score >= ALL (
 SELECT SUM(score) FROM student_course GROUP BY sid
);

6.6 第 N 高的分数

1
2
3
4
5
6
7


-- 课程 1 第 2 高的分数
SELECT score
FROM student_course
WHERE cid = 1
GROUP BY score
ORDER BY score DESC
LIMIT 1, 1; -- offset=1, count=1

常见错误：LIMIT 2 然后 MIN(score)——因为执行顺序是 GROUP BY → MIN → ORDER BY → LIMIT，MIN 后 ORDER BY 已经无意义。

正确做法是用 LIMIT offset, count 跳过的语法。

6.7 每门课最高分的学生（核心）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 错误写法（MySQL 不会报错，但 sid 是无效的）
SELECT sid, cid, MAX(score)
FROM student_course
GROUP BY cid;

-- 正确写法：相关子查询
SELECT *
FROM student_course AS x
WHERE score >= (
 SELECT MAX(score) FROM student_course AS y WHERE cid = x.cid
);

GROUP BY 后的 SELECT 字段只能是：① GROUP BY 字段；② 聚集函数；③ 每个分组内均相同的字段。MySQL 的扩展语法（sid）默认开了 ONLY_FULL_GROUP_BY 是会拒绝的。

6.8 每门课的前 N 名

1
2
3
4
5
6
7
8
9


-- 每门课前 2 名
SELECT *
FROM student_course AS x
WHERE 2 > (
 SELECT COUNT(*)
 FROM student_course AS y
 WHERE y.cid = x.cid AND y.score > x.score
)
ORDER BY cid, score DESC;

核心思想：对于某个分数，如果同课程下比它高的分数少于 N 个，那么它就是前 N 名之一。

6.9 比赛两两组合

1
2
3
4


-- 4 队两两比赛，列出所有可能的比赛组合
SELECT a.name, b.name
FROM team a, team b
WHERE a.name < b.name;

自连接 + 不等式：本质是 team 表和自己做笛卡尔积，再过滤掉 a=b 和 a>b 的重复。

MySQL 索引优化实战：700 万行表从 3 秒到 50 毫秒

Mon, 15 Dec 2014 00:00:00 +0800

为什么写这篇：很多教程讲索引原理头头是道，但真碰到 700 万行、6 张表 join、含 GROUP BY 和 ORDER BY 的复杂 SQL 时，仍是无从下手。本文还原一次完整的"看 EXPLAIN → 找瓶颈 → 设计索引 → 上线验证"过程，所有 SQL 都在 INPLACE LOCK=NONE 下执行，不阻塞业务读写。

适用读者：在生产库做 SQL 优化的后端 / DBA，需要 INPLACE 在线 DDL 经验。

前置知识：了解 B+ 树索引、EXPLAIN 各字段含义、InnoDB 在线 DDL。

1. 场景还原：3 秒的复杂 SQL

业务背景：某安全风险排查平台，要查"过去一个月内、某岗位/某单位/某风险点下的排查任务"，分页展示。

表数据量：

表名	含义	估算行数
`risk_task`	排查任务主表	100 万
`risk_task_info`	任务时间信息表	700 万
`risk_ctrl`	风险管控措施	50 万
`risk_info`	风险点信息	5 万
`risk_unit`	风险单元	5000
`risk_object`	风险对象	2000
`dangersrc`	危险源	500

原始 SQL（6 张表 join，3 排序字段，分页 20）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


EXPLAIN
SELECT
 hprt.id AS task_id,
 hprg.id AS main_id,
 hprt.create_time,
 hprti.begin_time,
 hprti.end_time,
 hprt.check_time,
 hprt.check_user_id,
 hprt.check_status,
 CASE
 WHEN hprt.check_status = 0 AND hprti.end_time >= NOW() AND hprti.begin_time <= NOW() THEN '10'
 WHEN hprt.check_status = 2
 OR (hprt.check_status = 0 AND hprti.end_time < NOW()) THEN '11'
 WHEN hprt.check_status = 1 THEN '20'
 END AS STATUS,
 hpro.risk_object_name,
 hpru.risk_unit_name,
 hpd.dangersrc_name,
 hpri.risk_info,
 hpru.risk_type,
 hpri.risk_level,
 hprc.F_Id AS ctrl_id,
 hprc.screening_type,
 hprc.screening_num,
 hprc.screening_department,
 hprc.screening_position,
 hprc.post_psn_id,
 hprc.ctrl_measure,
 hprc.hd_content,
 hprc.post_psn_name,
 hpro.F_CreateUserId
FROM
 risk_task hprt
 INNER JOIN risk_task_info hprti USE INDEX (index_begin_time)
 ON hprt.task_info_id = hprti.task_info_id
 INNER JOIN risk_ctrl hprc
 ON hprt.ctrl_id = hprc.F_Id AND hprc.F_DeleteMark = 0
 INNER JOIN risk_info hpri
 ON hprc.risk_id = hpri.F_Id AND hpri.F_DeleteMark = 0
 INNER JOIN risk_unit hpru
 ON hpri.risk_unit_id = hpru.F_Id AND hpru.F_DeleteMark = 0
 INNER JOIN risk_object hpro
 ON hpru.risk_object_id = hpro.F_Id AND hpru.F_DeleteMark = 0
 INNER JOIN dangersrc hpd
 ON hpri.dangersrc_id = hpd.F_Id AND hpd.F_DeleteMark = 0
 LEFT JOIN risk_governance hprg
 ON hprg.task_id = hprt.id
WHERE
 hprt.F_DeleteMark = 0
 AND hprti.begin_time <= NOW()
 AND hprti.begin_time >= '2025-09-9 00:00:00'
 AND '2025-09-9 23:59:59' >= hprti.begin_time
ORDER BY
 hpro.risk_object_name,
 hpru.risk_unit_name,
 hprti.begin_time DESC,
 hprt.check_time DESC
LIMIT 20;

实测耗时：3.1 秒（业务方强烈要求压到 1 秒内）。

2. 第一次 EXPLAIN：定位瓶颈

跑 EXPLAIN 后重点看 3 个字段：

id	table	type	key	rows	Extra
1	hprti	range	index_begin_time	21548	Using index condition; Using temporary; Using filesort
1	hprt	ref	index_task_info_id	1	Using where
1	hprc	eq_ref	PRIMARY	1	Using where
1	hpri	eq_ref	PRIMARY	1	Using where
1	hpru	eq_ref	PRIMARY	1	Using where
1	hpro	eq_ref	PRIMARY	1	—
1	hpd	eq_ref	PRIMARY	1	Using where
1	hprg	ref	index_task_id	16	Using where; Using index

两个关键信号：

Using temporary：MySQL 在内存中建了一张临时表
Using filesort：在临时表上做了文件排序

这俩同时出现意味着：当前索引对 ORDER BY 的顺序毫无贡献，MySQL 只能把所有满足条件的行拉到临时表里再排。

driver 表的索引问题：

hprti 表上只有：

1
2


KEY `index_end_time` (`end_time`)
KEY `index_begin_time` (`begin_time`) -- 范围过滤用了

这个单列索引对 ORDER BY hprti.begin_time DESC 有帮助（Backward index scan），但对 4 个字段的复合排序完全不够。

3. 索引设计原则：覆盖索引 + 复合索引顺序

按"驱动表先建、JOIN 列次之、ORDER BY 列最后"的原则设计复合索引。

3.1 驱动表 `risk_task_info`：覆盖 WHERE + JOIN + ORDER BY

1
2
3
4
5


-- 旧索引（删）
KEY `index_begin_time` (`begin_time`)

-- 新索引：begin_time（过滤）+ task_info_id（JOIN hprt）+ end_time（覆盖 WHERE）
KEY `index_begin_time` (`begin_time`, `task_info_id`, `end_time`)

复合索引列顺序铁律：等值查询 > 范围查询 > 排序。这里 begin_time 是范围过滤，放最前；task_info_id 是等值 JOIN 字段放第二；end_time 顺手覆盖到 WHERE 条件。

3.2 关联表 `risk_object`：覆盖 JOIN + ORDER BY

1
2
3


-- 排序第一字段是 risk_object_name
-- JOIN 字段是 F_Id
KEY `idx_risk_object_name` (`risk_object_name`, `F_Id`)

3.3 关联表 `risk_unit`：覆盖 JOIN + ORDER BY + JOIN

1
2
3
4
5


-- 删除旧索引
KEY `index_object_id` (`risk_object_id`)

-- 新索引：risk_object_id（JOIN hpro）+ risk_unit_name（排序）+ F_Id（JOIN hpri）
KEY `idx_risk_unit_covering` (`risk_object_id`, `risk_unit_name`, `F_Id`)

3.4 关联表 `risk_task`：覆盖 JOIN + 过滤 + 排序

1
2
3
4
5
6


-- 删除旧索引
KEY `index_task_info_id` (`task_info_id`)
KEY `index_ctrl_id` (`ctrl_id`)

-- 新索引：task_info_id（JOIN hprti）+ F_DeleteMark（过滤）+ ctrl_id（JOIN hprc）+ check_time（排序）
KEY `idx_task_covering` (`task_info_id`, `F_DeleteMark`, `ctrl_id`, `check_time`)

4. 实施步骤：INPLACE 在线 DDL

MySQL 5.6+ 支持在线加索引：ALGORITHM=INPLACE + LOCK=NONE。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


-- 1. 删旧索引（INPLACE 操作，瞬间完成）
ALTER TABLE risk_task_info
 ALGORITHM = INPLACE,
 DROP INDEX index_begin_time;

-- 2. 加新索引（INPLACE，不锁表）
ALTER TABLE risk_task_info
 ALGORITHM = INPLACE,
 ADD INDEX idx_hprti_time_covering (begin_time, task_info_id, end_time);

-- 3. 改名复用（SQL 写死了 USE INDEX (index_begin_time)，不能改名）
ALTER TABLE risk_task_info
 ALGORITHM = INPLACE,
 RENAME INDEX idx_hprti_time_covering TO index_begin_time;

-- 4. risk_object 加索引
ALTER TABLE risk_object
 ALGORITHM = INPLACE,
 ADD INDEX idx_risk_object_name (risk_object_name, F_Id);

-- 5. risk_unit 替换索引
ALTER TABLE risk_unit
 ALGORITHM = INPLACE,
 DROP INDEX index_object_id;

CREATE INDEX idx_risk_unit_covering ON risk_unit(
 risk_object_id, risk_unit_name, F_Id
) ALGORITHM = INPLACE;

-- 6. risk_task 替换索引
ALTER TABLE risk_task
 ALGORITHM = INPLACE,
 DROP INDEX index_task_info_id,
 DROP INDEX index_ctrl_id;

CREATE INDEX idx_task_covering ON risk_task(
 task_info_id, F_DeleteMark, ctrl_id, check_time
) ALGORITHM = INPLACE;

实操记录：

操作	表大小	耗时
DROP + ADD + RENAME `index_begin_time`	700 万行	57 秒
DROP + CREATE `idx_risk_unit_covering`	5000 行	< 1 秒
DROP + CREATE `idx_task_covering`	100 万行	128 秒

700 万行上加复合索引耗时 57 秒，期间应用读写不阻塞（INPLACE LOCK=NONE）。这就是 MySQL 5.6+ 最大的运维红利——以前做这种事要停机维护。

5. 第二次 EXPLAIN：瓶颈消除

id	table	type	key	rows	Extra
1	hprti	range	index_begin_time	21548	Using index condition; Backwards index scan
1	hprt	ref	idx_task_covering	1	Using where
1	hprc	eq_ref	PRIMARY	1	Using where
1	hpri	eq_ref	PRIMARY	1	Using where
1	hpru	eq_ref	idx_risk_unit_covering	1	Using where
1	hpro	eq_ref	idx_risk_object_name	1	—
1	hpd	eq_ref	PRIMARY	1	Using where
1	hprg	ref	index_task_id	16	Using where; Using index

变化：

Using temporary 消失
Using filesort 消失
出现 Backwards index scan（对 index_begin_time 倒序扫，刚好满足 ORDER BY ... DESC）

实际耗时：从 3.1 秒 → 0.18 秒（17 倍提升），单次压测稳定在 50~180ms 区间。

6. CTE + GROUP BY 场景的索引设计

业务方后来又加了个"按风险对象统计完成率"的需求，用到了 CTE + GROUP BY：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


WITH baseInfos AS (
 SELECT d.F_Id AS mId, c.F_Id AS tId, b.F_Id AS oId, a.F_Id AS lId,
 d.NAME AS NAME, a.work_type AS workType
 FROM risk_ctrl a
 INNER JOIN risk_info b ON a.risk_id = b.F_Id
 INNER JOIN risk_object c ON b.risk_object_id = c.F_Id
 INNER JOIN hazard_major_management d ON d.identifier = c.riskobject_code
 WHERE b.F_DeleteMark = 0
 AND c.F_DeleteMark = 0
 AND d.F_DeleteMark = 0
 AND a.work_type IN ('1', '2', '3')
)
SELECT
 t.*,
 p.person_in_charge_main main,
 p.person_in_charge_technical technical,
 p.person_in_charge_operation operation
FROM (
 SELECT
 baseInfos.mId id,
 baseInfos.workType,
 baseInfos.NAME riskObjectName,
 date_format(info.begin_time, '%Y-%m-%d') beginTime,
 date_format(info.end_time, '%Y-%m-%d') endTime,
 IF(count(1) = sum(IF(k.check_status = 1, 1, 0)), '已完成', '未完成') AS checkStatus,
 sum(k.is_risk) hdCount,
 max(k.check_time) checkTime,
 k.check_user_id checkUser
 FROM risk_task k
 INNER JOIN risk_task_info info ON k.task_info_id = info.task_info_id
 INNER JOIN baseInfos ON k.ctrl_id = baseInfos.lId
 WHERE k.F_DeleteMark = 0
 GROUP BY
 baseInfos.mId,
 IF(checkUser IS NULL OR checkUser = '', baseInfos.workType, checkUser),
 info.begin_time,
 info.end_time
 ORDER BY info.begin_time DESC
) t
LEFT JOIN hazard_major_management p ON t.id = p.F_Id
LIMIT 20;

关键索引：

1
2
3
4
5
6
7
8
9


-- 覆盖过滤 + JOIN + 排序
CREATE INDEX idx_k_covering ON risk_task
 (F_DeleteMark, ctrl_id, task_info_id, check_time)
 ALGORITHM = INPLACE LOCK = NONE;

-- 覆盖 JOIN + 排序
CREATE INDEX idx_info_covering ON risk_task_info
 (task_info_id, begin_time, end_time)
 ALGORITHM = INPLACE LOCK = NONE;

CTE 本身不会自动建立索引，所以外层 JOIN 用到的字段（ctrl_id、task_info_id）必须在底层表上有索引。

7. 经验总结

7.1 三类必看 EXPLAIN 字段

字段	出现什么	优化方向
`type`	`ALL`	必须加索引
`Extra`	`Using filesort`	ORDER BY 字段没有命中索引顺序
`Extra`	`Using temporary`	GROUP BY / DISTINCT 没有命中索引顺序
`rows`	大于实际过滤后行数	索引选择度不够

7.2 复合索引列顺序铁律

1

等值过滤 > 范围过滤 > 排序 > 覆盖字段

错误示范：(order_field, where_field, id) —— 排序字段放最前，会导致 ORDER BY 之后无法再用 WHERE 字段做范围过滤。

7.3 INPLACE DDL 安全守则

守则	原因
先 DROP 旧索引再 ADD 新索引	避免索引膨胀导致 buffer pool 命中率下降
`LOCK = NONE` 必须显式写	不写默认可能是 `LOCK = SHARED`
一次 DDL 只动一张表	减少主从延迟
大表 DDL 前先在从库试	主从切换可用

7.4 不能光看 EXPLAIN 推算耗时

EXPLAIN 输出的 rows 是估算，不是实际扫描行数。type=ref 估算 1 行，真实扫了 50 万行的案例比比皆是。必须以 SELECT BENCHMARK() 或业务压测的真实耗时为准。

下一步

EXPLAIN 全字段解读 + 经典 SQL 题：见《MySQL 实战速查》
慢查询日志 + sysbench 压测：见《MySQL 慢查询与性能调优》
mysqldump + ibd2sql 备份恢复：见《MySQL 备份恢复实战》

MySQL 安装部署实战：Linux 二进制与 Windows Installer 双路

Fri, 15 Mar 2013 00:00:00 +0800

为什么写这篇：MySQL 的安装步骤看似简单，但glibc 版本依赖、socket 文件路径、字符集配置、远程 root 授权这四件事踩过坑的人不在少数。本文把"Linux 通用二进制 + Windows MSI Installer"两条路整理成可复制的 SOP，每一步都说明"为什么这么做"。

适用读者：需要在本地或服务器上从零搭建 MySQL 的开发者、运维、DBA。

前置知识：会用 tar/systemctl、懂得基础 SQL。

1. 安装前必看：版本与发行版选型

MySQL 的安装方式有很多种，按"可控性"从高到低排列：

方式	适用场景	关键特点
glibc 通用二进制包	生产服务器	自包含、可控、不依赖系统包管理器
源码编译	极致定制	自由选编译参数，但维护成本高
apt/yum 仓库包	个人开发机	一行命令搞定，但版本可能偏旧
MSI Installer（Windows）	Windows 服务器 / 开发机	图形化向导 + Windows 服务集成
Docker 镜像	容器化部署	隔离性好、启动最快（参考 0.5.4 批次的 MySQL Docker 实战）

选型建议：生产环境首选 glibc 通用二进制或 yum/apt 仓库包；开发机用 MSI Installer 最省事；K8s 集群用 Docker 镜像。

版本号含义（以 8.0.40 为例）：

第一个数字 8：主版本。从 8.0 起，MySQL 引入窗口函数、CTE、JSON 增强
第二个数字 0：次版本。8.0 时代的偶数版本（8.0.23、8.0.34、8.0.40）是 LTS 候选
第三个数字 40：补丁版本。bugfix 累计，越大越新

glibc 版本核查：

1
2
3
4


ldd --version
# 输出：ldd (GNU libc) 2.17
# MySQL 8.0.40+ 要求 glibc 2.28+
# CentOS 7 自带 glibc 2.17 → 装 8.0.40 会失败，要选 8.0.23 之前的版本

重要提示：MySQL 8.x 的二进制包对 glibc 有最低版本要求。CentOS 7 / RHEL 7 自带 glibc 2.17，最多支持到 MySQL 8.0.36；想要 8.0.40+ 需要升 glibc 或换 OS。

2. Linux 二进制安装：glibc 通用包

2.1 卸载旧版本

很多系统预装了 MariaDB 或老版本 MySQL，必须先卸载：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 查看
rpm -qa | grep -i mariadb
rpm -qa | grep -i mysql

# 卸载（-e --nodeps 强制卸载，可能破坏依赖，但生产库就是要干净）
rpm -e --nodeps mariadb-libs-5.5.44-2.el7.centos.x86_64
rpm -e --nodeps mysql-libs-5.1.73-5.el6_6.x86_64

# 删除残留配置
rm -f /etc/my.cnf

2.2 下载与解压

官方归档地址：https://downloads.mysql.com/archives/community/

1
2
3
4
5
6
7
8


cd /usr/local/

# 下载（以 MySQL 8.1.0 为例，根据 glibc 兼容性挑版本）
wget https://downloads.mysql.com/archives/get/p/23/file/mysql-8.1.0-linux-glibc2.28-x86_64.tar.xz

# 解压并改名
tar -xvf mysql-8.1.0-linux-glibc2.28-x86_64.tar.xz
mv mysql-8.1.0-linux-glibc2.28-x86_64 mysql

2.3 创建 mysql 用户与目录

1
2
3
4
5
6


mkdir -p /usr/local/mysql/data

groupadd mysql
useradd -g mysql mysql

chown -R mysql:mysql /usr/local/mysql

2.4 编辑 `/etc/my.cnf`

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


[mysql]
# 设置 mysql 客户端默认字符集
default-character-set=utf8

[mysqld]
# 设置 3306 端口
port = 3306
# 设置 mysql 的安装目录
basedir=/usr/local/mysql
# 设置 mysql 数据库的数据存放目录
datadir=/usr/local/mysql/data
# 允许最大连接数
max_connections=200
# 服务端使用的字符集默认为 8 比特编码的 latin1 字符集
character-set-server=utf8
# 创建新表时将使用的默认存储引擎
default-storage-engine=INNODB
# 表名是否区分大小写：1=不区分（推荐），0=区分
lower_case_table_names=1
# 单条 SQL 允许的最大包大小（导入大文件时需要调大）
max_allowed_packet=16M
# socket 文件位置
socket=/usr/local/mysql/mysql.sock
# 关闭符号链接（安全）
symbolic-links=0

[client]
port=3306
socket=/usr/local/mysql/mysql.sock

!includedir /etc/my.cnf.d

2.5 初始化数据库

1
2
3
4
5
6
7


cd /usr/local/mysql/bin/
./mysqld \
 --defaults-file=/etc/my.cnf \
 --basedir=/usr/local/mysql/ \
 --datadir=/usr/local/mysql/data/ \
 --user=mysql \
 --initialize

initialize（注意是两个横线）会生成一个临时 root 密码，请从控制台输出中抄下来，类似：
1
A temporary password is generated for root@localhost: w+,S,s+jp6to

如果报 libaio.so.1 缺失：

1
2
3


yum install -y libaio.so.1
# 如果上面解决不了，再装：
yum install -y libaio

2.6 注册系统服务

1
2


cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysql
chkconfig --add mysql

2.7 启动与重置密码

1
2
3
4
5
6
7


service mysql start

# 软链接 socket（解决 /tmp/mysql.sock 找不到的问题）
ln -s /usr/local/mysql/mysql.sock /tmp/mysql.sock

# 用临时密码登录
./mysql -h 127.0.0.1 -u root -p

登录后第一件事：把密码改成空，然后再设一个新的，避免密码策略拒绝你设的新密码。

1
2
3


use mysql;
update user set authentication_string='' where user='root';
quit;

退出后去掉 /etc/my.cnf 里的 skip-grant-tables（如果加了），重启服务，再空密码登录正式改密：

1

ALTER USER 'root'@'localhost' IDENTIFIED BY '{{REDACTED}}';

2.8 开启远程访问

1
2
3


use mysql;
update user set host='%' where user='root';
flush privileges;

现在 Navicat 就可以连了。

3. Windows MSI Installer 安装

Windows 上推荐用 MSI Installer（mysql-installer-community-8.0.40.0.msi），下载：https://dev.mysql.com/downloads/windows/installer/8.0.html。

3.1 安装类型选择

MSI Installer 提供 5 种安装类型，新手最常选的是：

Server only：只装 MySQL Server（推荐生产用）
Custom：自定义勾选组件
Developer Default：开发环境全套（带 Workbench、Connector/NET、Examples）

坑点：不要选 “Full”——它会带一堆用不到的 Connector、Excel 插件、Visual Studio Integration。

3.2 关键步骤截图导航

以下步骤与 MSI Installer 8.0.40 的引导顺序一一对应：

Choosing a Setup Type → 选 Server only
Check Requirements → 一路 Next，缺啥装啥
Installation → 点 Execute，等待 30s~2min
Product Configuration → 端口、密码类型、root 密码、Windows 服务名
Apply Configuration → 点 Execute，最后 Finish

端口配置：默认 3306，生产库强烈建议改成非常规端口（如 33060、33306），减少被自动扫描爆破的概率。

密码类型：建议选 Strong Password（8 位以上 + 大小写 + 数字 + 符号）。

Windows 服务名：默认是 MySQL80，不要改成 MySQL——避免与系统中可能存在的 MariaDB 冲突。

配置文件位置（关键！很多人找不到）：

1

C:\ProgramData\MySQL\MySQL Server 8.0\my.ini

C:\ProgramData 是隐藏目录，需要在文件资源管理器开启"显示隐藏的项目"。

3.3 用 Navicat 连本机 MySQL

主机：localhost 或 127.0.0.1
端口：3306（或你改的端口）
用户名：root
密码：刚才设置的那个

4. my.cnf / my.ini 关键参数

下面是一份生产环境推荐的精简配置（以 8G 内存 / 4 核服务器为例）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

[mysqld]
# 基础
user = mysql
port = 3306
basedir = /usr/local/mysql
datadir = /usr/local/mysql/data
socket = /usr/local/mysql/mysql.sock
pid-file = /usr/local/mysql/mysqld.pid

# 字符集
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

# 引擎
default-storage-engine = InnoDB
lower_case_table_names = 1

# 连接数
max_connections = 500
max_allowed_packet = 64M
wait_timeout = 28800

# InnoDB 缓冲池（核心：物理内存的 50%~80%）
innodb_buffer_pool_size = 4G
innodb_buffer_pool_instances = 4
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = O_DIRECT

# 慢查询
slow_query_log = on
long_query_time = 2
log-queries-not-using-indexes = on

进阶建议：生产库不要用默认的 latin1 字符集——中文乱码就是从这里来的。统一 utf8mb4 解决 emoji 表情和部分生僻字。

5. 常见安装问题与排错

5.1 启动报 `Unable to lock ./undo_001`

1
2


mv undo_001 undo_001.bak
cp -a undo_001.bak undo_001

这是 InnoDB undo 表空间被锁/损坏的经典症状，多发于断电/异常关机后。处理思路是替换文件、强制恢复：

1
2


# /etc/my.cnf
innodb_force_recovery=6

6 个等级的 innodb_force_recovery 含义（数字越大越激进）：

值	含义
1 (SRV_FORCE_IGNORE_CORRUPT)	忽略检查到的 corrupt 页
2 (SRV_FORCE_NO_BACKGROUND)	阻止主线程的 full purge 操作
3 (SRV_FORCE_NO_TRX_UNDO)	不执行事务回滚
4 (SRV_FORCE_NO_IBUF_MERGE)	不执行插入缓冲的合并
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)	不查看重做日志
6 (SRV_FORCE_NO_LOG_REDO)	不执行前滚

从 1 开始试，能起来就行。6 是最后一招——6 能起来意味着数据可能丢失，先 mysqldump 出来再重建。

5.2 `ERROR 1130 (HY000): Host 'xxx' is not allowed to connect to this MySQL server`

root 默认只能 localhost 登录，远程连不上。两种修法：

1
2
3
4
5
6
7
8
9


-- 修法 1：把 root 改成允许任意 IP（仅测试用）
CREATE USER IF NOT EXISTS 'root'@'%' IDENTIFIED WITH mysql_native_password BY '{{REDACTED}}';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

-- 修法 2（推荐生产）：创建一个专门的远程账号
CREATE USER 'app_user'@'10.0.0.%' IDENTIFIED WITH mysql_native_password BY '{{REDACTED}}';
GRANT SELECT, INSERT, UPDATE, DELETE ON your_db.* TO 'app_user'@'10.0.0.%';
FLUSH PRIVILEGES;

5.3 忘了 root 密码

按这个 SOP 找回（前提：你能物理访问服务器）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# 1. 在 [mysqld] 段加 skip-grant-tables
vim /etc/my.cnf
# 加入：
# [mysqld]
# skip-grant-tables

# 2. 重启服务
systemctl restart mysqld

# 3. 空密码登录
mysql -uroot

# 4. 清空 root 密码
use mysql;
flush privileges;
update user set authentication_string='' where user='root';

# 5. 退出，注释掉 skip-grant-tables，重启
# 6. 重新登录，设置新密码
mysql -uroot
ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码';
ALTER USER 'root'@'%' IDENTIFIED BY '新密码';
FLUSH PRIVILEGES;

5.4 `mysql_native_password` vs `caching_sha2_password`

MySQL 8.0 默认认证插件是 caching_sha2_password，但很多老客户端（Navicat 11/12、JDBC 5.x）不支持。连接时报：

1

Authentication plugin 'caching_sha2_password' cannot be loaded

修法：把密码插件降级为 mysql_native_password：

1
2
3


ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '{{REDACTED}}';
ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY '{{REDACTED}}';
FLUSH PRIVILEGES;

这只是兼容性回退方案。新应用应该用 caching_sha2_password——它支持密码轮换、不在网络中明文传密码。

下一步

SQL 速查 + EXPLAIN 解读：见《MySQL 实战速查：EXPLAIN 全字段解读 + 经典 SQL 题解》
索引调优案例：见《MySQL 索引优化实战：700 万行表从 3 秒到 50 毫秒》
慢查询与性能调优：见《MySQL 慢查询与性能调优：sysbench + buffer pool》
备份恢复：见《MySQL 备份恢复实战：mysqldump + ibd2sql + binlog2sql》

2024+ 视角：MySQL 8.4 LTS 与 9.x 时代

MySQL 版本节奏的"3+1"变化

从 2023 年起 Oracle 把 MySQL 改为 LTS + Innovation 双轨：

轨道	节奏	适用
LTS（Long Term Support）	8.0 → 8.4 → 9.7（每 2 年）	生产首选
Innovation	8.1 / 8.2 / 8.3 / 8.4 / 9.0…	新特性尝鲜，不推荐生产

生产推荐 8.4 LTS（2024-04 GA）—— 至少支持到 2032 年。

MySQL 8.4 LTS 关键变化

默认认证插件仍是 caching_sha2_password——但配套的 mysql_native_password 已完全标记 deprecated
information_schema 性能：元数据查询加速 30%
JSON 函数增强：JSON_TABLE()、JSON_VALUE() 标准化
复制改进：基于 WRITESET 的并行回放，多线程复制更稳
资源组（Resource Group） 完善：可按线程绑定 CPU 核

MySQL 9.0（2024-07 GA）核心新特性

JavaScript 存储程序：支持在存储过程里写 JS（基于 V8 引擎的 mle 组件）
向量数据类型 内部预览——VECTOR(N) + 距离函数，对标 pgvector
Performance Schema 优化：默认启用更多事件监控
隐式 cast 收紧：字符串 ↔ 数字转换告警更严格——历史项目升级可能踩坑

1
2
3
4
5
6
7
8
9


-- MySQL 9.0 向量（实验）
CREATE TABLE docs (
 id BIGINT PRIMARY KEY,
 content TEXT,
 embedding VECTOR(1536)
);
SELECT id FROM docs
ORDER BY VECTOR_DISTANCE(embedding, VECTOR('[0.1, 0.2, ...]'))
LIMIT 5;

2024+ 安装新选项

MySQL Shell (mysqlsh) 取代 mysql 客户端成为官方推荐
- 支持多语言（Python / JS / SQL）
- 内置 util.loadDump() / util.dumpInstance() 处理大库备份
MySQL Operator for Kubernetes GA——K8s 上生产级 MySQL 部署
MySQL InnoDB ClusterSet——多数据中心灾备"开箱可用"

2024+ 配置基线

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# /etc/my.cnf（2024+ 推荐）
[mysqld]
# 字符集
character-set-server = utf8mb4
collation-server = utf8mb4_0900_ai_ci # 8.0+ 默认

# InnoDB（核心）
innodb_buffer_pool_size = 物理内存 * 0.6
innodb_buffer_pool_instances = 8 # 8.0 起允许更多
innodb_redo_log_capacity = 8G # 8.0.30+ 新参数（替代 innodb_log_file_size）

# 复制
binlog_transaction_dependency_tracking = WRITESET
binlog_transaction_dependency_history_size = 10000

# 安全
default_authentication_plugin = caching_sha2_password

2024+ 的"坑"演进

caching_sha2_password 不再是坑：8.4 起所有官方驱动、ORM（Hibernate 6+ / MyBatis 3.5+）原生支持，老客户端升级即可
8.0 → 8.4 升级：字典结构变了，必须 mysql_upgrade + 两次重启
8.4 → 9.0 升级：引入 JavaScript 存储程序的库需重新编译；隐式 cast 收紧可能让旧 SQL 抛 warning

2024+ 选型决策

1
2
3
4
5
6
7
8
9


新项目选 MySQL 什么版本？
├── 保守（金融、政府） → 8.4 LTS（至少 2032 支持）
├── 互联网（云原生） → 8.4 LTS + MySQL Operator
├── 想用向量 / JS 存储程序 → 9.0（实验心态）
└── 已有 5.7 / 8.0 项目 → 升 8.4 LTS（路径清晰）

数据库国产化替代？
├── MySQL 业务系统 → TiDB / OceanBase / KES (DB_MODE=mysql)
└── 重点考虑兼容度 + 性能 → TiDB 8.x 兼容度最高（95%+）