索引监控核心是命中率与碎片率：命中率低需排查设计、写法或统计信息，碎片率超30%需重建，5%~30%可重组；应分级告警、自动采集并记录优化档案。
索引监控的核心是两个指标：索引是否被用上（命中率），以及用久了是否变“松散”（碎片率）。这两项不持续跟踪，性能问题往往等出事才暴露。
索引命中率：看查询是否真走索引
命中率低≠没建索引，更可能是索引设计不合理、查询写法绕过索引，或统计信息过期。重点不是追求100%，而是识别长期为0或极低的索引。
- SQL Server 可查 sys.dm_db_index_usage_stats，关注 user_seeks + user_scans（实际查找/扫描次数）与 user_lookups（书签查找，说明非聚集索引需回表）的比例；若 user_seeks = 0 且 user_updates > 0，大概率是“写多读少”的无效索引
- MySQL 可结合 performance_schema.table_io_waits_summary_by_index_usage，看 COUNT_STAR 是否长期为0；配合 EXPLAIN 验证关键慢查询是否走了预期索引
- 建议每周自动采集一次，并标记连续3次 seek/scan = 0 的索引，加入待评估清单
索引碎片率：判断是否需要重建或重组
碎片高会拖慢范围扫描、增加I/O和内存压力，但并非所有碎片都要立刻处理——只有对高频读写的大型索引才敏感。
- SQL Server 用 sys.dm_db_index_physical_stats 查 avg_fragmentation_in_percent：
• • 5% ~ 30%：ALTER INDEX … REORGANIZE
• > 30%：ALTER INDEX … REBUILD（注意锁和日志增长） - PostgreSQL 看 pg_stat_all_indexes 的 idx_scan，再结合 pg_total_relation_size 和 pg_relation_size('index_name') 估算膨胀率；真正用 VACUUM FULL 或 REINDEX 前，先确认是否因大量UPDATE/DELETE导致死元组堆积
- 避免固定时间全量重建——按使用频率和碎片程度分级调度，比如只对 size > 100MB 且 fragmentation > 20% 的索引自动处理
轻量级监控落地建议
不依赖商业工具也能建立有效闭环，关键是把数据采集、阈值告警、人工复核串起来。
- 用定时任务（如SQL Agent / cron）每天凌晨执行一段脚本，把关键指标写入一张监控表，保留30天
- 设置两级告警：
• 邮件通知：单个索引命中率连续7天为0，或碎片率突破30%
• 企业微信/钉钉静默提醒：碎片率15%~30%的索引超过10个，提示“批量评估窗口开启” - 每次重建/删除索引后，记录操作人、原因、前后碎片与查询耗时对比，形成可回溯的优化档案
