> 技术文档 > MySQL 的 Query Cache 和 PostgreSQL 的 pg_prewarm_postgresql query cache

MySQL 的 Query Cache 和 PostgreSQL 的 pg_prewarm_postgresql query cache


目录标题

    • ✅ 一、MySQL 的 Query Cache(查询缓存)【已废弃】
      • 🔹 功能概述
      • 🔹 原理机制
      • 🔹 主要参数
      • 🔹 优缺点
      • ⚠️ 注意事项:
    • ✅ 二、PostgreSQL 的 pg\\_prewarm(页级预热)
      • 🔹 功能概述
      • 🔹 原理机制
      • 🔹 使用方式
      • 🔹 配合自动预热使用
      • 🔹 优缺点
    • ✅ 三、对比总结
    • ✅ 实战建议
      • 🟢 若你是运维/PostgreSQL DBA:
      • 🔴 若你还在使用老版本 MySQL(5.6/5.7):

MySQL 的 Query CachePostgreSQL 的 pg_prewarm,虽然都涉及“缓存”,但原理、作用层面完全不同。下面我们从 核心功能、原理机制、使用建议、适用场景、对比分析 等角度全面说明。


✅ 一、MySQL 的 Query Cache(查询缓存)【已废弃】

🔹 功能概述

MySQL 的 Query Cache 是一个用于缓存 SQL 查询结果的全局缓存,当完全相同的 SQL 被再次执行时,可以直接返回缓存结果,跳过解析、优化、执行流程

🔹 原理机制

  • 查询缓存的是 结果集(Result Set),不是执行计划。
  • 只有完全相同的 SQL 字符串(包括空格、大小写)才能命中缓存。
  • 当表中的数据发生变化(如 INSERT/UPDATE/DELETE),该表相关的缓存会全部失效。
  • Query Cache 是全局唯一的,不分库表、用户,也不是线程局部缓存。

🔹 主要参数

query_cache_type = 1  # 0=off, 1=on, 2=DEMANDquery_cache_size = 64M # 缓存总大小query_cache_limit = 1M # 单条查询最大缓存

🔹 优缺点

优点 缺点 小型、读多写少场景命中率高,减少 CPU 和磁盘压力 易导致全局锁争用,数据一变即清空相关缓存,命中率低 查询速度可极大提升(只要 SQL 和表数据都未变化) 高并发写时性能下降严重,适得其反;多核扩展性差

⚠️ 注意事项:

  • MySQL 5.7 开始默认关闭,8.0 已完全移除(废弃)
  • 在现代系统中,推荐使用应用层缓存(如 Redis)、Proxy 层缓存或使用 InnoDB Buffer Pool(页缓存)而非 Query Cache

✅ 二、PostgreSQL 的 pg_prewarm(页级预热)

🔹 功能概述

PostgreSQL 的 pg_prewarm 是一个 将表或索引数据加载进共享缓冲区(shared_buffers) 的扩展模块,常用于数据库重启后的 热数据预加载(预热),加快数据库“恢复访问性能”。

🔹 原理机制

  • PostgreSQL 使用 Buffer Pool(共享缓冲区) 管理数据页,冷启动时缓存为空。
  • pg_prewarm 可以将指定的表、索引页主动读取进缓存,避免冷启动时慢查询。
  • 可以搭配 auto_preload_libraries 自动在启动时加载,也可以定期 dump 热页信息并在启动恢复。

🔹 使用方式

-- 加载扩展CREATE EXTENSION IF NOT EXISTS pg_prewarm;-- 手动预热某表SELECT pg_prewarm(\'mytable\');-- 指定预热方式(可选:prefetch, read, buffer, read_async)SELECT pg_prewarm(\'mytable\', \'prefetch\');

🔹 配合自动预热使用

  1. 开启插件:
shared_preload_libraries = \'pg_prewarm\'
  1. 使用 pg_buffercache + pg_prewarm 定期导出热数据页,在重启后恢复:
SELECT * FROM pg_buffercache LIMIT 10;-- 使用 extension 来结合自动恢复机制

🔹 优缺点

优点 缺点 明确、主动地提升关键数据表冷启动性能 非自动缓存,需额外维护策略与脚本 适合大表/索引重启预热,提升系统恢复性能 如果 shared_buffers 太小,效果有限

✅ 三、对比总结

特性 / 系统 MySQL Query Cache PostgreSQL pg_prewarm 缓存内容 SQL 查询结果 数据页(blocks) 缓存粒度 SQL 层 存储层(页级别) 命中条件 SQL 完全相同且数据未改动 无需精确 SQL,可按表预热 一致性影响 高(数据更新后清除缓存) 无影响(数据页始终一致) 是否自动 可自动缓存 需手动或脚本维护 现代支持情况 MySQL 8.0 移除 PostgreSQL 官方推荐扩展 推荐替代方案 Redis 缓存 + InnoDB Buffer Pool 使用 shared_buffers + pg_prewarm

✅ 实战建议

🟢 若你是运维/PostgreSQL DBA:

  • 建议使用 pg_prewarm 结合 pg_buffercache、监控热页访问模式,定期导出热数据页信息,并写入 cron 脚本,在系统重启后调用预热脚本提升性能。

🔴 若你还在使用老版本 MySQL(5.6/5.7):

  • 避免启用 Query Cache(除非是非常小的读密集型场景),建议通过应用层缓存 + InnoDB 参数优化提升查询效率。

  • 使用 InnoDB 缓冲池预热

    innodb_buffer_pool_dump_at_shutdown = 1innodb_buffer_pool_load_at_startup = 1