supervision-boot/sql/20261027_profile_query_performance.md

单位 / 个人问题库查询优化（MySQL 5.7.21）

本次改动

• 先按单位 ID / 身份证号聚合明细，再连接名称、职务等展示字段，避免在多字段的明细结果上分组。
• 分页使用自定义 count SQL，使用 EXISTS 判断是否有符合条件的问题，不再重复统计每个单位的涉及人数或每个人的问题数。
• 保留 DISTINCT 去重语义、筛选条件、全量排序后分页及总数。不新增缓存，不降低数据实时性。
• 单位仍按问题创建时间统计；个人仍按发现时间、已办结、属实/部分属实及个人责任记录统计，不调整业务口径。

生产核查步骤

1. 在业务库执行 20261027_profile_query_explain.sql，收集版本、表规模估计、索引及优化前后 8 份 EXPLAIN。默认不限时间、不选单位；如果慢请求带筛选条件，应按实际请求补上同样条件。
2. 检查 negative_blame 是否按 negativeId / blameIdCode 走索引、negative 是否使用对应时间和状态索引，以及连接字段的数据类型和字符集是否一致。小的聚合结果出现临时表或排序不等于优化失败。
3. 对照现有索引评估 20261027_profile_query_indexes.sql。脚本按完整左前缀跳过已有等价索引，不删除旧索引。先确认 InnoDB、字段长度、磁盘空间和同名索引冲突；低峰期执行。在线建索引仍消耗 I/O 并可能等待元数据锁，LOCK=NONE 不支持时会停止，不降级为锁表。
4. 索引准备后部署后端改动，再执行优化后 EXPLAIN 和实际请求。MySQL 5.7 不支持 EXPLAIN ANALYZE；EXPLAIN 的 rows 是估计值，不能用来证明 3 秒达标。
5. 性能验收同时计入总数 SQL、列表 SQL、接口开销和网络耗时。分别验证首次请求与重复请求、不限时间与短时间范围、单位/姓名筛选、升降序、后续分页，以及实际并发下的耗时。避免把查询缓存命中误判为 SQL 本身已优化。

验证状态

• 后端编译、SQL 映射与排序/筛选回归测试已通过。
• 本地模拟使用 SQLite 内存数据库及 12 万条问题，属于结果一致性和优化方向验证，不是生产 MySQL 5.7 性能验收。
• 开发数据库连接失败；生产索引、执行计划和端到端耗时尚未取得，不能承诺已达到 3 秒。
• 索引脚本尚未对任何数据库执行；本次未改前端或运行前端构建。