056、查询优化之优化实战

快速定位问题SQL

Dashboard->SQL Statements

快速定位慢查询

Dashboard -> slow queries

DML语句优化

大量DML操作导致OOM

• 案例背景
  索引扫描范围过大，无论优化器是选择index scan还是table scan，TiDB都倾向 TiKV corprocessor请求读取大量的数据
  

• 案例现象
  Coprocessor CPU 使用率飙升 -> CPU 资源耗尽 -> 集群的duration升高
  大量数据删除 -> 加载到内存 -> 打满TiDB的内存 -> 导致OOM

• 解决

  • 通过hint 或者 use index的方式强制走索引
  • 问题：在大量读取数据的场景，强制走索引很可能会带来更差的效果
  • 大事务化成小事务处理
    

基于执行计划的优化

执行计划不稳定导致延迟增加

• 案例背景
  

• 现象
  现象：执行计划不稳定可能会导致业务的相应延迟升高，duration出现抖动的情况

• 解决
  方案一： 及时收集统计嘻嘻

  • 考虑使用analyze table来手动收集统计信息，或者结合cron job的方式
  • 调整tidb_auto_analyze_ration、tidb_auto_analyze_start_time和tidb_auto_analyze_end_time参数提高收集的频次，扩大收集的时间窗口

方案二： 更改执行计划
- 使用hint或者use index 语句固化执行计划
- 使用sql hint的方式更改执行计划

SQL执行计划不准

• 背景
  

• 索引分析
  
  
  

• 统计信息收集
  统计信息分析
  统计信息收集后
  
  验证结果