AWS国际版免实名 如何查看亚马逊RDS数据库的慢查询日志与死锁
这类搜索背后的真实意图
- 尽快定位性能瓶颈：明确在哪里看慢查询、如何开启、多久能看到数据。
- 线上风险可控：开启哪些参数会重启实例、是否影响业务、如何在维护窗口进行。
- AWS国际版免实名 成本可控：CloudWatch Logs、Performance Insights 和日志保留各自的费用与增量成本。
- 账号与区域限制：国际站与中国区的开通与实名认证差异、支付方式、风控审核触发点。
- 权限边界：DBA/IAM 需要什么权限，最小权限怎么配。
- 不同引擎差异：MySQL/MariaDB、PostgreSQL、SQL Server、Aurora 的开启方法与可行替代方案。
先选路径：不同引擎查看慢查询与死锁的最短路线
| 引擎 | 慢查询获取 | 死锁获取 | 是否需重启 | 控制台可视化 |
|---|---|---|---|---|
| RDS for MySQL / MariaDB | 参数组启用 slow_query_log、long_query_time，日志到 CloudWatch 或控制台下载 | 设置 innodb_print_all_deadlocks=1，在错误日志中检索; 或 Performance Insights 阻塞分析 | 部分参数需重启；Aurora MySQL 多数动态 | Performance Insights、CloudWatch Logs |
| RDS for PostgreSQL | 设置 log_min_duration_statement、log_statement_sample_rate，日志到 CloudWatch | 设置 log_lock_waits、deadlock_timeout；结合 pg_stat_activity/pg_locks | 通常不需重启（参数动态），个别场景例外 | Performance Insights、CloudWatch Logs |
| RDS for SQL Server | 启用 Query Store 收集 Top Queries 与执行计划 | system_health Extended Events 捕获死锁；也可自建 deadlock 捕获会话 | 无需重启，但 Query Store 初次启用有负载 | Performance Insights（部分版本/实例族支持） |
| Aurora MySQL / Aurora PostgreSQL | Aurora 参数组同源引擎；Aurora MySQL 推荐 Performance Schema + Performance Insights | Aurora MySQL 错误日志/PI，Aurora PG 同 Postgres | 多为动态参数；少量需重启 | Performance Insights、CloudWatch Logs |
账号与区域准备：开通、认证、支付与风控差异
国际站（aws.amazon.com）
- 开通与认证：邮箱注册 + 信用卡验证 + 电话/短信验证。企业账号建议提前提交税务与公司信息以便后续开票/额度申请。
- 支付方式：信用卡为主；部分国家可 ACH/SEPA 自动扣款；企业可申请月结（需信用审核与合同）。不支持预存储值，代金券/信用额度属于抵扣而非充值。
- 风控点：新账号高频创建/删除实例、异常地区登录、账单激增、大流量日志写入易触发人工审核或临时限制（如无法创建资源）。建议：
- 首月启用预算与告警；限制 CloudWatch Logs 入口；先在测试区验证参数。
- IAM 使用最小权限，避免用 Root 操作。
中国区（北京/宁夏）
- 账号体系独立：需在 amazonaws.cn 单独注册。运营商（北京：光环新网，宁夏：西云数据）。
- 实名认证：个人身份证或企业营业执照实名认证后方可启用多数服务。
- AWS国际版免实名 支付方式：人民币结算，常见为对公转账与本地支付渠道。支持预付款与合同制更普遍，财务合规更易管理。
- 服务与价格差异：部分服务开通节奏与价格不同。启用 CloudWatch Logs/Performance Insights 时请按中国区价格页测算。
账号购买与续费实操建议
- AWS国际版免实名 若需企业月结或本地发票：国际站可通过授权经销商开通转售账户；中国区可直接走合同与预付款。
- 生产业务启用 RDS 前，先完成付款方式验证与限额提升，避免日志激增导致欠费停机。
- 预算与告警：按实例与日志分别设置预算；对 CloudWatch Logs 单独设阈值和通知。
按引擎的开启与查看步骤（避坑版）
AWS国际版免实名 MySQL / MariaDB
- 确认参数组：RDS 控制台查看实例的 DB Parameter Group，若为默认组，先复制创建自定义组并关联实例。
- 开启慢查询：
- slow_query_log=1（若为静态需重启，Aurora 多为动态）
- long_query_time=1~3（生产初次建议 1–3 秒，避免日志爆量）
- log_output=FILE（推荐 CloudWatch 导出；TABLE 会带来更高开销）
- 可选：log_queries_not_using_indexes=1（短时间排查用，持续开启会产生日志洪峰）
- 导出到 CloudWatch Logs：
- RDS 控制台 > 日志与监控 > 日志导出，勾选 slowlog/error/mysql upgrade（视版本而定）。
- 需要 RDSServiceLinkedRole 与 CloudWatch 权限自动创建；如失败，先赋予 IAM 权限。
- 死锁捕获：
- 在参数组中设置 innodb_print_all_deadlocks=1。
- 死锁将写入错误日志，CloudWatch Logs 中检索关键词：LATEST DETECTED DEADLOCK。
- 临时排查可执行：SHOW ENGINE INNODB STATUS; 但该命令仅显示最近一次。
- 快速查看方法：
- 控制台下载日志：实例 > 日志与事件 > 选择 slowquery/mysql-error 日志下载。
- AWS国际版免实名 CLI 拉取片段：aws rds download-db-log-file-portion --db-instance-identifier xxx --log-file-name slowquery/mysql-error --starting-token 0 --output text
- 性能可视化：启用 Performance Insights，观察 Top SQL、等待事件、阻塞树；对死锁前后窗口特别有用。
- 常见坑：
- 修改了参数组但未关联实例或未重启导致参数未生效。
- long_query_time 设太低 + 高并发，CloudWatch Logs 突增触发账单告警。
- log_output=TABLE 持续开启导致 I/O 压力与表膨胀。
PostgreSQL / Aurora PostgreSQL
- 参数建议（均在参数组设置，通常为动态）：
- log_min_duration_statement=1000（初次 1000ms，必要时下调）
- log_lock_waits=on，deadlock_timeout=1s（便于定位锁等待与死锁）
- log_statement='ddl' 或采样：log_statement_sample_rate=0.01（避免全量日志）
- CloudWatch 导出：同样在实例的日志导出中勾选 postgresql 日志。
- 在线排查 SQL（无日志也能用）：
- 锁等待：select pid,wait_event_type,wait_event,query from pg_stat_activity where wait_event_type='Lock';
- 阻塞关系：select pg_blocking_pids(pid),pid,query from pg_stat_activity where state='active';
- 锁详情：select * from pg_locks l join pg_stat_activity a on l.pid=a.pid;
- 死锁日志：当发生死锁，Postgres 会在日志中打印涉及语句与关系名，到 CloudWatch 搜索 deadlock detected。
- 性能可视化：Performance Insights + pg_stat_statements 扩展（在参数组 shared_preload_libraries 加入 pg_stat_statements，并创建扩展）。
- 常见坑：
- 未开启 pg_stat_statements 却只看 PI，难以追踪语句指纹历史。
- deadlock_timeout 太高，定位延迟且缺乏等待日志。
- CloudWatch Logs 未勾选，导致控制台只有少量近期日志。
SQL Server
- 慢查询：启用 Query Store（数据库属性 > Query Store > Operation Mode: Read Write；或 T-SQL 设置 MAX_STORAGE_SIZE_MB 等限制）。
- 死锁：使用系统默认 system_health 扩展事件。查询 XML 片段可还原死锁图；必要时单独启用 xml_deadlock_report 事件会话。
- 日志获取：
- RDS 控制台可查看 SQL Server 错误日志；死锁通常写入扩展事件而非错误日志。
- 在数据库中查询 Query Store 视图 sys.query_store_runtime_stats 等获取耗时与回归。
- 常见坑：
- Query Store 初启用在高峰期增加写放大，应设置合适 capture mode 与清理策略。
- 把死锁期望在错误日志中直接看到，实际需解析扩展事件。
权限与风控：最小权限、重启窗口与审计
- IAM 最小权限：
- 查看日志：logs:FilterLogEvents、logs:GetLogEvents、rds:DownloadDBLogFilePortion。
- 改参数组：rds:ModifyDBParameterGroup、rds:ModifyDBInstance（含 ApplyImmediately）。
- 启用 PI：pi:EnablePerformanceInsights、rds:ModifyDBInstance。
- 重启与维护窗口：
- 标记需重启的参数变更安排在维护窗口；多可用区下切换不等于无感，短暂连接中断需应用层重试。
- 审计与合规：
- 变更前记录参数基线与回滚点；CloudTrail 记录控制面操作，便于审计。
- 生产环境避免长时间开启高噪声日志（如 general log、过低 long_query_time）。
成本核算：日志与监控的隐藏账单
- CloudWatch Logs 成本构成：
- 摄入量：按 GB 计费。慢查询阈值过低会指数级提升摄入。
- AWS国际版免实名 存储与保留：按 GB-月计费。建议按日志组设置 3–7 天短保留，长期归档到 S3。
- 检索：Logs Insights 按扫描量计费，复杂查询要限制时间范围。
- Performance Insights 成本与保留：
- 基础保留通常包含短期历史；长期保留按 vCPU 与时长计费。
- 小实例长期开启的成本可忽略不计，中大型实例需要在预算中单列。
- AWS国际版免实名 S3 归档与分析：
- 将日志订阅到 Kinesis Firehose → S3，配合 Athena 做按需分析，可显著降低 CloudWatch 保留成本。
- 跨区/跨账户传输会产生数据传输与请求费用。
- 示例估算方法（按月）：
- AWS国际版免实名 慢查询日志量估算：QPS × 命中比例 × 平均条目大小（行文本） = 每秒字节 → 换算到 GB。
- CloudWatch 成本 ≈ 摄入单价 × 月摄入量 + 存储单价 × 平均保留量。
- AWS国际版免实名 PI 成本 ≈ vCPU 数 × 小时单价 × 使用小时数（超过基础保留部分）。
场景化案例：从开启到定位再到优化
案例一：电商 MySQL 高峰慢查询导致 CPU 95%
- 动作：将 long_query_time 设为 2s，开启 slow_query_log 与 CloudWatch 导出，PI 打开。
- AWS国际版免实名 发现：60% 慢查询来自 order_items 联表，where 条件 user_id + created_at，只有单列索引。
- 优化：补充复合索引 (user_id, created_at)，并将分页方式从 offset 改为基于游标的 seek。
- 结果：p95 查询时间从 3.6s 降到 220ms，CPU 峰值从 95% 降到 55%。
- 成本控制：恢复 long_query_time 到 3s，并对 CloudWatch 日志组设 3 天保留。
案例二：SaaS 多租户 PostgreSQL 间歇性死锁
- 动作：log_lock_waits=on，deadlock_timeout=1s；CloudWatch 搜索 deadlock detected；并用 pg_blocking_pids 定位阻塞链。
- 发现：两条事务对 account 与 subscription 表更新顺序相反，偶发循环等待。
- 优化：统一更新顺序（先 account 后 subscription），分离长事务报表至只读副本。
- 结果：死锁从每日 30 次降为 0；慢查询数量下降 40%。
案例三：SQL Server 月底账单批处理卡顿
- AWS国际版免实名 动作：启用 Query Store，分析 Top Regressed Queries；查看 system_health 中的死锁 XML。
- 发现：两存储过程在 REPEATABLE READ 下长事务更新同一索引范围，导致死锁与等待。
- 优化：将热点语句改为行版本控制（RCSI），添加覆盖索引，拆分批量提交。
- 结果：批处理窗口缩短 35%，并发报错清零。
常见失败原因与排查清单
- 修改了错误的参数组或未关联到实例。
- 需要重启的参数未重启，实际未生效。
- CloudWatch Logs 未授权或导出未勾选，控制台看不到慢日志。
- 长时间开启 TABLE 方式慢日志导致 I/O 压力与空间增长。
- 死锁未记录：MySQL 未开启 innodb_print_all_deadlocks；Postgres deadlock_timeout 过大。
- 只看平均值忽略 p95/p99，错判问题严重度。
- 故障发生后才开启日志，缺少事发窗口数据。
- 多可用区故障切换后未更新日志组检索前缀，遗漏新实例日志。
FAQ：围绕购买、认证、支付、风控与使用限制
- 开启慢查询会影响性能吗？
- MySQL FILE 慢日志对 CPU 影响可控（常见 < 5%），TABLE 模式成本更高；Postgres 记录语句耗时通常可接受。
- 建议先在低流量窗口开启并观察指标。
- 必须启用 Performance Insights 吗？
- 不是必须，但在无侵入情况下快速看到热 SQL 与等待事件，排障效率更高。
- 国际站怎么付费最稳妥？
- 绑定信用卡并设置账单告警；企业需月结可通过经销商或与 AWS 信审对接。
- 中国区是否需要实名认证？
- 需要。未实名会限制服务开通，日志导出/监控等也可能受限。
- 欠费会影响日志吗？
- CloudWatch 与 RDS 都会受影响，轻则新日志无法写入，重则实例被停机。建议为日志单独设预算与告警。
- 权限不够怎么给 DBA 只读日志？
- 创建只读 IAM 策略，允许 logs:DescribeLogGroups, logs:FilterLogEvents, rds:DownloadDBLogFilePortion，禁止 rds:ModifyDBInstance。
- 多账户多区域如何统一看慢日志？
- AWS国际版免实名 用 Logs Subscription 统一汇聚到集中账户的 S3，再用 Athena/QuickSight 统一分析；或开启跨账户 PI 访问。
- Aurora Serverless v2 支持这些吗？
- 支持 CloudWatch 日志与 PI；参数需通过集群/实例参数组配置，注意与自动缩放的交互。
决策建议：如何以最小风险上线慢查询与死锁监控
- 步骤 1（账户侧）：确认付款方式有效、预算已配置；中国区先完成实名认证与合同/预付。
- 步骤 2（参数侧）：创建自定义参数组；MySQL 设置 long_query_time≥1s，Postgres 设置 log_min_duration_statement≥1000ms；开启必要的死锁与锁等待日志。
- 步骤 3（观测侧）：先开启 CloudWatch 导出，保留 3–7 天；如需更长分析，订阅到 S3。
- 步骤 4（可视化）：启用 Performance Insights 观察 24–72 小时，确认热点 SQL 与等待事件。
- 步骤 5（优化与回收）：完成索引/SQL 优化后上调阈值，关闭高噪声选项，控制日志成本。
- 步骤 6（制度化）：把参数与预算纳入 IaC 与 FinOps，定期审计日志保留与费用。
附：常用命令与检索关键字
- MySQL 死锁检索词：LATEST DETECTED DEADLOCK；慢日志字段：Query_time, Lock_time, Rows_examined。
- PostgreSQL 死锁检索词：deadlock detected；锁等待：canceling statement due to lock timeout。
- AWS CLI 下载日志：aws rds download-db-log-file-portion；CloudWatch 检索：aws logs filter-log-events。