数据库教程FGMT070-数据库工程师项目专业能力提升（数据库从业必备）

数据库教程FGMT070-数据库工程师项目专业能力提升（数据库从业必备）

一、前言与内容大纲介绍

风哥针对本文前言说明：很多从业者把"会写 SQL、能装数据库"当作全部技能，但真正让一个数据库工程师从"会做"走向"做得好、说得清、交付得稳"的，是那一整套围绕数据库的日常运维与项目交付的方法论。会建库不代表会巡检，会巡检不代表会写巡检报告，会写报告不代表能在项目里按阶段把文档产出出来。这套能力是数据库从业者向上发展的分水岭。

风哥本文围绕四个方面展开：第一，数据库工程师日常工作简述，讲清一天、一周、一个月到底在做什么；第二，数据库健康巡检类，覆盖巡检前/中/后工作、每日检查报告、月度巡检报告、年度服务总结报告的编写方法与命令实操；第三，数据库运维故障与需求支持类，讲接到任务后第一步做什么、故障处理报告如何写、技术服务类报告如何写、任务完成后如何向上汇报；第四，数据库交付实施项目类，覆盖项目流程、新项目如何入手、立项启动、需求调研、规划设计实施、测试验收各阶段的阶段工作与文档编写。

风哥本文整体遵循"理论支撑 + 实战命令"的思路，所有配置按 64G 内存 / 8 CPU 规格设计，主机名为 fgedu-net-cn1 与 fgedu-net-cn2，数据路径统一为 /fgedudb，数据库实例与账号统一使用 fgedudb / fgedu。文中以 Oracle、MySQL 为主线，并可平滑延伸到 PostgreSQL、SQL Server 及达梦、人大金仓、openGauss 等国产数据库。

二、数据库工程师日常工作简述（理论部分）

数据库工程师的工作可归纳为四大块：日常维护、巡检保障、故障响应、项目交付。四者不是割裂的，而是围绕"数据库可用性、性能、安全、容量"四条主线不断循环。

日常维护（Day to Day）：这是每天的基础工作。包括查看告警邮件与监控平台、确认备份是否成功、检查归档日志与告警日志、处理容量告警、响应开发与业务侧的技术支持请求。这一块占据约 40% 的工作时间，也是最容易被低估的部分——它的价值在于"把风险消灭在爆发之前"。

巡检保障（Inspection）：按频率分为每日检查、月度巡检、季度巡检、年度总结。每日检查是"快照式"的，关注核心指标是否越过阈值；月度巡检是"系统式"的，要覆盖实例、存储、网络、备份、安全等全维度并输出正式报告；年度总结则站在"服务回顾"角度，统计可用性、故障次数、处理时长、容量变化趋势，并给出下一周期的规划建议。

故障响应（Incident）：故障是检验工程师真实水平的试金石。一个故障从接报到解决，考验的是定位顺序是否合理、手段是否可控、沟通是否及时、复盘是否到位。故障处理的产出不只是"恢复了"，还包括一份可追溯、可复用的故障处理报告。

项目交付（Delivery）：数据库交付项目是"重活"，周期长、阶段多、干系人多。新库建设、升级迁移、架构改造都属于这一类。项目交付最核心的能力不是装库本身，而是按阶段推进并沉淀文档：立项、需求、调研、方案设计、实施、测试、验收，每个阶段都有对应的标准文档。

从理论角度，这四大块背后有三个方法论支撑：第一是"标准作业程序（SOP）"思想——把重复性工作固化成可执行的步骤和检查清单，降低对人的依赖；第二是"文档即交付物"思想——在运维与项目场景里，过程文档与最终系统同等重要，它决定了工作是否可审计、可交接；第三是"分级响应"思想——按影响程度把任务分优先级，把有限资源投入到最关键的问题上。

下面把理论落到命令与文档层面，逐块实战展开。

三、数据库健康巡检类（实战为主）

3.1 巡检前 / 巡检中 / 巡检后的工作

风哥针对巡检流程实战说明：巡检不是"连上去跑几条 SQL 就结束"，而是一个有前、中、后三个环节的完整流程。

巡检前（准备阶段），要做四件事：

1. 明确巡检对象清单，主机 fgedu-net-cn1、fgedu-net-cn2 上的实例 fgedudb；
2. 准备巡检账号（只读账号，最小权限）；
3. 制定巡检时间窗口，避开业务高峰；
4. 准备巡检脚本模板与上次巡检基线数据，便于对比。

巡检中（执行阶段），按"操作系统 → 实例 → 存储 → 备份 → 安全"的顺序执行，逐项记录原始输出。

巡检后（产出阶段），整理数据、对比基线、标记异常、给出结论与建议，输出正式巡检报告。

下面以每日检查为例，给出完整的命令实操。

3.2 数据库健康检查——每天检查（如何编写每天的报告）

每日检查的目标是"用最短时间确认数据库是否健康"。风哥推荐的方式是一套固定脚本 + 固定输出模板，把每天 30 分钟的巡检压缩到 10 分钟以内。

先看操作系统层，登录 fgedu-net-cn1 后检查 CPU、内存、负载与磁盘：

# 查看负载与CPU
uptime
top -bn1 | head -20
# 查看内存（64G规格，重点看available与buff/cache）
free -h
# 查看根分区及数据盘使用率（数据路径 /fgedudb）
df -h / /fgedudb
# 查看IO负载与等待
iostat -x 1 3

再进入 Oracle 实例检查（以实例 fgedudb 为例），设置环境后使用 sqlplus 只读查询：

su - oracle
export ORACLE_SID=fgedudb
sqlplus / as sysdba

在 SQL*Plus 中执行每日核心检查脚本：

-- 1) 实例状态与启动时间
SELECT instance_name, status, database_status,
       TO_CHAR(startup_time,'YYYY-MM-DD HH24:MI') startup_time
FROM v$instance;

-- 2) 数据库整体状态（open 状态为正常）
SELECT name, open_mode, log_mode, created
FROM v$database;

-- 3) 表空间使用率（重点看超过85%的表空间）
SELECT a.tablespace_name,
       ROUND(a.total_mb,2) total_mb,
       ROUND(a.total_mb - nvl(b.free_mb,0),2) used_mb,
       ROUND(nvl(b.free_mb,0),2) free_mb,
       ROUND((a.total_mb - nvl(b.free_mb,0))/a.total_mb*100,2) used_pct
FROM (SELECT tablespace_name, SUM(bytes)/1024/1024 total_mb
      FROM dba_data_files GROUP BY tablespace_name) a,
     (SELECT tablespace_name, SUM(bytes)/1024/1024 free_mb
      FROM dba_free_space GROUP BY tablespace_name) b
WHERE a.tablespace_name = b.tablespace_name
  AND (a.total_mb - nvl(b.free_mb,0))/a.total_mb*100 >= 85
ORDER BY 5 DESC;

-- 4) 连接数情况（比较当前会话与上限）
SELECT COUNT(*) sessions_now FROM v$session;
SHOW PARAMETER sessions;
SHOW PARAMETER processes;

-- 5) 最近出现的严重错误（检查 alert 日志关键错误）
SELECT TO_CHAR(originating_timestamp,'YYYY-MM-DD HH24:MI') ts,
       message_text
FROM v$diag_alert_ext
WHERE originating_timestamp > SYSDATE - 1
  AND (message_text LIKE '%ORA-00600%'
       OR message_text LIKE '%ORA-07445%'
       OR message_text LIKE '%ORA-01555%'
       OR message_text LIKE '%ORA-0165%');

MySQL 侧，在 fgedu-net-cn2 上通过 mysql 客户端执行每日检查：

mysql -uroot -p -h127.0.0.1

-- 1) 版本与运行时长
SELECT VERSION(), NOW();
SHOW GLOBAL STATUS LIKE 'Uptime';
-- 2) 连接数使用率
SHOW VARIABLES LIKE 'max_connections';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
-- 3) 慢查询（当日慢SQL条数）
SHOW GLOBAL STATUS LIKE 'Slow_queries';
-- 4) 主从复制状态（若为复制架构）
SHOW SLAVE STATUS\G
-- 5) 关键表空间/库大小
SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024,2) size_mb
FROM information_schema.tables
GROUP BY table_schema ORDER BY size_mb DESC;

每日检查报告的编写，风哥建议固定一个精简模板，包含五段：检查时间与对象、系统资源状态、实例与数据库状态、异常项清单（含严重级别）、结论与建议。日报要求"快、准、可追踪"，不需要大段文字，一张表格加结论即可，重点是把异常项和处置状态写清楚，便于月度汇总时直接引用。

3.3 数据库健康检查——月度巡检（如何编写月度巡检报告）

月度巡检比每日检查更系统，风哥把它定位为"对数据库做一次全面体检"。巡检范围包括：系统资源趋势、实例参数合理性、表空间与容量增长、备份恢复有效性、归档与日志、对象碎片与统计信息、安全性（账号权限、密码策略）、以及过去一个月的变更与故障回顾。

先做容量增长趋势分析，这依赖 dba_hist 或手动保留的每月快照。风哥给出一个基于数据字典的容量脚本（Oracle）：

-- 月度容量快照：记录到历史表 tb_capacity_his
INSERT INTO tb_capacity_his(snap_time, tablespace_name, total_mb, used_pct)
SELECT SYSDATE, a.tablespace_name,
       SUM(a.bytes)/1024/1024,
       ROUND((SUM(a.bytes)-nvl(b.free_mb,0))/SUM(a.bytes)*100,2)
FROM dba_data_files a,
     (SELECT tablespace_name, SUM(bytes)/1024/1024 free_mb
      FROM dba_free_space GROUP BY tablespace_name) b
WHERE a.tablespace_name = b.tablespace_name
GROUP BY a.tablespace_name;
COMMIT;

-- 对比本月与上月使用率，预测剩余可用天数
SELECT tablespace_name,
       MAX(CASE WHEN TRUNC(snap_time,'MM')=TRUNC(SYSDATE,'MM') THEN used_pct END) cur_pct,
       MAX(CASE WHEN TRUNC(snap_time,'MM')=ADD_MONTHS(TRUNC(SYSDATE,'MM'),-1) THEN used_pct END) last_pct
FROM tb_capacity_his
GROUP BY tablespace_name;

MySQL 月度巡检的核心命令：

mysql -uroot -p -e "
  SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';
  SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages%';
  SHOW ENGINE INNODB STATUS\G
"
# 检查binlog占用
du -sh /fgedudb/mysql3306/logs/binlog
# 检查备份文件完整性
ls -lh /fgedudb/backup/mysql3306/

月度巡检报告模板，风哥建议按以下章节组织：

1. 巡检范围与周期说明；
2. 系统资源与容量（含趋势对比表）；
3. 数据库运行状态（实例、参数、会话、锁）；
4. 备份与恢复有效性验证结果；
5. 安全与权限检查结果；
6. 过去一个月事件回顾（故障、变更、需求）；
7. 风险项与整改建议清单。

报告末尾一定要有"风险分级 + 建议动作 + 责任人 + 计划完成时间"，否则报告只是一份数据堆砌，没有决策价值。

3.4 数据库服务年度总结（如何编写年度总结报告）

年度总结是面向管理层和客户的服务回顾，风哥强调它的定位是"价值证明 + 下一年规划"。年度总结要回答三个问题：过去一年数据库服务做得怎么样、有哪些问题、明年怎么做得更好。

年度总结的核心数据来源是月报、故障记录、变更记录和容量快照。关键指标包括：

• 可用性：可用性 = (总分钟数 - 不可用分钟数) / 总分钟数 × 100%，目标通常 99.9% 以上；
• 故障统计：故障次数、按严重级别分布、平均恢复时长（MTTR）、平均无故障时长（MTBF）；
• 需求与变更：处理的需求数量、成功率、回退次数；
• 容量变化：各表空间年度增长量、预测剩余周期。

可用性计算可用脚本从记录表聚合：

-- 从故障记录表聚合年度可用性
SELECT TO_CHAR(fault_time,'YYYY') yr,
       8760 - SUM(down_minutes)/60 AS total_up_hours,
       ROUND((8760 - SUM(down_minutes)/60)/8760*100,3) AS availability_pct
FROM db_fault_log
WHERE TO_CHAR(fault_time,'YYYY') = '2026'
GROUP BY TO_CHAR(fault_time,'YYYY');

年度总结报告的结构：

1. 服务范围与运行环境（fgedu-net-cn1 / fgedu-net-cn2，实例 fgedudb，64G/8CPU 规格说明）；
2. 年度运行指标总览（可用性、故障、需求、容量）；
3. 重点事件回顾（重大故障、重点项目、重要变更）；
4. 存在的问题与改进；
5. 下一年度运维与建设规划。

四、数据库运维故障与需求支持类（实战为主）

4.1 接到任务后第一时间应该做什么？

这是很多新手容易出错的地方。风哥针对此实战说明：接到故障任务后的前 5 分钟，决定整个故障处理的成败。第一时间应该做的是"先控风险、再探根因"，而不是急着动手改。

推荐的第一时间动作清单（按顺序）：

1. 记录接报信息：故障现象、发生时间、影响范围、业务方联系方式、是否已影响生产；
2. 判断影响级别：是否核心业务、是否已宕机、是否有数据丢失风险，据此决定是否启动应急流程；
3. 保护现场：在定位前，先抓取现场信息——告警日志尾部、当前会话、锁与等待事件、最近变更记录；
4. 隔离影响：必要时先限制影响面（如拒绝新连接、停止相关作业），但必须评估操作风险；
5. 再定位根因：带着现场信息去分析，而不是盲目重启。

下面以一次 Oracle 实例会话爆满故障为例，展示从接报到定位的过程。

接报现象：业务报"连接不上数据库"。第一时间登录 fgedu-net-cn1 抓现场：

su - oracle
sqlplus / as sysdba

-- 1) 查看当前会话数是否打满
SELECT COUNT(*) total_sess FROM v$session;
SHOW PARAMETER processes;
SHOW PARAMETER sessions;
-- 2) 查看是哪些会话在占资源
SELECT s.sid, s.serial#, s.username, s.status,
       s.sql_id, s.event, s.blocking_session
FROM v$session s
WHERE s.type = 'USER'
ORDER BY s.sid;
-- 3) 查看是否有会话被阻塞（blocking_session 非空即为被阻塞）
SELECT COUNT(*) blocked_cnt
FROM v$session
WHERE blocking_session IS NOT NULL AND type='USER';
-- 4) 查看锁等待
SELECT object_name, s.sid, s.event
FROM v$locked_object l, dba_objects o, v$session s
WHERE l.object_id = o.object_id AND l.session_id = s.sid;

4.2 数据库故障处理类（如何编写故障处理报告）

故障处理完成后，风哥强烈建议当天输出故障处理报告。一份合格的故障处理报告，要求做到"过程可还原、根因可服众、后续可预防"。

故障处理报告的标准结构：

1. 故障概述（现象、时间、影响范围、级别）；
2. 处理过程时间线（接报→定位→处置→验证，精确到分钟）；
3. 根因分析（直接原因 + 深层原因）；
4. 处置措施（做了什么、为什么这么做、有无替代方案）；
5. 验证结果（如何确认已恢复、业务是否验证通过）；
6. 后续整改（监控补强、参数调整、SOP 完善、责任归属）；
7. 经验教训总结。

继续上面的会话爆满案例，定位后发现根因是应用侧连接池配置不合理导致大量空闲会话占用，且 processes 参数偏低。处置措施包括：临时扩大 processes 参数、排查异常会话、推动应用侧修复。

-- 调整 processes 参数（64G内存，8CPU，参考值，需评估后修改）
ALTER SYSTEM SET processes = 600 SCOPE = SPFILE;
-- 查询当前等待事件分布，确认瓶颈
SELECT event, COUNT(*) cnt
FROM v$session
WHERE type='USER'
GROUP BY event ORDER BY cnt DESC;

对 MySQL 故障，以"连接数满 + 慢查询堆积"为例，抓取现场：

mysql -uroot -p -e "
  SHOW PROCESSLIST;
  SHOW GLOBAL STATUS LIKE 'Threads_connected';
  SHOW GLOBAL STATUS LIKE 'Max_used_connections';
"
# 查看慢查询日志尾部
tail -200 /fgedudb/mysql3306/logs/slow.log

处置时先分析慢 SQL（用 explain 看执行计划），确认是否需要加索引或改写 SQL，而不是简单重启实例：

EXPLAIN SELECT /*+ 慢SQL */ * FROM t_order WHERE order_no = 'xxx'\G
-- 补索引（确认影响后执行）
ALTER TABLE t_order ADD INDEX idx_order_no(order_no);

4.3 数据库技术支持与需求类（如何编写技术服务类报告）

技术支持类任务（数据抽取、报表统计、权限调整、参数变更、数据订正等）虽然不像故障那么紧急，但同样需要文档沉淀。风哥针对此类任务的要求是**“先约定、后执行、再留痕”**。

技术服务类报告的结构：

1. 需求描述（业务方原始诉求，尽量原话引用）；
2. 需求分析与确认（理解是否正确、口径是否对齐）；
3. 技术方案（涉及哪些库、哪些对象、如何实现）；
4. 实施步骤与脚本（含回退方案）；
5. 实施结果验证；
6. 遗留问题与后续建议。

以"数据订正"类需求为例，核心原则是变更前必须备份、必须留原始记录、必须有回退方案：

-- 订正前：先把受影响数据备份到审计表
CREATE TABLE t_emp_bak_20261022 AS SELECT * FROM t_emp WHERE dept_id = 10;
-- 记录订正日志
INSERT INTO db_change_log(change_time, obj_name, sql_text, oper_user)
VALUES (SYSDATE, 't_emp', 'UPDATE t_emp SET salary=salary*1.1 WHERE dept_id=10', 'fgedu');
COMMIT;
-- 执行订正
UPDATE t_emp SET salary = salary * 1.1 WHERE dept_id = 10;
COMMIT;
-- 验证
SELECT COUNT(*) FROM t_emp_bak_20261022;
SELECT COUNT(*) FROM t_emp WHERE dept_id = 10;

4.4 任务完成后如何汇报工作（升职加薪必备）

风哥把"汇报"列为升职加薪必备技能，因为它决定你的工作成果能否被看见。汇报的核心是结果导向 + 数据说话 + 结构清晰。

汇报的三个原则：

1. 结论先行：先说"任务已完成/未完成，结果是X"，再讲过程；
2. 数据支撑：用可量化指标代替"很稳定""没问题"这类模糊表述；
3. 问题与价值并重：不仅说"做了什么"，更要说"带来了什么价值、规避了什么风险"。

一次周报/项目汇报的黄金结构：

• 本周/本期核心成果（2-3 条，量化）；
• 关键问题与处理情况；
• 风险预警与需要的支持；
• 下周/下期计划。

例如汇报巡检成果，应写"本周完成 fgedu-net-cn1/fgedu-net-cn2 两节点每日巡检 7 次、月度巡检 1 次，发现并处置表空间超 85% 告警 2 项、慢查询 5 条，已全部整改闭环，未发生影响业务的故障"，而不是"这周都在忙巡检，数据库挺正常的"。

五、数据库交付实施项目类（实战为主）

5.1 项目流程及新项目如何入手

数据库交付项目一般分五个阶段：立项与启动 → 需求与调研 → 规划与设计 → 实施与上线 → 测试与验收。每个阶段都有明确的阶段工作和文档产出，形成一个完整闭环。

新项目入手，风哥建议先做三件事：

1. 摸清项目背景：业务目标、上线时间、数据量、并发量、可用性要求；
2. 识别干系人：谁是决策者、谁是业务负责人、谁是技术对接人；
3. 明确边界：本项目范围是什么、哪些不做（很重要，防止范围蔓延）。

项目文档是交付项目区别于日常运维的核心特征。下面按阶段展开各阶段的工作与文档编写要点。

5.2 项目立项与启动（阶段工作及如何文档编写）

立项与启动阶段的目标是"把项目正式立起来，明确目标、范围、计划与责任"。阶段工作包括：编制项目立项说明、明确项目目标与验收标准、组建项目团队、制定总体计划、召开启动会。

立项文档（项目章程）核心内容：

• 项目背景与目标；
• 项目范围（含不包含项）；
• 里程碑计划与时间表；
• 资源与角色分工；
• 风险与假设；
• 验收标准。

以"某业务系统数据库建设"为例，立项阶段要明确：新库部署在 fgedu-net-cn1/fgedu-net-cn2，规格 64G 内存 8 CPU，数据路径 /fgedudb，实例名 fgedudb，账号 fgedu，主用 Oracle 或 MySQL，并写明预计数据量和可用性要求。这些内容一旦写进立项文档，就是后续所有阶段的依据。

5.3 项目需求与调研（阶段工作及如何文档编写）

需求与调研阶段的目标是"把业务需求翻译成技术需求"。阶段工作包括：调研现状、收集业务需求、分析数据模型与访问模式、确定技术选型、输出需求文档与调研报告。

调研报告的核心内容：

• 现状调研（现有系统、数据量、迁移来源）；
• 业务需求（功能需求、性能需求、容量需求、可用性需求）；
• 技术约束（操作系统、硬件、安全合规要求）；
• 关键问题与待确认事项。

需求文档（需求规格说明书）核心内容：

• 数据库架构需求（单机/主备/集群/RAC）；
• 容量需求（数据量、增长速度，据此估算表空间）；
• 性能需求（并发数、响应时间、TPS）；
• 高可用与备份需求（RPO/RTO）；
• 安全需求（权限、加密、审计）。

这一阶段要产出关键数字，例如根据业务给出的"日增数据 50GB、峰值并发 800"估算表空间与 IO 需求，这些数字直接决定后面规划阶段的架构设计。

5.4 项目规划与实施（阶段工作及如何文档编写）

规划与实施阶段是项目核心，目标是把需求落地为可运行的数据库系统。阶段工作包括：架构设计、参数规划、安装部署、初始化与配置、数据导入、功能验证。

实施方案（规划设计文档）核心内容：

• 总体架构图（含主机、网络、存储）；
• 数据库设计（表空间/库设计、实例参数规划）；
• 部署步骤（分步命令）；
• 高可用与备份方案；
• 监控方案；
• 上线方案与回退方案。

以 Oracle 实例参数规划为例，针对 64G 内存 8 CPU 规格给出参考值（实际需结合 workload 评估，以下为常见基线）：

-- 内存相关参数（64G规格参考，SGA+PGA 约占总内存 50%-70%）
ALTER SYSTEM SET sga_target = 24G SCOPE=SPFILE;
ALTER SYSTEM SET pga_aggregate_target = 8G SCOPE=SPFILE;
-- 进程与会话
ALTER SYSTEM SET processes = 800 SCOPE=SPFILE;
ALTER SYSTEM SET sessions = 1200 SCOPE=SPFILE;
-- 归档模式
ALTER SYSTEM SET db_recovery_file_dest_size = 100G SCOPE=SPFILE;
ALTER SYSTEM SET log_archive_dest_1 = 'LOCATION=/fgedudb/arch' SCOPE=SPFILE;
-- 并行度（8CPU参考）
ALTER SYSTEM SET parallel_max_servers = 32 SCOPE=SPFILE;
ALTER SYSTEM SET parallel_degree_limit = 8 SCOPE=SPFILE;

实施阶段的安装部署命令（Oracle 11g/19c 安装完成后初始化）：

# 创建数据目录
mkdir -p /fgedudb/oradata /fgedudb/arch /fgedudb/backup
chown -R oracle:oinstall /fgedudb

# 设置环境变量（fgedu 用户）
cat >> ~/.bash_profile <<'EOF'
export ORACLE_BASE=/fgedudb/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/19c/dbhome_1
export ORACLE_SID=fgedudb
export PATH=$ORACLE_HOME/bin:$PATH
EOF
source ~/.bash_profile

# 启动监听
lsnrctl start

# 以 nomount 启动并创建数据库（使用 DBCA 或手工建库脚本）
sqlplus / as sysdba
startup nomount

MySQL 侧的初始化（8.0 为例，数据路径 /fgedudb/mysql3306）：

# 创建数据目录并初始化
mkdir -p /fgedudb/mysql3306/{data,logs,tmp}
chown -R mysql:mysql /fgedudb/mysql3306
mysqld --initialize-insecure --user=mysql \
  --basedir=/usr/local/mysql \
  --datadir=/fgedudb/mysql3306/data

# 编辑配置文件 /etc/my3306.cnf（64G内存8CPU参考）

[mysqld]
basedir=/usr/local/mysql
datadir=/fgedudb/mysql3306/data
port=3306
server-id=1
max_connections=2000
innodb_buffer_pool_size=24G
innodb_log_file_size=1G
innodb_flush_log_at_trx_commit=1
innodb_flush_method=O_DIRECT
slow_query_log=ON
slow_query_log_file=/fgedudb/mysql3306/logs/slow.log
long_query_time=2
binlog_format=ROW
log_bin=/fgedudb/mysql3306/logs/binlog
expire_logs_days=7
character-set-server=utf8mb4

启动并验证：

mysqld_safe --defaults-file=/etc/my3306.cnf &
# 验证
mysql -uroot -p -e "SELECT VERSION(); SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

实施阶段还要完成初始化业务库、创建应用账号、导入数据并做数据一致性校验。

5.5 项目测试与验收（阶段工作及如何文档编写）

测试与验收阶段的目标是"证明系统满足需求文档中定义的验收标准"。阶段工作包括：制定测试方案、执行功能/性能/高可用测试、修复问题、编制测试报告、组织验收。

测试报告核心内容：

• 测试范围与环境说明；
• 功能测试用例与结果（逐条对照需求）；
• 性能测试数据（并发、TPS、响应时间、资源使用）；
• 高可用测试结果（主备切换、故障演练）；
• 问题清单与处理状态；
• 测试结论（是否满足验收标准）。

性能测试是数据库交付验收的重点。风哥给出一组基于 sysbench 的 MySQL 压力测试命令，用于验证 64G/8CPU 规格下的性能基线：

# 准备测试数据（8张表，每表100万行）
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=127.0.0.1 --mysql-port=3306 \
  --mysql-user=fgedu --mysql-password=fgedu \
  --tables=8 --table-size=1000000 \
  prepare

# 执行读写混合压测（64线程）
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=127.0.0.1 --mysql-port=3306 \
  --mysql-user=fgedu --mysql-password=fgedu \
  --tables=8 --table-size=1000000 \
  --threads=64 --time=300 --report-interval=10 \
  run

验收环节最后要完成验收确认单：列出需求文档中的每一条验收标准，逐条标注"通过/不通过/豁免"，并由双方签字确认。只有验收文档闭环，项目才算正式交付，后续进入运维保障阶段。

六、风哥针对本文总结

风哥针对本文总结说明：数据库工程师的专业能力提升，核心不在于学会某一条命令，而在于建立**"运维 + 文档 + 项目"三位一体的工作体系**。日常维护提供稳定基础，健康巡检通过每日、月度、年度三级检查把风险前置拦截，故障与需求支持用标准化的接报-定位-处置-复盘流程把每一次问题变成能力资产，项目交付则用"立项-需求-规划-实施-测试-验收"五阶段加配套文档，保证交付质量可衡量、过程可追溯。

风哥给从业者的行动建议是：从今天开始，把每一次巡检、每一个故障、每一个需求、每一个项目阶段，都用标准模板沉淀成文档。坚持下去，你积累的不只是经验，更是一套可复用、可交接、可证明价值的方法论——这正是数据库工程师从"执行者"走向"负责人"、从技术岗走向技术管理岗的底层能力。本文所有命令均在 64G 内存 / 8 CPU 规格、fgedu-net-cn1/fgedu-net-cn2 主机、/fgedudb 路径、fgedudb/fgedu 实例账号下演示，可直接作为日常运维与项目交付的操作参考。