sky999
天山茗客
UID 181291
Digest
2
Points 10
Posts 3918
码币MB 2575 Code
黄金 0 Catty
钻石 884 Pellet
Permissions 10
Register 2020-11-28
Status offline
|
各位领导/客户同事好， 针对 DFS 系统近期“运行缓慢”的情况，我们已在 chang1000（Wi
各位领导/客户同事好，
针对 DFS 系统近期“运行缓慢”的情况，我们已在 chang1000（Windows Server 2008，phpStudy 环境）对性能瓶颈进行了定位，并完成了第一阶段的针对性优化。现将排查结论、已实施整改及后续建议汇报如下：
一、问题现象
DFS 业务量不大，但页面访问与后台操作出现明显卡顿；
服务器配置较高（16G 内存、24 线程 Xeon），但仍表现为整体响应慢。
二、排查方法与结论（瓶颈定位）
1. 系统资源快照采样（卡顿时抓取）
CPU 总体并未长期打满，内存可用量充足；
进一步对进程级别（CPU/IO）采样后发现：MySQL（mysqld）占用 CPU 并持续大量读盘，其他进程占用很低。
结论：主要瓶颈在数据库层（MySQL 的 SQL 扫描/更新效率、锁等待）。
2. MySQL SQL 画像分析（performance_schema / processlist）
统计显示多条 UPDATE/SELECT 语句累计耗时居高，且存在“rows_examined 极大”的特征，说明有大量全表扫描/回表过滤；
同时在 processlist 中观察到“waiting for update …”类等待，提示更新存在排队与锁竞争。
结论：慢点集中在少数核心表：缺少有效联合索引 + MyISAM 表锁导致更新排队。
三、已完成的整改动作（第一阶段）
1）表：material_gongyi_gongjia_tongbu_test
原状：仅主键 `id`，业务查询/更新却以 `materialID`、`FOPERATIONID` 等字段定位，导致全表扫描；引擎为 MyISAM（表锁）。
已执行：
新增联合索引：`idx_mid_fop (materialID, FOPERATIONID)`（使用前缀索引适配 varchar 字段）
引擎从 MyISAM → InnoDB（由表锁变为行级锁）
2）表：kucunsumtable
原状：仅有单列索引 `MAT_FNUMBER`、`GZH_FTRACKNO`，但高频 UPDATE 需要按多字段定位；引擎为 MyISAM（表锁）。
已执行：
新增联合索引：`idx_mat_gzh (MAT_FNUMBER, GZH_FTRACKNO)`（前缀索引）
引擎从 MyISAM → InnoDB
> 以上两张表均已完成：“补联合索引 + 引擎升级 InnoDB” 的核心整改，可显著降低全表扫描与更新排队（waiting for update）风险。
四、阶段性效果预期
关键慢 SQL 会从“扫描大量行”转为“索引命中少量行”，MySQL 读盘与 CPU 占用应明显下降；
MyISAM 表锁造成的并发更新排队将大幅减少，系统在高峰期更稳定。
> 我们将继续基于 MySQL 的语句统计榜单（TOP 慢 SQL）逐条定位下一批高耗时表/语句，并按相同方法补齐索引与引擎优化。
五、后续整改建议（第二阶段与中长期）
A. 数据库层（短期见效，持续优化）
1. 继续对 TOP 慢 SQL 涉及的表逐个检查：
是否缺少与 WHERE 条件一致的联合索引；
是否存在更新条件不唯一导致多行更新；
是否存在长事务/大批量更新导致锁等待；
并逐表优化（索引/SQL改写/拆批处理）。
2. 建议开启/完善慢查询治理机制：
开启 slow log（按阈值记录慢 SQL）；
定期用 digest 汇总筛查耗时最高的语句，形成“周度 SQL 优化清单”。
B. 架构与硬件建议（建议客户投入）
当前 chang1000 为 Windows 2008 + phpStudy 的一体机运行模式，数据库与业务同机，磁盘 I/O 与系统环境对 MySQL 性能影响较大。建议如下（二选一或组合）：
方案 1：新增独立数据库服务器（推荐）
新增一台专用数据库服务器，部署 SUSE Linux 作为数据库运行平台；
MySQL 独立承载，业务 Web 仍可留在现有服务器；
优势：Linux 对数据库 I/O、进程调度、长期稳定性更友好；数据库独占资源后性能上限与稳定性显著提升；后期扩容更清晰。
方案 2：对 chang1000 做硬件升级（快速落地）
增加/更换为 SSD（强烈建议 NVMe 或企业级 SSD），将 MySQL 数据目录与日志优先落在 SSD；
视数据规模与缓存情况 增加内存（使 InnoDB buffer pool 能更大比例缓存热点数据，减少磁盘读）；
优势：实施快、改动小；SSD 对目前“读盘型慢”问题改善最明显。
六、下一步计划
继续针对 TOP 慢 SQL 关联表（如 production_ftrackno、outsourcing_supplier 等）进行索引与引擎检查，形成第二批优化清单；
优化完成后复测：采样 mysqld CPU/IO、页面响应时间、并发更新等待情况，并输出对比数据。
如需我们协助评估“新增数据库服务器规格（CPU/内存/SSD/RAID/备份方案）”或“现有 chang1000 的最佳升级组合”，我们可在收到客户预算与数据规模信息后给出建议配置。
谢谢。
|
|
