mysql 8.0 起已彻底移除 query_cache，清缓存操作无效；前端数据陈旧主因是应用层、中间件或浏览器/cdn 缓存，需逐层排查 http 响应头、nginx proxy_cache、框架视图缓存及 redis 缓存一致性。

mysql 的 query_cache 已被移除，别白忙活清缓存

mysql 8.0 起彻底删掉了查询缓存（query_cache_type、query_cache_size 等配置），哪怕你执行了 reset query cache 或设成 0，也完全没用——它根本不存在了。很多教程还在讲这个，但你查的其实是“幻觉缓存”。真正卡住前端的，通常是应用层或中间件的缓存。

前端看到旧数据，大概率是浏览器或 CDN 缓存了响应

后端 SQL 导入成功、数据库里数据已更新，但前端页面还是老的，第一反应不该查数据库，而是看 HTTP 响应头：Cache-Control、ETag、Last-Modified。尤其当接口走的是 Nginx、Cloudflare 或 Vercel 这类带默认缓存策略的服务时：

• Chrome 开发者工具 Network 标签页里点请求 → Headers → Response Headers，找 cache-control: public, max-age=3600 这类字段
• 临时验证：在 URL 后加随机参数（如 ?t=123）强制绕过缓存，如果这时数据变新了，基本锁定是缓存问题
• Nginx 配置里如果写了 proxy_cache_valid 200 1h;，就算后端返回了新数据，Nginx 仍会吐出旧缓存

Django/Flask/Express 这类框架自带视图级缓存，得手动关或刷新

比如 Django 的 @cache_page(60 * 15) 装饰器、Flask 的 @cache.cached(timeout=300)，或者 Express 用 res.set('Cache-Control', 'max-age=300')，这些都会让整个响应被缓存。SQL 导入后它们不会自动失效：

• Django：调用 cache.clear()（注意这是全库清空）；更稳妥的是用 cache.delete('my_view_key') 针对性删除
• Flask-Caching：用 cache.delete_memoized(my_view_func) 或 cache.clear()
• Express + memory-cache：需维护 key 映射，导入 SQL 后显式调用 cache.del('api_users')
• 别依赖“重启服务”来清缓存——除非你确认框架没持久化缓存到 Redis 或文件

Redis 缓存未失效是最隐蔽的坑

如果业务用了 Redis 存查询结果（比如 GET users:list），而导入 SQL 后没触发 DEL users:list 或 EXPIRE users:list 0，前端就永远拿不到新数据。这种场景下，数据库和 HTTP 层都干净，问题却卡在中间：

• 检查代码里是否有类似 redis.get('user_profile_' + user_id) 这样的读取，对应写入是否做了 redis.delete(...)
• 用 redis-cli 直连，执行 KEYS *user* 看有没有残留 key，再 GET 一个确认值是否过期
• 批量导入时，用管道（pipeline）+ DEL 比单条 DEL 更快，避免缓存雪崩
• 别把“缓存一致性”当成部署后的一次性任务——它得是数据变更逻辑的一部分

最麻烦的不是找不到缓存位置，而是多个缓存层叠在一起：浏览器 → CDN → Nginx → 应用内存 → Redis。SQL 导入只是起点，每个环节都可能拦下一帧旧数据。动手前先抓包，比翻日志快十倍。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！