新手区 大佬们关于索引的测试你们是怎么设计测试用例的

hug. · 2024年01月02日 · 最后由 simiko 回复于 2024年01月09日 · 5857 次阅读

最近接了个新需求,是开发对数据库表进行了索引的优化,拿到这个需求不太懂怎么去设计用例测试,大佬们是怎么测试的
这是其中的一段 sql

  • "SELECT "
  • " app_id AS appId, "
  • " tool_type AS toolType,"
  • " SUM(duration) AS dailyStartDuration "
  • "FROM qt_test "
  • "WHERE del = 0 "
  • " AND app_id IN ( "
  • " "
  • " #{appId}"
  • " ) "
  • "AND created_time BETWEEN UNIX_TIMESTAMP(#{statDate}) AND UNIX_TIMESTAMP(#{statDate})+86399 "
  • "GROUP BY app_id,tool_type"
共收到 9 条回复 时间 点赞

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

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

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

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

  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 分析指令,确实具备一定的能力去分析慢查询,但实际还是压测更靠谱一点,因为在实际的项目里,经常出现一个表索引过多的情况,查询优化器可能偶尔出现走不到指定索引的慢查询。所以实际过程中是压测更靠谱(且需要多次压测复现)

需要 登录 後方可回應,如果你還沒有帳號按這裡 注册