$args = [ 'post_type' => 'notice', 'posts_per_page' => 20, 'paged' => $paged ]; update_meta_cache( 'post', wp_list_pluck( $q->posts, 'ID' ) );
后台公告列表打开要转十几秒，前台公告归档页滚动明显掉帧，慢查询日志里同一条 SELECT 出现两千多行，单次耗时 4.8 秒。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，查询把 posts_per_page 设成 -1，两千多条公告连同元数据一次取出，内存和渲染都吃不消。列表模板还在循环里调用 get_post_meta，每条再查一次库。
围绕「公告列表查询性能」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。改完隔一天再看一次，当场正常不代表能稳住。
测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
处理上按这个顺序：列表改成分页，每页二十条，翻页走 paged 参数；循环前用 update_meta_cache 预取元数据，别在循环里逐条查；用查询监控插件看页面 SQL 条数，确认降到个位数。
改完只确认一件事：公告列表首屏两秒内打开，页面 SQL 条数从两千多降到十条以内。