ResourceUtilization：选开发，测开就是测试，后续发展肯定是开发要好如果你喜欢测试那也不会有这个问题了

一笑而过2222：1. Linux查看CPU情况：使用 top 可实时查看系统CPU整体及各进程占用率，按 1 能展示每个核心运行状态； htop 以可视化界面增强交互性； mpstat -P ALL 精准统计每个CPU核心负载； lscpu 输出CPU架构、缓存等硬件信息； vmstat 综合展示CPU、内存、IO等资源使用趋势； sar -u 基于历史数据统计CPU负载； nproc 直接获取CPU核心数量。实际分析时，先用 top 快速定位异常，再结合 mpstat 等深入排查。 2. 电商退款测试用例：功能测试覆盖全额/部分退款、不同发货状态处理、退款金额计算及多渠道返还；异常测试包含重复退款、越权操作、网络中断恢复；业务规则聚焦退款时效控制、优惠券分摊逻辑、高频退款风控；同时补充兼容性（多终端适配）和性能测试（高并发场景响应），保障退款流程稳定可靠。 3. 死锁及其原因：死锁是多进程/线程因资源竞争形成互相等待、无法推进的阻塞状态，需同时满足互斥（资源独占）、请求保持（占有资源时请求其他资源）、不可剥夺（资源不能被强制释放）、循环等待（形成资源等待环路）四个条件。常见于数据库事务交叉锁定、多线程无序获取锁等场景，可通过资源预分配、顺序加锁预防，依赖日志或线程Dump分析检测。 4. 慢查询原因及定位：慢查询根源在于索引失效（未命中或设计不当）、数据量过大导致全表扫描、复杂查询（嵌套子查询、大量JOIN）、锁冲突（行锁升级表锁）、服务器资源瓶颈（CPU/IO过载）。定位时，先启用慢查询日志并用 pt-query-digest 分析高频慢SQL，再通过 EXPLAIN 剖析执行计划，结合 SHOW ENGINE INNODB STATUS 排查锁等待，必要时借助 Performance Schema 监控资源消耗。 5. 适合建索引的字段：优先对高频出现在 WHERE 、 JOIN 、 ORDER BY 子句中的字段建索引，尤其是高选择性字段（如身份证号、手机号）；组合索引遵循最左前缀原则；写入频繁字段谨慎建索引，避免影响性能；大字段类型可使用前缀索引优化查询。 6. InnoDB与MyISAM区别：InnoDB支持事务、外键和行级锁，采用聚簇索引存储数据，适合高并发读写场景，具备崩溃恢复能力；MyISAM使用表级锁，无事务支持，索引与数据分离存储， COUNT(*) 统计高效，但不适用于写密集业务。生产中InnoDB用于核心交易模块，MyISAM适用于只读统计类表。 7. InnoDB锁及表锁升级：InnoDB提供共享锁、排他锁、间隙锁等多种锁机制，并通过MVCC减少冲突。表锁升级常发生于SQL无法命中索引引发全表扫描、大事务更新大量数据导致自适应哈希索引失效、执行 ALTER TABLE 等DDL操作，以及死锁检测后强制升级场景。优化需确保索引覆盖查询，拆分大事务降低锁粒度。