错误处理与日志专题测试

对

错

对

错

使用GORM的SlowThreshold配置,自动输出慢查询日志

在数据库端开启慢查询日志,通过日志分析工具处理

使用自定义Plugin在回调中计算SQL执行时间,超过阈值时记录日志并上报监控

以上方案的组合使用是最完整的慢查询监控策略

将慢查询按SQL类型和表分组,统计数量和平均延迟,在Grafana中展示热力图

将每条慢查询的SQL语句打印到日志,人工逐条分析

只记录最慢的10条查询,不关注整体趋势

慢查询数据不需要可视化,有告警就足够了

通过慢查询日志,发现短时间内大量相似SQL的执行

通过代码review,检查是否有在循环中执行数据库操作的代码

通过监控SQL执行次数,识别异常的高频SQL模式

以上方法的组合使用

总是记录完整的SQL参数值,便于排查问题

永远不记录参数值,只记录SQL模板,避免泄露敏感信息

根据日志级别决定是否记录参数值,Info级别记录,Warn/Error级别不记录

对敏感参数(如密码)进行脱敏后再记录,其他参数正常记录

Silent - 完全关闭所有日志输出

Error - 只输出错误级别的日志

Warn - 输出警告和错误级别的日志

Info - 输出所有SQL语句和参数

开发环境使用Info级别+彩色输出,生产环境使用Warn级别+结构化日志

所有环境使用相同的日志配置,保持一致性

开发环境关闭日志提高性能,生产环境开启详细日志

开发环境使用Debug级别,生产环境使用Info级别

GORM可以自动分析慢查询并添加索引,无需人工干预

GORM可以在运行时自动重写慢查询的SQL,提升性能

GORM本身不提供自动优化慢查询的功能,需要人工分析和优化

GORM可以通过插件自动优化所有慢查询

日志和监控功能重叠,只需要其中一个即可

日志用于详细记录和排查问题,监控用于趋势分析和告警,两者互补

监控可以替代日志,因为监控指标更结构化

日志可以替代监控,因为日志包含更详细的信息

GORM日志和业务日志应该输出到不同的目标,便于分别处理

GORM日志应该使用独立的Logger实例,与业务日志的配置分离

所有日志应该合并到一起,统一管理

GORM日志的级别可以与业务日志不同,如GORM用Warn,业务用Info

SQL执行计划 - 通过EXPLAIN分析索引使用和扫描行数

数据库连接等待时间 - 是否因为连接池满而等待

网络延迟 - 应用与数据库之间的网络传输时间

锁等待时间 - 是否因为行锁或表锁导致阻塞

日志输出(I/O操作)会显著增加SQL执行的延迟

使用异步日志写入可以减少对主业务流程的性能影响

关闭日志(Silent级别)可以提升10%以上的数据库操作性能

日志级别越高(如Debug),性能影响越大

当慢查询数量超过阈值(如每分钟10条)时触发告警

当P99 SQL延迟超过目标值(如2秒)时触发告警

当某条特定SQL频繁变慢时,针对该SQL单独告警

只要出现任何慢查询就立即告警,确保不遗漏

Preload加载了大量关联记录,导致SQL执行时间过长

Preload嵌套多层关联,产生复杂的JOIN或多次查询

Preload没有使用索引,导致关联查询全表扫描

Preload总是比懒加载(Lazy Loading)更慢

可以通过logger.New创建自定义的日志器,指定日志级别和输出方式

GORM默认将日志输出到标准输出(stdout),可以通过配置修改

可以通过设置IgnoreRecordNotFoundError控制是否记录"记录未找到"的日志

GORM的日志系统基于zap,可以直接使用zap的配置