我还真没做过这种测试。 一般索引优化了是为了性能吧。 你直接做性能测试不行么

索引的目的是优化查询速度，按接口响应性能方向设计

看加了索引速度快没有，索引有没有用上

这种测试咋测？ 我感觉一般有改动那就几个步骤吧，先确保原有功能不被开发优化影响，再看下优化的效果

1. 优化前和优化后的性能对比
2. 跑下接口自动化看下接口情况

• 3.看下索引失效的相关场景：
  • 1. 模糊查询以% 开头
  • 2. 使用 or ，如果 or 两边都不是索引字段，那么索引就会失效
  • 3. 使用复合索引，没有 使用左侧的列查找，索引失效 create index xxxx on 表名 (字段 1 ，字段 2 ) 使用字段 1 生效索引
  • 4. 在 where 中使用了运算 /函数，例如 lower()

我这一般是用 explain 看 select 的各种条件是是否用了索引

如上所说，这个需求的目标就是性能优化，所以我们只要验证优化前后性能有符合预期的提升就行，关键点：

1. 优化前后，常规场景或目标场景下，有性能提升
2. 优化前后，极端场景或非目标场景下，无性能劣化

第一点好操作，第二点需要多判断一下。这个优化方式是加索引，加索引不一定万能，如高频写可能因为加了索引导致性能更差。

索引的优化 那要看具体优化了啥索引啊 前后查询效率有啥变化，索引管理的列、表这些数据搞多点才能看出效率，而不是去测 sql 的结果

explain 查看执行计划

开发会改索引，应该是你们生产出现了慢查询，你可以先分析实际场景嘛。比如说是不是因为 qps 太大，导致了慢查询？如果是，专门针对这个场景做压测，切换前后，对比性能是否有提升～explain 是 sql 分析指令，确实具备一定的能力去分析慢查询，但实际还是压测更靠谱一点，因为在实际的项目里，经常出现一个表索引过多的情况，查询优化器可能偶尔出现走不到指定索引的慢查询。所以实际过程中是压测更靠谱（且需要多次压测复现）