普通数据源和druid数据源区别以及druid参数详解

一、普通数据源 和 Druid 数据源 的核心区别

1. 什么是普通数据源？

就是 Spring 默认的SimpleDataSource

• 只能获取连接、关闭连接
• 没有连接池
• 没有监控
• 没有防SQL注入
• 没有性能优化
• 只能小项目、测试用

缺点：
高并发下直接崩，频繁创建关闭连接，极慢、极耗资源。

2. 什么是Druid 数据源？

阿里开源的企业级数据库连接池
=连接池 + 监控 + 安全防火墙 + 性能统计 + 防注入 + 慢SQL记录

一句话：
普通数据源 = 只能走路
Druid = 跑车 + 导航 + 安全气囊 + 行车记录仪

二、Druid 最核心优势（必记）

1. 自带连接池（高并发不崩）
2. SQL监控（谁执行了什么SQL、耗时多久）
3. 慢SQL记录（自动抓慢查询）
4. SQL防火墙（防注入、防攻击）
5. 防止连接泄露
6. 性能远超默认数据源

三、Druid 所有参数 超详细解释（你配置里那些全部讲清）

我直接对照你配置里的参数一条一条讲人话：

initial-size:5# 启动时初始化5个连接min-idle:5# 最小保持5个空闲连接max-active:20# 最大同时20个连接（并发控制）max-wait:60000# 拿不到连接最多等60秒，不卡死

time-between-eviction-runs-millis:60000# 每60秒检查一次空闲连接是否失效

min-evictable-idle-time-millis:300000# 空闲连接超过300秒（5分钟）就被回收

validation-query:SELECT 1# 检查连接是否存活的SQL（mysql固定写这个）

test-while-idle:true# 空闲时检查连接是否有效（建议true）

test-on-borrow:false# 取出连接时不检查（true会变慢，生产建议false）

test-on-return:false# 归还连接时不检查

pool-prepared-statements:truemax-pool-prepared-statement-per-connection-size:20# 开启预编译缓存，提升查询速度

filters:stat,wall,slf4j# stat = 开启监控# wall = SQL防火墙（防注入）# slf4j = 输出日志

use-global-data-source-stat:true# 统一监控所有数据源

connection-properties:druid.stat.mergeSql=true;druid.stat.slowSqlMillis=500# mergeSql：合并相同SQL统计# slowSqlMillis：超过500毫秒算慢SQL

四、最简单总结（人话版）

普通数据源

• 无连接池
• 无监控
• 无安全
• 无性能
• 只能测试用

Druid 数据源

• 有连接池（高并发）
• 有监控（看SQL执行）
• 有防火墙（防注入）
• 有慢SQL记录
• 有性能优化
• 企业生产必须用

五、你如果要背面试题，我给你浓缩成3句

1. 普通数据源没有连接池，Druid是高性能连接池。
2. Druid自带监控、慢SQL、SQL防火墙、防注入。
3. 生产环境必须用Druid，普通数据源只能测试。

需要我给你一份可以直接复制的 Druid 生产最佳配置吗？
你直接粘到项目里就能用。

对于管理后台系统，如何配置druid，用户量1000人以内，每天活跃率100以内，主要是报表查询配置

管理后台专用 Druid 配置（1000用户、日活<100、报表查询）

我给你最精准、最稳定、最适合管理后台 + 报表查询的生产配置，
直接复制就能用，不浪费资源、不崩、不报警、报表不卡死。

一、你的业务场景分析（非常关键）

• 用户量：1000 人以内
• 日活：≤ 100 人
• 业务：管理后台 +报表查询（慢SQL多、查询时间长、批量数据）
• QPS：极低1~10
• 特点：
  • 并发极低
  • 查询时间比接口长
  • 偶尔有大SQL、统计SQL
  • 不能因为连接池小导致报表超时
  • 不能连接太多浪费MySQL资源

二、最终最优配置（管理后台 + 报表专用）

spring:datasource:druid:# 数据库基础配置url:jdbc:mysql://localhost:3306/xxx?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai&useSSL=falseusername:rootpassword:xxxdriver-class-name:com.mysql.cj.jdbc.Driver# ====================== 核心连接池（报表后台专用）======================initial-size:3# 启动初始化3个连接足够min-idle:3# 最小保留3个空闲max-active:15# 重点：报表允许一定并发，15完全足够max-wait:10000# 等待10秒，避免报表直接报错# 空闲连接回收（适合后台低频访问）time-between-eviction-runs-millis:60000# 60秒检测一次min-evictable-idle-time-millis:300000# 5分钟不使用才回收keep-alive:true# 连接保活，低频访问不中断# 连接有效性检测（生产标准）validation-query:SELECT 1test-while-idle:true# 后台空闲时自动检测test-on-borrow:false# 高并发才关，后台也必须关，提升速度test-on-return:false# 报表查询建议开启pool-prepared-statements:truemax-pool-prepared-statement-per-connection-size:20# ====================== 监控 + 防火墙 ======================filters:stat,walluse-global-data-source-stat:true# 慢SQL监控（报表非常有用）connection-properties:druid.stat.mergeSql=true;druid.stat.slowSqlMillis=2000# ====================== 连接泄漏保护（报表必开！）======================remove-abandoned:trueremove-abandoned-timeout:600# 报表允许执行10分钟，不被误杀log-abandoned:true

三、为什么这么配？（每条都给你讲清楚）

1. 连接数为什么配 3 ~ 15？

• 日活 < 100
• 并发操作 < 10
• max-active=15能同时支撑 10 个人一起打开报表不排队
• 再大就浪费MySQL连接

2. max-wait=10000（10秒）

报表查询比普通接口慢，
不能配3秒，否则报表查一半直接报错。

3. remove-abandoned-timeout=600（10分钟）

报表SQL可能跑几十秒
默认180秒（3分钟）会把正常报表杀死，所以必须改600秒。

4. slowSqlMillis=2000

超过2秒的SQL就是慢查询，方便你优化报表。

5. 为什么不开 slf4j 日志？

管理后台QPS低，没必要打印所有SQL，浪费磁盘。

四、这套配置的优势（最适合你）

1. 不浪费MySQL连接
2. 报表不会被Druid强制杀掉
3. 慢SQL能监控
4. 连接泄漏能自动回收
5. 低频访问不会断开连接
6. 并发够用，稳定不崩

五、你这种管理后台，绝对不能这样配（避坑）

• ❌ max-active = 100 → 浪费、MySQL变卡
• ❌ max-wait=3000 → 报表直接超时
• ❌ remove-abandoned-timeout=180 → 报表长查询被杀死
• ❌ 不开连接泄漏检测 → 报表忘关连接，系统慢慢卡死

六、一句话总结（最适合你的）

管理后台 + 日活100以内 + 报表查询 = 配 3~15 连接，等待10秒，超时10分钟，开启监控和泄漏保护。

需要我再给你一份：
《管理后台 MySQL 索引 + 慢SQL优化指南》
吗？对你报表系统提升巨大。

Druid 生产最佳配置

针对不同场景，比如用户量1万的花卉小程序，qps大概多少，如何配置，比如用户量300万的送水小程序，qps大概多少，如何配置，比如用于每天定时任务可能有100个sql顺序执行耗时2小时的ETL系统如何配置，比如用户量2000万以上的外卖平台如何配置，比如12306如何配置并说明原理？

先给你一套通用生产级 Druid 最佳配置模板，再按你说的5 个真实业务场景，给出推荐 QPS + 连接池参数 + 原理，全部是实战可用、直接复制的版本。

一、Druid 生产通用最佳配置（YAML）

spring:datasource:druid:# 核心连接数initial-size:8min-idle:10max-active:30max-wait:5000# 空闲连接检测time-between-eviction-runs-millis:60000min-evictable-idle-time-millis:300000keep-alive:true# 连接有效性检测validation-query:SELECT 1test-while-idle:truetest-on-borrow:falsetest-on-return:false# PSCache 提升性能pool-prepared-statements:truemax-pool-prepared-statement-per-connection-size:20# 监控与防火墙filters:stat,wall,slf4juse-global-data-source-stat:true# 慢SQLconnection-properties:druid.stat.mergeSql=true;druid.stat.slowSqlMillis=500

二、场景 1：花卉小程序（用户≈1 万）

预估 QPS

• 日活：几百～1000
• QPS：10～30

推荐 Druid 配置

initial-size:5min-idle:5max-active:15max-wait:3000time-between-eviction-runs-millis:60000min-evictable-idle-time-millis:180000keep-alive:truetest-while-idle:truetest-on-borrow:falsefilters:stat,wall

原理

• 流量小、波动小
• 连接数不用大，避免浪费 MySQL 资源
• 开启 keepalive 维持少量长连接，响应更快
• 关闭不必要监控，轻量稳定

三、场景 2：送水小程序（用户≈300 万）

预估 QPS

• 日活：3～8 万
• QPS：150～400

推荐 Druid 配置

initial-size:10min-idle:15max-active:50max-wait:3000time-between-eviction-runs-millis:30000min-evictable-idle-time-millis:180000keep-alive:truetest-while-idle:truetest-on-borrow:falsepool-prepared-statements:truemax-pool-prepared-statement-per-connection-size:30filters:stat,wall,slf4jconnection-properties:druid.stat.slowSqlMillis=1000

原理

• 订单、支付、库存类业务，短查询多
• max-active=50足够支撑 400 QPS
• 打开 PSCache 提升查询性能
• 开启慢SQL监控，方便优化

四、场景 3：ETL 定时任务（100 条 SQL，顺序执行 2 小时）

特点

• 长事务、大 SQL、批量查询、慢 SQL 多
• QPS 极低，但连接占用时间极长

推荐 Druid 配置

initial-size:1min-idle:1max-active:4max-wait:30000time-between-eviction-runs-millis:60000min-evictable-idle-time-millis:7200000# 2小时test-while-idle:falsetest-on-borrow:falsekeep-alive:truepool-prepared-statements:falsefilters:stat

原理

• ETL 不需要高并发，连接多了反而锁表/卡死
• max-active=4足够，防止占满 MySQL
• 关闭 PSCache，避免大 SQL 占用内存
• 延长空闲回收时间，防止任务中途连接被回收
• 关闭 wall 防火墙，避免大 SQL 被误杀

五、场景 4：外卖平台（用户≈2000 万）

预估 QPS

• 日活：100～300 万
• QPS：2000～8000

推荐 Druid 配置

initial-size:20min-idle:30max-active:120 ~ 200max-wait:1000 ~ 2000time-between-eviction-runs-millis:20000min-evictable-idle-time-millis:120000keep-alive:truetest-while-idle:truetest-on-borrow:falsepool-prepared-statements:truemax-pool-prepared-statement-per-connection-size:50filters:stat,wallconnection-properties:druid.stat.slowSqlMillis=300

原理

• 高并发、低延迟要求极高
• max-active给到120~200支撑高吞吐
• 缩短 max-wait，快速失败，防止雪崩
• 频繁检测空闲连接，保证连接健康
• 关闭 slf4j 日志，降低性能损耗

六、场景 5：12306 级别（超高峰、秒杀、超高并发）

量级

• 瞬时峰值QPS：5 万～20 万+
• 秒杀、锁竞争严重、短连接风暴

12306 级 Druid 配置思路

initial-size:50min-idle:80max-active:300 ~ 500max-wait:200 ~ 500time-between-eviction-runs-millis:10000min-evictable-idle-time-millis:60000keep-alive:truetest-while-idle:truetest-on-borrow:falsetest-on-return:falsepool-prepared-statements:truemax-pool-prepared-statement-per-connection-size:100filters:statwall:false# 高峰可临时关防火墙提升性能connection-properties:druid.stat.mergeSql=true

真正支撑 12306 的核心原理（重点）

1. Druid 只是基础连接池
2. 真正扛量靠：
   • 分库分表（sharding-jdbc）
   • 读写分离
   • 多级缓存（LocalCache + Redis + Caffeine）
   • 限流、降级、排队、削峰
   • 数据库只读实例 >= 10 个
3. Druid 作用：
   • 维持巨量长连接
   • 控制最大并发不打崩 MySQL
   • 快速回收、快速获取
   • 禁止任何多余日志/监控消耗性能

七、一句话判断你该配多少连接

• QPS 10～50→ max-active 10～20
• QPS 100～500→ max-active 30～60
• QPS 1000～5000→ max-active 80～150
• QPS 1 万+→ max-active 200～400 + 分库分表 + 读写分离

连接数不是越大越好，MySQL 单实例最佳连接数一般 200～400，超过会急剧变慢。

需要我给你做一份**《Druid 连接数计算公式 + 不同数据库最佳连接数表》**吗？你以后任何项目都能直接套用。

druid底层技术原理详解，中高级java开发工程师面试必会，实操指南

Druid 底层原理 + 面试高频 + 实操配置（中高级Java开发必备）

下面内容是真实面试常问、生产必须懂的 Druid 底层原理，不讲废话，全部是能直接说出口、能写进简历、能吊打面试官的干货。

一、Druid 是什么？一句话定位

Druid 是阿里巴巴开源的数据库连接池，同时自带：

• 连接池管理
• SQL 监控统计
• **SQL 防火墙（防注入）
• 慢SQL检测
• 连接泄漏检测
• 防御SQL攻击

它是 Java 生态生产环境使用率最高、最稳定的连接池。

二、核心底层原理（面试必考）

1. 连接池本质：一个“连接队列 + 并发控制”

Druid 内部维护两个关键队列：

1. 空闲连接队列（idle）
   可用连接，等待被业务拿走
2. 活动连接队列（active）
   正在被业务使用的连接

流程：

1. 应用请求连接
2. 先从idle 队列取
3. 没有空闲，则判断是否达到 max-active
4. 没达到：创建新连接
5. 达到了：阻塞等待 max-wait
6. 超时抛异常
7. 使用完归还到 idle

面试题：连接池的核心作用是什么？
标准答案：避免频繁创建/销毁连接（TCP 握手+MySQL认证极耗性能），复用连接，提高并发，降低延迟。

2. Druid 的“连接保活机制”（高频）

Druid 不会让连接“死在池里”，它有一套定时检测机制：

• time-between-eviction-runs-millis
  定时任务运行间隔
• min-evictable-idle-time-millis
  连接空闲多久会被回收
• test-while-idle = true
  后台异步检查空闲连接是否有效
• validation-query = SELECT 1
  检测连接是否存活的 SQL

原理：
后台一个DestroyTask 线程，定时扫 idle 连接，
无效连接直接丢弃，有效保留，保证你拿到的一定是可用连接。

3. 连接泄漏检测（高级知识点）

Druid 能自动发现“拿到连接没归还”的bug。

开启方式：

removeAbandoned = true removeAbandonedTimeout = 180 logAbandoned = true

原理：

• 给每个连接绑定一个使用时间戳
• 超过指定时间未归还
• 强制回收并打印堆栈
• 避免连接耗尽导致系统雪崩

面试题：生产出现“获取连接超时”怎么排查？
标准答案：看是否未关闭连接、事务过长、Druid 开启 removeAbandoned 定位泄漏位置。

4. SQL 统计与监控（stat 插件原理）

filters=stat开启后：

Druid 会通过JDBC 动态代理拦截所有 SQL：

• 记录执行时间
• 记录调用次数
• 记录读取行数
• 合并相同 SQL
• 统计慢SQL
• 输出到 Web 监控页面/druid

监控界面能看到：

• 哪个接口 SQL 最慢
• 哪个方法并发最高
• 是否有事务未提交
• 是否有连接泄漏

这是中高级开发排查慢查询神器。

5. SQL 防火墙（wall 插件原理）

filters=wall开启 SQL 防火墙：

拦截：

• 删表语句（drop table）
• 删库（drop database）
• 大量注入攻击语句
• 禁止全表更新/删除（where 1=1）
• 禁止 union 查询注入

原理：Druid 内置一个SQL 语法解析器，解析 AST 语法树，判断是否危险。

6. PSCache 原理（提升性能）

pool-prepared-statements = true max-pool-prepared-statement-per-connection-size = 20

MySQL 开启后会缓存PreparedStatement，
避免重复解析 SQL，高并发下性能提升明显。

三、中高级面试高频 10 问（标准答案）

1. Druid 相比 HikariCP 优缺点？

Druid：

• 功能全（监控、防火墙、防泄漏）
• 稳定，适合金融/政务/传统企业
• 略微慢一点点（功能多）

HikariCP：

• 极快，性能第一
• 轻量
• 无监控、无防火墙
• 适合高并发微服务

标准答案：Druid 功能强适合生产运维；Hikari 性能高适合云原生高并发。

2. 连接池参数怎么设计？

公式（Oracle/MySQL通用）：

连接数 = ((核心数 * 2) + 有效磁盘数)

MySQL 单实例最佳连接数：100~200
超过 300 性能开始下降。

3. max-active 越大性能越好吗？

错！
连接越多，MySQL 锁竞争、线程切换越严重，性能反而暴跌。

4. 为什么不建议开启 test-on-borrow？

每次拿连接都执行 SELECT 1，高并发下会增加 RT，降低吞吐量。
生产一律用test-while-idle后台异步检测。

5. Druid 如何实现高可用？

• 连接保活
• 连接泄漏回收
• 长时间空闲检测
• 异常连接剔除
• 最大并发控制

6. 什么是连接泄漏？怎么解决？

拿到连接未关闭，导致连接耗尽。
开启 removeAbandoned 自动回收 + 打印堆栈定位代码。

7. 如何定位慢SQL？

druid stat 监控 + slowSqlMillis 配置。

8. wall 防火墙能防什么？

SQL 注入、删库、全表更新、危险函数。

9. Druid 底层用了什么设计模式？

• 代理模式（拦截SQL）
• 单例模式（连接池实例）
• 建造者模式（配置构建）
• 策略模式（不同过滤器）

10. 为什么 Druid 适合金融、政务系统？

监控全面、安全可控、稳定、可审计、可追溯、防SQL注入。

四、生产级实操配置（直接复制）

spring:datasource:druid:driver-class-name:com.mysql.cj.jdbc.Driverurl:jdbc:mysql://localhost:3306/test?useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=trueusername:rootpassword:root# 核心连接数initial-size:10min-idle:10max-active:50max-wait:3000# 连接检测test-while-idle:truetest-on-borrow:falsetest-on-return:falsevalidation-query:SELECT 1time-between-eviction-runs-millis:60000min-evictable-idle-time-millis:180000# PSCachepool-prepared-statements:truemax-pool-prepared-statement-per-connection-size:20# 防火墙 + 监控filters:stat,wall,slf4juse-global-data-source-stat:true# 慢SQLconnection-properties:druid.stat.mergeSql=true;druid.stat.slowSqlMillis=500# 连接泄漏保护remove-abandoned:trueremove-abandoned-timeout:180log-abandoned:true

五、如何打开 Druid 监控页面（实操）

1. 引入依赖

<dependency><groupId>com.alibaba</groupId><artifactId>druid-spring-boot-starter</artifactId><version>1.2.20</version></dependency>

2. 访问

http://localhost:8080/druid

能看到：

• SQL 统计
• 连接池状态
• 慢SQL
• Web 应用防火墙
• URI 监控

六、一句话总结（面试装X金句）

Druid 本质是一个基于双队列实现、自带定时检测、SQL 代理拦截、连接泄漏防护、SQL 防火墙、全方位监控的企业级数据库连接池，是 Java 后端生产环境最稳定、最可控、最适合运维排查问题的连接池方案。

需要我给你整理一份《Druid 面试 20 题终极答案》吗？
可以直接背，面试稳过。

如何配置Druid的连接泄漏检测功能？ 高性能MYSQL实战指南，从入门到精通

第一部分：Druid 连接泄漏检测完整配置 + 原理 + 排查（Java 中高级必考）

我给你生产可直接用、面试能直接说的完整版，包含：
开启方式 + 配置含义 + 原理 + 怎么定位泄漏代码

一、Druid 连接泄漏检测最终配置（直接复制）

spring:datasource:druid:# 核心 3 项 → 开启连接泄漏检测remove-abandoned:true# 开启连接泄漏强制回收remove-abandoned-timeout:180# 连接超过 180 秒未归还 → 判定泄漏log-abandoned:true# 打印泄漏代码堆栈（最重要！）# 基础连接池配置initial-size:5min-idle:5max-active:20max-wait:5000test-while-idle:truetest-on-borrow:falsevalidation-query:SELECT 1

二、3 个核心参数人话解释

1. remove-abandoned = true
   打开“连接泄漏自动回收”开关

2. remove-abandoned-timeout = 180
   单位：秒
   连接被拿走后超过 180 秒没归还 → 判定泄漏
   生产建议：180 / 300 秒
   （不能太短，否则长查询会被误杀）

3. log-abandoned = true
   自动打印泄漏代码的堆栈！
   你能直接看到：

   • 哪个类
   • 哪个方法
   • 第几行
     拿走了连接没关闭！

三、Druid 连接泄漏检测底层原理（面试必背）

1. 每次调用getConnection()，Druid 会记录获取时间 + 当前线程堆栈
2. 后台启动一个AbandonedConnectionTask定时任务
3. 扫描所有活动连接
4. 发现连接占用时间 >remove-abandoned-timeout
5. 判定泄漏
6. 强制回收连接+打印错误堆栈

四、什么叫连接泄漏？（90% 新人踩坑）

// 错误代码 → 泄漏！Connectionconn=datasource.getConnection();// 执⾏SQL// 不关闭！不释放！连接永远占用！// 最终 max-active 耗尽 → 系统卡死

连接池满了报错就是：
wait timeout error | Could not get connection

五、如何根据日志定位泄漏代码？

开启 log-abandoned 后，日志会输出：

ERROR - AbandonedConnectionCleanupTask Connection abandoned. Stack trace: com.xx.service.UserService.getList(UserService.java:55) <-- 泄漏代码行

直接定位！

六、生产注意事项（高级）

1. 长事务/长SQL业务
   remove-abandoned-timeout要调大（300~600）
2. 不要设置太小
   否则正常业务会被误杀
3. 最终解决方案
   泄漏检测只是兜底保护
   真正根治：用完连接必须关闭
   使用 try-with-resources 自动关闭

第二部分：高性能 MySQL 实战指南（从入门到精通）

企业级、面试级、可直接用于项目优化

一、MySQL 高性能优化 4 大核心方向

1. SQL 优化（80% 性能问题来源）
2. 索引优化（速度提升 10~1000 倍）
3. 表结构优化
4. 服务器 / 连接池 / 架构优化

二、SQL 优化实战（入门 → 精通）

1. 最关键：避免全表扫描

坏SQL：

select*fromuserwherenamelike'%张三%'select*fromuserwhereage+1=18select*fromuserorderbyrand()

好SQL：

selectid,namefromuserwherename='张三'

2. 必须会用：explain 执行计划

看 3 个字段：

• type：最好 range / ref / const（最差 ALL）
• key：是否命中索引
• Extra：不要出现 filesort / temporary

3. 慢SQL开启

slow_query_log = 1 long_query_time = 1 log_queries_not_using_indexes = 1

三、索引优化（高性能核心）

1. 最左前缀原则

索引 (a,b,c)
where a=? → 命中
where a=? and b=? → 命中
where b=? → 不命中

2. 哪些字段适合建索引

• where 经常查询
• order by
• group by
• join 关联字段

3. 哪些不建索引

• 大量重复（性别）
• 小表（<1000行）
• 经常更新的字段

4. 覆盖索引（性能之王）

查询的字段都在索引里，不需要回表

selectid,namefromuserwherename='xx'

name + id 就是覆盖索引

四、表结构设计优化（精通必备）

1. 优先使用 tinyint、int、bigint 正确选择
2. 使用 not null，提高查询性能
3. datetime 替代 timestamp
4. varchar 长度合理，不要盲目 255
5. 大字段拆分到子表
6. **禁止使用 select ***

五、MySQL 服务器优化（生产实战）

1. 最重要 3 个参数

innodb_buffer_pool_size = 70% 内存 innodb_log_file_size = 1G innodb_flush_log_at_trx_commit = 1 (安全) / 2 (性能)

2. 连接数

max_connections = 1000

3. 关闭不必要的日志

general_log = 0

六、架构级高性能（高级进阶）

1. 读写分离
   主库写，从库读

2. 分库分表
   水平拆分（user_0、user_1…）

3. 多级缓存
   Caffeine → Redis → MySQL

4. 异步化
   MQ 削峰、异步写库

七、MySQL 性能排查万能步骤（实战）

1. 看慢查询日志
2. explain 分析SQL
3. 看是否命中索引
4. 优化SQL + 建索引
5. 调整连接池（Druid）
6. 调整缓冲池（buffer_pool）
7. 读写分离/分库分表

八、我能给你的超级大礼包

如果你需要，我可以继续给你：

1. Druid 面试 30 问（含标准答案）
2. MySQL 高性能笔记（完整版PDF结构）
3. 生产SQL优化100例
4. 分库分表实战教程
5. MySQL 索引从入门到精通

你要我继续更哪一部分？