独立站数据库优化：查询慢日志、索引、表结构的性能调优

独立站数据库优化：查询慢日志、索引、表结构的性能调优

一、WordPress数据库为什么会慢

WordPress用MySQL做数据库，默认表结构跑小站没问题，但内容多了之后会越来越慢。慢的根源不在服务器配置，而在两个设计问题：wp_postmeta表把所有自定义字段存在一张键值表里，查一个产品的参数要做多次JOIN；wp_options表把所有配置项混在一起，每次后台加载都要扫全表。

一个WordPress页面平均要查12至20次数据库，其中大部分是查wp_postmeta。当你装了10个插件，每个插件都往wp_postmeta写自定义字段，这张表可能膨胀到几十万行。这时候随便一个带meta_query的页面请求，就要在几十万行里扫，慢查询自然就来了。

数据库慢了之后，页面缓存能掩盖一部分——页面缓存命中时根本不查数据库。但缓存miss的时候（刚发布文章、访问未缓存页面），慢查询就暴露出来了。所以数据库优化和缓存策略要配合看，见独立站三层缓存策略。如果数据库已经慢到影响Core Web Vitals，优化优先级见Core Web Vitals优化。

二、慢查询日志：怎么找到慢的SQL

优化数据库的第一步不是加索引，而是找到到底哪条SQL慢。靠肉眼猜是猜不出来的——你以为是某条查询慢，实际可能是另一条。MySQL自带慢查询日志，打开之后会把超过阈值的SQL全部记录下来。

在MySQL配置里（my.cnf或my.ini）加三行：slow_query_log=1、long_query_time=1、slow_query_log_file=/var/log/mysql/slow.log。意思是：开启慢日志，超过1秒的查询记录下来，日志写到指定文件。跑一天之后，用mysqldumpslow或pt-query-digest工具把日志按查询类型聚合，找出TOP 10最慢的SQL。

场景示例：你发现产品筛选页特别慢，打开慢日志一看，TOP 1慢查询是一条带meta_query的SQL，查wp_postmeta表的某个自定义字段。用EXPLAIN分析，type列显示ALL（全表扫描），rows列显示扫描了12万行——这条SQL每次都把wp_postmeta表扫一遍。这时候你就知道要给meta_key字段加索引了，而不是去升级服务器。

慢查询日志不要长期开着，它本身有IO开销。跑一天收集完数据就关掉，或者把阈值调到2秒只记录最慢的。日常监控用数据库性能监控工具（如Prometheus+Grafana），见站点监控与告警清单。

三、索引优化：哪些字段该加索引

EXPLAIN结果里最关键的两列是type和rows。type列如果显示ALL，说明这条查询在全表扫描，必须加索引；如果显示ref或eq_ref，说明已经走了索引，不用动。rows列显示MySQL预估要扫描多少行，数字越大越危险——扫描1万行以内还行，扫描10万行以上就该优化了。

WordPress数据库里最值得加索引的是wp_postmeta表。这张表默认只有post_id一个索引，但实际查询经常按meta_key和meta_value过滤。加一个(meta_key, meta_value)复合索引，按自定义字段筛选的查询能快10倍以上。注意是复合索引，不是单独给meta_key加索引——单独加meta_key，查询里带meta_value过滤时还是要回表。

反直觉判断：很多人看到慢查询就立刻加索引，但索引不是免费的。每个索引都占磁盘空间，而且每次INSERT或UPDATE时，MySQL要同时更新所有索引。wp_options这种写多读少的表（后台每次保存配置都写），乱加索引反而会让写入变慢。正确做法是：读多写少的表（wp_postmeta、wp_posts）大胆加索引；写多读少的表（wp_options、wp_comments）谨慎加，能不加就不加。

加索引之前一定要先在staging环境测试。直接在生产库ALTER TABLE加索引，大表可能锁表几分钟，网站直接502。生产环境加索引用pt-online-schema-change或gh-ost这类在线DDL工具，不锁表。环形山在出海站数据库上的维护经验见环形山技术栈与四个自研插件。

四、表结构优化：wp_postmeta和wp_options的坑

有些问题靠加索引解决不了，必须改表结构。wp_postmeta的键值设计就是这类问题——它把所有自定义字段存在一张表里，查一个产品的规格参数要JOIN好几次。当产品数量到几千个、自定义字段到几十个时，这张表会膨胀到几十万行，索引优化的收益见顶。

这时候有两个方向：一是用自定义表替代postmeta，把高频查询的自定义字段单独建表，按字段类型存，查询时直接查对应表；二是用WordPress的wp_options autoload机制，把读多写少的配置项设为自动加载，避免每次都查options表。对B2B独立站来说，方向一适合产品参数复杂的站，方向二适合插件装得多的站。

场景示例：一个工业装备官网有50个产品，每个产品有20个自定义参数（材质、功率、尺寸、精度等）。这些参数全部存在wp_postmeta里，查一个产品详情页就要JOIN wp_postmeta 20次。正确做法是建一张wp_product_specs自定义表，把20个参数作为列存在一行里，查产品参数就是一次SELECT，不用JOIN。这样做开发量不大，但性能提升是数量级的。

表结构变更前必须备份数据库。备份和恢复演练见网站备份与恢复演练。如果数据库已经被黑过，清理和加固流程见网站被黑之后的处理。

五、优化后的验证与维护

加了索引或改了表结构之后，不能直接算完。必须做三件事：第一，用EXPLAIN重新跑一遍优化前的慢SQL，确认type列从ALL变成ref或eq_ref；第二，对比优化前后的实际耗时，确认慢查询真的变快了；第三，观察一周看慢查询日志里有没有新的慢查询出现——优化经常会把瓶颈从一个地方挪到另一个地方。

数据库优化不是一次性工作。内容增长、插件更新、主题改版都会引入新的慢查询。建议每月做一次慢查询日志分析，看TOP 10有没有变化。日常维护里数据库优化是固定项，见官网维护期每月六件事。独立站技术栈的整体选型框架见环形山技术栈，PHP版本升级和数据库配置的配合见官网维护指南。

FAQ 常见问题

写在最后

数据库优化这件事，最容易走的弯路是一慢就升级服务器。从1核2G升到4核8G，花了双倍钱，结果慢查询还是慢——因为瓶颈不在CPU，在没走索引的全表扫描。正确的顺序永远是：先开慢日志找到具体哪条SQL慢，再用EXPLAIN看执行计划，最后才决定加索引还是改表结构。

落地三步：第一步，开慢查询日志跑一天，用mysqldumpslow找出TOP 10；第二步，逐条EXPLAIN，type=ALL的加索引，wp_postmeta优先加(meta_key,meta_value)复合索引；第三步，优化后复测，确认慢SQL从1秒降到100毫秒以内。这三步做完，你会发现服务器配置一点没变，但页面速度快了好几倍。

一句可以记住的话：数据库慢了先找慢日志，别先升服务器——80%的慢查询是没走索引的全表扫描，加对一个索引比升一档配置管用。