简介：本资源是一份面向数据库开发初学者与中小型应用开发者的技术指导文献，聚焦MySQL应用程序开发全流程实践，涵盖系统平台选型、B/S与C/S架构下的开发工具适配、逻辑建模与反规范化权衡、列类型选择原则、索引设计策略及安全编码要点。全文基于2003年《空军雷达学院学报》发表的学术论文整理而成，内容扎实，兼顾理论依据与工程落地建议，特别适合需快速构建稳定、高效MySQL后端的Web项目或局域网应用开发者参考。资源为单文件PDF，大小仅144KB，轻量易读，便于离线查阅核心方法论。目前已有114人学习下载，文中详述内存表优化、统计值表设计、表分割技巧、ENUM列使用、WHERE条件索引建立等实操细节，并附有典型场景下的性能调优思路与安全防护措施，是理解MySQL开发底层逻辑与规避常见陷阱的优质入门指引。

1. 为什么你写的 MySQL 应用程序总在上线后崩得悄无声息？

这不是数据库没装好、不是 SQL 写错了、也不是连接池配少了——而是你把「基于 MySQL 的应用程序开发」当成了一门「会写 SELECT 就能交差」的手艺。真实场景里，一个学生选课系统上线第三天，因UPDATE score SET value = value + 10 WHERE id = ?被并发调用 200 次，导致成绩多加了 3 倍；一个电商订单服务在凌晨批量更新库存时，因没设SQL_MODE=STRICT_TRANS_TABLES，把NULL插进NOT NULL字段却只报 warning，日志里安静得像什么都没发生，直到财务对账差出 47 万元。这些不是玄学，是 MySQL 在应用层暴露的刚性契约：它不替你做业务判断，但会用锁、事务隔离、类型隐式转换、默认值策略、字符集继承规则，一层层把你没声明的意图翻译成不可逆的数据行为。本文不讲「MySQL 怎么安装」或「Navicat 怎么连」，只聚焦一线工程师每天要亲手填的坑：如何让代码里的INSERT真正落地为原子写入，让JOIN不因索引缺失拖垮接口，让datetime字段不因时区错位把用户下单时间记成昨天。适合正在用 Java/Python/Node.js 写 Web API、且已能连上 MySQL 但常被线上数据异常反向排查到怀疑人生的开发者。

2. 从连接建立到查询执行：MySQL 应用链路的 5 层校验点

应用和 MySQL 的交互不是「发一条 SQL → 回一个结果」的扁平通道，而是一条带状态、有契约、可中断的流水线。跳过任意一层校验，都可能让错误在下游爆发。我一般会按这 5 层逐级确认，而不是一上来就查慢查询日志。

2.1 连接层：别信“localhost”就是本地，socket 路径才是真相

很多开发者以为jdbc:mysql://localhost:3306/db就是走 TCP，其实 Linux 下localhost默认走 Unix socket（除非显式加?allowPublicKeyRetrieval=true或改 host 为127.0.0.1）。而 socket 路径在不同发行版差异极大：

• CentOS 7/8 默认是/var/lib/mysql/mysql.sock
• Ubuntu/Debian 多为/var/run/mysqld/mysqld.sock
• Docker 官方镜像里是/var/run/mysqld/mysqld.sock
• macOS Homebrew 安装则是/tmp/mysql.sock

一旦路径错，就会报经典错误：

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'

验证命令（不用密码，只测 socket 是否通）：

mysql --socket=/var/run/mysqld/mysqld.sock -u root -e "SELECT VERSION();"

提示：Java JDBC 连接串中若需强制走 TCP，请把localhost替换为127.0.0.1；Python 的pymysql则需显式传参unix_socket=None。

2.2 认证层：MySQL 8.0+ 的 caching_sha2_password 会让旧驱动直接拒连

MySQL 5.7 默认用mysql_native_password，而 8.0+ 新建用户默认用caching_sha2_password。如果你用的是 Spring Boot 2.1.x 或更早版本（内置 mysql-connector-java < 8.0.16），或者 Python 的PyMySQL < 1.0，连接时会直接抛异常：

Public Key Retrieval is not allowed

或更隐蔽的：

Access denied for user 'app'@'%' (using password: YES)

根本原因：新认证插件要求客户端支持 RSA 密钥交换，但老驱动要么不支持，要么默认禁用公钥获取。

解法分三类：

• ✅推荐（安全）：升级驱动并启用公钥（Java 示例）：

  spring.datasource.url=jdbc:mysql://127.0.0.1:3306/mydb?serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true&useSSL=false

• ⚠️临时（兼容）：降级用户认证方式（仅限测试环境）：

  ALTER USER 'app'@'%' IDENTIFIED WITH mysql_native_password BY 'yourpass'; FLUSH PRIVILEGES;

• 🚫禁止：设skip-grant-tables—— 这等于把数据库大门焊死再拿钥匙砸锁，生产环境零容忍。

2.3 会话层：每个连接都有独立的 SQL_MODE、time_zone、character_set

MySQL 不是全局单例，每个 TCP 连接启动时会继承全局变量，但可被会话级覆盖。而 ORM 或连接池（如 HikariCP、DBUtils）往往复用连接，导致前一个请求设的SET time_zone = '+00:00'影响后一个中国用户的NOW()结果。

必须检查的 3 个会话变量（在应用启动后、首次查询前执行）：

-- 强制严格模式，避免隐式截断（如 INSERT 'abcde' 到 VARCHAR(3) 只存 'ab' 还不报错） SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO'; -- 统一时区，避免 NOW() 和 JDBC Timestamp 解析错位 SET SESSION time_zone = '+08:00'; -- 显式声明字符集，防止 utf8mb4 和 utf8 混用导致 emoji 存储失败 SET SESSION character_set_client = utf8mb4; SET SESSION character_set_results = utf8mb4; SET SESSION character_set_connection = utf8mb4;

注意：Spring Boot 中可在application.yml里统一配置：

spring: datasource: hikari: connection-init-sql: "SET SESSION sql_mode='STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO'; SET SESSION time_zone='+08:00';"

2.4 查询层：预编译语句（Prepared Statement）不是性能优化，是安全刚需

很多人以为PreparedStatement只是为了防 SQL 注入，其实它在 MySQL 侧还承担着「查询计划缓存」职责。未预编译的Statement每次执行都会触发SQL_PARSE → QUERY_OPTIMIZE → EXECUTE全流程，而PreparedStatement第一次解析后，后续相同结构 SQL 直接复用执行计划。

但注意陷阱：参数类型必须与字段类型严格匹配。例如：

// ❌ 错误：int 参数传给 VARCHAR 字段，MySQL 会隐式转换，导致索引失效 ps.setInt(1, 123); // 但 name 字段是 VARCHAR ps.executeQuery("SELECT * FROM user WHERE name = ?"); // ✅ 正确：用 setString 保持类型一致 ps.setString(1, "123");

验证是否走索引：执行EXPLAIN后看key列是否非 NULL，type是否为ref或const，而非ALL（全表扫描）。

2.5 事务层：AUTOCOMMIT=1 是应用层最大的幻觉

MySQL 默认autocommit=1，意味着每条 DML（INSERT/UPDATE/DELETE）都是独立事务。但业务逻辑从来不是单条 SQL：「扣库存 + 写订单 + 发消息」必须原子。如果没显式BEGIN，中间某步失败，前面已提交的无法回滚。

正确姿势（以 Java JDBC 为例）：

conn.setAutoCommit(false); // 关闭自动提交 try { stmt.executeUpdate("UPDATE stock SET qty = qty - 1 WHERE id = 1001 AND qty >= 1"); stmt.executeUpdate("INSERT INTO order (uid, item_id) VALUES (123, 1001)"); stmt.executeUpdate("INSERT INTO msg_queue (topic, payload) VALUES ('order', '...')"); conn.commit(); // 全部成功才提交 } catch (SQLException e) { conn.rollback(); // 任一失败则回滚 throw e; } finally { conn.setAutoCommit(true); // 恢复默认，避免连接池污染 }

关键细节：rollback()后必须setAutoCommit(true)，否则该连接归还连接池后，下一个使用者会继承autocommit=false状态，造成诡异的「SQL 不生效」问题。

3. 表结构设计：那些让你半夜被 call 起来改 schema 的致命选择

应用层的问题，70% 源于建表时没想清楚业务语义。MySQL 不是 Excel，INT和BIGINT差的不是存储空间，是未来三年订单 ID 是否爆掉；VARCHAR(255)和TEXT决定你能否加索引；DATETIME和TIMESTAMP的时区行为直接决定用户看到的「下单时间」是不是他点击按钮的那一刻。

3.1 主键：为什么 UUID/GUID 是高并发写入的隐形杀手

新手常为「全局唯一」选CHAR(36)存 UUID，但这是对 MySQL B+ 树索引的严重误用：

• UUID 是随机字符串，插入时无法追加到索引末尾，必然引发页分裂（page split）
• 每次插入都要定位到中间某个页，B+ 树深度增加，I/O 次数飙升
• InnoDB 主键即聚簇索引，主键越大，二级索引叶子节点存储的主键值也越大，空间浪费成倍放大

实测对比（100 万行插入耗时，SSD 环境）：

替代方案（兼顾唯一性与写入性能）：

• ✅雪花算法 ID（Snowflake）：64 位整数，时间戳前缀保证趋势递增，BIGINT存储，完美适配 B+ 树
• ✅COMPOUND_ID组合主键：如(tenant_id, order_seq)，tenant_id高频查询，order_seq每租户内自增
• ✅ULID（UUID-like but lexicographically sortable）：字符串但按时间排序，比 UUID 好一点，仍不如整数

我一般会这样建：

CREATE TABLE order ( id BIGINT NOT NULL PRIMARY KEY COMMENT '雪花ID，全局唯一且递增', tenant_id INT NOT NULL COMMENT '租户ID，用于分库分表路由', created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3), INDEX idx_tenant_created (tenant_id, created_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

3.2 字段类型：INT + 5不是数学题，是类型溢出预警

INT在 MySQL 中是 4 字节有符号整数，范围-2147483648到2147483647。当业务增长后，user_id或order_id达到 20 亿时，INSERT会静默转成2147483647（最大值），后续所有 ID 都卡在这个数，形成「数据雪崩」。

更危险的是TINYINT：

• TINYINT默认是有符号的，范围-128~127
• 但很多人写TINYINT存状态码（0=待处理, 1=成功, 2=失败），却忘了2是合法值，而128会溢出成-128

血泪经验：

• 所有主键、计数器、ID 类字段，无脑用BIGINT UNSIGNED（0 ~ 18446744073709551615）
• 状态码用TINYINT UNSIGNED，并加CHECK (status IN (0,1,2))（MySQL 8.0.16+ 支持）
• 金额字段必须用DECIMAL(12,2)，绝不用 FLOAT/DOUBLE—— 浮点数二进制存储会导致0.1 + 0.2 != 0.3，财务系统零容忍

3.3 时间字段：DATETIMEvsTIMESTAMP，选错等于放弃时区控制

选型原则：

• ✅记录绝对时间（如创建时间、支付时间）→ 用DATETIME
  因为用户在北京下单，时间就是2024-05-20 14:30:00，不该因服务器切到美国机房就变成2024-05-20 02:30:00
• ✅记录相对时间（如会话过期时间、缓存失效时间）→ 用TIMESTAMP
  因为它天然适配「UTC 统一存储 + 本地时区展示」，避免跨时区运维混乱

实操建议：

CREATE TABLE user ( id BIGINT PRIMARY KEY, created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3), -- 绝对时间，不随会话变 last_login_at TIMESTAMP(3) NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP(3), -- 相对时间，自动维护 -- ⚠️ 注意：不要给 DATETIME 加 ON UPDATE，MySQL 5.6+ 不支持 );

3.4 字符集与排序规则：utf8mb4_unicode_ci不是摆设，是 emoji 和搜索准确性的底线

MySQL 的utf8实际是utf8mb3，最多存 3 字节字符，不支持 emoji（需 4 字节）。而utf8mb4才是真正的 UTF-8。

更关键的是排序规则（Collation）：

• utf8mb4_general_ci：MySQL 5.7 及之前默认，不区分 emoji，不区分某些语言重音（如é和e视为相同）
• utf8mb4_unicode_ci：基于 Unicode 9.0.0，支持更精准的比较，但性能略低
• utf8mb4_0900_as_cs（MySQL 8.0+）：大小写敏感 + 重音敏感，适合用户名唯一性校验

建库建表必须显式声明：

CREATE DATABASE myapp DEFAULT CHARACTER SET = utf8mb4 DEFAULT COLLATE = utf8mb4_0900_as_cs; CREATE TABLE comment ( id BIGINT PRIMARY KEY, content TEXT NOT NULL, -- 用户名必须大小写敏感，避免 'Admin' 和 'admin' 同时注册 author_name VARCHAR(64) NOT NULL COLLATE utf8mb4_0900_as_cs, INDEX idx_author (author_name) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_as_cs;

验证是否生效：

SHOW CREATE TABLE comment; -- 看 charset 和 collation 是否一致 SELECT _utf8mb4 'A' = _utf8mb4 'a' COLLATE utf8mb4_0900_as_cs; -- 返回 0（false）

4. 查询与索引：为什么EXPLAIN看起来走了索引，但接口还是慢？

EXPLAIN是起点，不是终点。它告诉你「MySQL 计划怎么执行」，但不告诉你「实际执行时发生了什么」。一个type=ref的查询，可能因Using filesort或Using temporary在内存不足时落盘，耗时从 10ms 暴涨到 2s。

4.1 覆盖索引（Covering Index）：让查询不回表，是性能跃迁的关键

InnoDB 主键即聚簇索引，数据行按主键顺序物理存储。当查询字段不在索引中时，MySQL 必须先通过二级索引找到主键，再回聚簇索引取完整行 —— 这叫「回表」，I/O 成倍增加。

覆盖索引 = 查询所需所有字段都在索引中。例如：

-- 表结构 CREATE TABLE product ( id BIGINT PRIMARY KEY, category_id INT NOT NULL, price DECIMAL(10,2) NOT NULL, title VARCHAR(255) NOT NULL, created_at DATETIME NOT NULL ); -- 普通索引（不够） INDEX idx_category (category_id); -- 覆盖索引（够了） INDEX idx_category_covering (category_id, price, title, created_at);

执行SELECT price, title, created_at FROM product WHERE category_id = 100时：

• 用idx_category：先查索引得到主键列表，再回表取price/title/created_at→ 2 次 I/O
• 用idx_category_covering：索引页里直接包含所有字段 → 1 次 I/O，且无需排序（ORDER BY也命中）

验证是否覆盖：EXPLAIN结果中Extra列出现Using index，而非Using where; Using index（后者表示用了索引但还需回表过滤）。

4.2 最左前缀法则：为什么WHERE a = ? AND b > ? AND c = ?只能用上(a,b)，用不上c？

B+ 树索引是有序结构，查询条件必须满足「连续最左匹配」才能利用索引。对于联合索引(a,b,c)：

• WHERE a = 1 AND b = 2 AND c = 3→ 全部命中
• WHERE a = 1 AND b > 2 AND c = 3→ 只用(a,b)，c条件在b > 2的结果集里线性扫描
• WHERE b = 2 AND c = 3→完全不用索引，因为没a，无法定位树分支

实战口诀：

• 等值查询（=）放最左，越多越好
• 范围查询（>,<,BETWEEN）放中间，只能有一个
• 排序字段（ORDER BY）放最后，且方向必须一致（ASC/DESC不能混）

举例：高频查询SELECT * FROM order WHERE status = 'paid' AND created_at > '2024-01-01' ORDER BY amount DESC
正确索引：INDEX idx_status_created_amount (status, created_at, amount)
错误索引：INDEX idx_created_status (created_at, status)→created_at > ?后无法用status = ?二分查找

4.3 索引下推（ICP）：MySQL 5.6+ 的隐藏加速器

ICP 允许 MySQL 在存储引擎层（InnoDB）就过滤WHERE条件，而非把所有索引行返回 Server 层再过滤。例如：

-- 索引 (last_name, first_name) SELECT * FROM user WHERE last_name = 'Zhang' AND first_name LIKE 'San%';

• MySQL 5.5：InnoDB 返回所有last_name = 'Zhang'的主键，Server 层再用first_name LIKE 'San%'过滤
• MySQL 5.6+：InnoDB 直接在索引页里匹配first_name LIKE 'San%'，只返回符合条件的主键 → 减少 80%+ 的主键传输量

开启条件：

• MySQL ≥ 5.6，且optimizer_switch中index_condition_pushdown=on（默认开启）
• 查询条件中，索引字段的过滤必须是「可下推」操作（=,IN,BETWEEN,LIKE 'prefix%'）

验证是否启用：EXPLAIN FORMAT=JSON查看"using_index_condition": true

4.4 避坑：常见索引失效场景与修复

现象 1：WHERE name LIKE '%abc'用不上索引

原因：前导%使 B+ 树无法从左到右匹配，只能全表扫描
解决：

• 改用全文索引（FULLTEXT）+MATCH AGAINST
• 或用倒排索引（Elasticsearch）处理模糊搜索
• 若必须前缀模糊，考虑生成「反向字符串」索引：

  ALTER TABLE user ADD COLUMN name_reversed VARCHAR(255) AS (REVERSE(name)); CREATE INDEX idx_name_rev ON user (name_reversed); -- 查询时：WHERE name_reversed LIKE REVERSE('%abc')

现象 2：WHERE status + 0 = 1导致索引失效

原因：对索引字段做函数运算，MySQL 无法用索引值直接比较
解决：

• ❌WHERE status + 0 = 1
• ✅WHERE status = 1（保持字段裸露）
• ✅WHERE CAST(status AS CHAR) = '1'（同理，避免运算）

现象 3：WHERE create_time > NOW() - INTERVAL 7 DAY在大表上慢

原因：NOW()是动态函数，MySQL 无法预估结果集大小，常选错执行计划
解决：

• 应用层计算好时间点再传参：WHERE create_time > '2024-05-13 00:00:00'
• 或用DATE_SUB(NOW(), INTERVAL 7 DAY)，但需确保create_time有索引

现象 4：ORDER BY和LIMIT组合在深分页时巨慢

原因：LIMIT 10000, 20要先扫 10020 行，再丢弃前 10000 行
解决：

• ✅游标分页（推荐）：WHERE id > last_seen_id ORDER BY id LIMIT 20
• ✅延迟关联：先查主键，再 JOIN 取详情

  SELECT t1.* FROM product t1 INNER JOIN (SELECT id FROM product WHERE status = 1 ORDER BY id LIMIT 10000, 20) t2 ON t1.id = t2.id;

5. 数据一致性：事务、锁与 MVCC 如何协同工作，又为何让你的 update 互相阻塞？

MySQL 的 ACID 不是魔法，是 InnoDB 用「锁 + MVCC + redo log + undo log」四层机制硬扛出来的。理解它们，才能写出不锁表、不脏读、不幻读的代码。

5.1 锁类型：行锁、间隙锁、临键锁，到底锁了哪几行？

InnoDB 的行锁不是锁「记录」，而是锁「索引记录之间的间隙」。例如表t(id PK, age INT)有数据(1,20), (5,30), (10,40)：

• SELECT ... WHERE id = 5 FOR UPDATE→ 锁住id=5这条记录（行锁）
• SELECT ... WHERE age = 30 FOR UPDATE→ 若age无索引，锁全表；若有索引，则锁age=30对应的id=5记录
• SELECT ... WHERE id BETWEEN 2 AND 8 FOR UPDATE→ 锁住(1,20)和(5,30)之间的间隙，以及(5,30)本身（临键锁 = 行锁 + 间隙锁）

关键结论：

• 无索引的WHERE条件 → 退化为表锁
• 唯一索引等值查询 → 只锁匹配行（行锁）
• 普通索引等值查询 → 锁匹配行 + 间隙（临键锁），防止幻读
• 范围查询 → 锁整个范围（间隙锁），可能阻塞其他事务插入

验证锁情况：SELECT * FROM performance_schema.data_locks;（MySQL 5.7+）

5.2 事务隔离级别：READ-COMMITTED不是银弹，REPEATABLE-READ也有代价

选型建议：

• ✅绝大多数 Web 应用 →REPEATABLE-READ
  因为它用间隙锁解决了幻读（INSERT并发冲突），且快照读性能好
• ⚠️高并发计数场景（如抢券）→READ-COMMITTED+SELECT ... FOR UPDATE
  避免间隙锁扩大锁定范围，但需手动加锁
• 🚫SERIALIZABLE→ 仅调试用，生产禁用，吞吐量暴跌 90%+

5.3 MVCC 快照读：为什么SELECT不加锁，却能看到「过去」的数据？

MVCC（多版本并发控制）是 InnoDB 实现非阻塞读的核心。每行数据有隐藏字段：

• DB_TRX_ID：最后修改该行的事务 ID
• DB_ROLL_PTR：指向 undo log 的指针，用于回溯旧版本

当事务 A 开始时，InnoDB 记录其read view（可见事务 ID 范围）。后续SELECT：

• 只读取DB_TRX_ID在read view中「已提交」且「小于当前事务 ID」的版本
• 若该行被事务 B 修改但未提交，则 A 看到的是 undo log 中的前一版本

这意味着：

• SELECT是快照读（不加锁），SELECT ... FOR UPDATE是当前读（加锁）
• 同一事务内多次SELECT看到的数据一致（REPEATABLE-READ语义）
• UPDATE/DELETE必须当前读，所以会触发锁等待

验证 MVCC：开启两个会话，会话 ABEGIN; SELECT * FROM t;，会话 BUPDATE t SET v=2 WHERE id=1;，会话 A 再SELECT仍见旧值，直到COMMIT。

5.4 死锁排查：LATEST DETECTED DEADLOCK日志里藏着救命线索

死锁不是错误，是 InnoDB 主动牺牲一个事务的正常策略。关键是要读懂SHOW ENGINE INNODB STATUS\G中的LATEST DETECTED DEADLOCK段：

*** (1) TRANSACTION: TRANSACTION 123456, ACTIVE 10 sec mysql tables in use 1, locked 1 LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s) MySQL thread id 10, OS thread handle 123456789, query id 1000 localhost root updating UPDATE account SET balance = balance - 100 WHERE id = 1 *** (2) TRANSACTION: TRANSACTION 123457, ACTIVE 8 sec mysql tables in use 1, locked 1 2 lock struct(s), heap size 1136, 1 row lock(s) MySQL thread id 11, OS thread handle 987654321, query id 1001 localhost root updating UPDATE account SET balance = balance + 100 WHERE id = 2 *** WE ROLL BACK TRANSACTION (2)

解读步骤：

1. 看(1)和(2)的query id，对应具体 SQL
2. 看LOCK WAIT行，哪个事务在等锁（(1)在等）
3. 看WE ROLL BACK行，谁被牺牲（(2)）
4. 结合 SQL 分析：事务 1 想锁id=1，事务 2 想锁id=2，但事务 1 已持id=2锁，事务 2 已持id=1锁 → 循环等待

根治方法：

• ✅固定 DML 顺序：所有事务按id ASC更新，避免交叉
• ✅减少事务粒度：把「扣款 + 记流水 + 发消息」拆成小事务，或用最终一致性
• ✅捕获死锁异常重试（Java）：

  try { executeUpdate(...); } catch (SQLException e) { if ("40001".equals(e.getSQLState())) { // Deadlock found Thread.sleep(10); // 指数退避 retry(); } }

6. 生产就绪 checklist：从本地开发到 K8s 部署，MySQL 应用必须过的 12 道关

写完功能只是开始。一个真正可交付的 MySQL 应用，必须在以下 12 个维度全部达标。我每次上线前都会逐项核对，漏一项，就可能在凌晨三点收到告警。

6.1 连接池：HikariCP 的 5 个必调参数

连接池不是「开箱即用」，而是应用性能的命脉。HikariCP 默认配置面向通用场景，生产必须调优：

Spring Boot 配置示例：

spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 10 connection-timeout: 30000 validation-timeout: 3000 leak-detection-threshold: 60000 connection-test-query: "SELECT 1"

6.2 SQL 审计：用slow_query_log+pt-query-digest定位坏查询

慢查询日志不是「开了就行」，必须配合分析工具：

# 开启慢查询（MySQL 5.6+） SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 0.1; -- 记录 >100ms 的查询 SET GLOBAL log_output = 'TABLE'; -- 写入 mysql.slow_log 表，方便程序查 # 用 Percona Toolkit 分 <p> <a href="https://download.csdn.net/download/jiebing2020/30277143" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>