用 EXPLAIN ANALYZE 定位慢查询，而不是猜
【摘要】 接口变慢时，很多人第一反应是加索引，但索引加错位置反而拖慢写入。更稳妥的方式是用 PostgreSQL 的 EXPLAIN ANALYZE 看真实执行计划。先对慢 SQL 执行：EXPLAIN (ANALYZE, BUFFERS)SELECT * FROM ordersWHERE user_id = 42 AND status = 'paid'ORDER BY created_at DESC...
接口变慢时，很多人第一反应是加索引，但索引加错位置反而拖慢写入。更稳妥的方式是用 PostgreSQL 的 EXPLAIN ANALYZE 看真实执行计划。先对慢 SQL 执行：
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders
WHERE user_id = 42 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;
重点看三处：是否走了全表扫描 Seq Scan、预估行数与实际行数是否差距很大、排序是否产生额外磁盘开销。如果 user_id 和 status 过滤性强，可以建联合索引 (user_id, status, created_at DESC)，让过滤和排序一次完成。注意索引列顺序要匹配查询条件，不要盲目给每个字段单独建索引。改完后再次执行 EXPLAIN ANALYZE 对比耗时和扫描行数，用数据验证效果。慢查询优化不是猜出来的，而是看出来的。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）