分析下 SET timestamp=1735387923; select LISTID from t_bluesky_p

动态 未结 0 81
邮箱用户_r5u2k
邮箱用户_r5u2k LV1 2024年12月31日 13:55 发表
摘要:
分析下 SET timestamp=1735387923; select LISTID from t_bluesky_pdf_text where CONTENT!='' AND CONTENT IS NOT NULL and frequency != '5' and STATUS = '0' limit 500; # Time: 241228 20:12:36 # User@Host: epab_bluesky_prod[epab_bluesky_prod] @ [192.168.103.111] Id: 1657286 # Query_time: 2.453281 Lock_time: 0.000083 Rows_sent: 24 Rows_examined: 6313346 SET timestamp=1735387956; select tbatchjobs0_.SUB_ID as col_0_0_ from T_BA_JO_SU tbatchjobs0_ where tbatchjobs0_.AGENT_ID is null; # Time: 241228 20:12:40
这是一段MySQL数据库的慢查询日志片段,让我详细分析一下: 1. 第一个查询: ```sql SELECT LISTID FROM t_bluesky_pdf_text WHERE CONTENT!='' AND CONTENT IS NOT NULL AND frequency != '5' AND STATUS = '0' LIMIT 500; ``` 性能特征: - 查询时间:2.453281秒 - 检查的行数:6,313,346行 - 返回的行数:24行 问题点: - 扫描行数非常多(630万),但只返回24行 - 可能缺少适当的索引 - WHERE条件中的多个判断可能导致全表扫描 优化建议: - 为CONTENT、frequency、STATUS添加复合索引 - 评估是否可以优化查询条件 - 考虑分区或重构查询 2. 第二个查询: ```sql SELECT tbatchjobs0_.SUB_ID FROM T_BA_JO_SU tbatchjobs0_ WHERE tbatchjobs0_.AGENT_ID is null; ``` 日志中未显示性能数据,但查询逻辑比较简单。 总体建议:关注索引优化和查询效率。
收藏(0)  分享
相关标签: 智能问答
问题没解决?让AI助手帮你作答 AI助手
0个回复
  • 消灭零回复