织梦数据库查询慢如何优化

织梦站点文章量上来后，最常遇到的性能瓶颈就是 MySQL 查询慢，表现为后台列表翻页卡、前台栏目页打开慢、生成静态页速度骤降。本文从定位、索引、SQL、缓存、配置五个层面给出可落地的优化方案。

一、开启慢查询日志定位元凶

在宝塔 软件商店 - MySQL - 配置修改 的 [mysqld] 段加入：

slow_query_log=ON
slow_query_log_file=/www/server/data/mysql-slow.log
long_query_time=1
log_queries_not_using_indexes=ON

重启 MySQL 后，执行慢查询分析：

mysqldumpslow -s t -t 10 /www/server/data/mysql-slow.log

输出按总耗时排序的 TOP 10 慢 SQL，是优化的起点。

二、补齐织梦常用索引

织梦默认建表索引不完整，数据量大时这些查询会全表扫描。建议补齐：

-- 文档列表按栏目+排序查询
ALTER TABLE dede_archives ADD INDEX idx_typeid_sort (typeid, sortrank DESC);

-- 按发布时间倒序列表
ALTER TABLE dede_archives ADD INDEX idx_pubdate (pubdate DESC);

-- arctiny 轻量列表同样补
ALTER TABLE dede_arctiny ADD INDEX idx_typeid (typeid, id DESC);

-- 标签关联表
ALTER TABLE dede_taglist ADD INDEX idx_tag_aid (tid, aid);

-- 栏目排序
ALTER TABLE dede_arctype ADD INDEX idx_reid_sort (reid, sortrank);

加索引会拖慢写入，建议在低峰期执行，单表数据量很大时用 pt-online-schema-change 在线变更。

三、改写低效 SQL

1. arclist 不要查全表

模板里 {dede:arclist} 不要省略 typeid，否则会扫描全站文档。同时 row 不要设过大：

{dede:arclist typeid='1' row='10' titlelen='40' orderby='pubdate'}
  <li><a href="[field:arcurl/]">[field:title/]</a></li>
{/dede:arclist}

2. 避免子查询

查“某栏目下所有子栏目的文章”时，不要写 WHERE typeid IN (SELECT id FROM dede_arctype WHERE reid=1)，改成先取出 id 列表再 WHERE typeid IN (1,2,3)。

3. 用 arctiny 代替 archives

列表页只需要 id、typeid、pubdate、title 这些字段时，查 dede_arctiny 比 dede_archives 快几倍，因为字段少、行宽小。

四、开启 MySQL 查询缓存

注意 MySQL 8.0 已移除 Query Cache，仅 5.7 及以下可用：

query_cache_type=ON
query_cache_size=64M
query_cache_limit=2M

对写入频繁的站点查询缓存命中率低，反而成负担，可关闭并改用应用层缓存。

五、织梦自身缓存

后台 系统 - 系统基本参数 - 性能选项：

开启“模板缓存”，缓存时间 3600 秒；
开启“栏目缓存”；
开启“arclist 缓存”，缓存时间 1800 秒。

对首页与频道页这种高频访问、低频更新的页面效果显著。

六、MySQL 配置调优

[mysqld]
innodb_buffer_pool_size=1G        # 服务器内存 50%~70%
innodb_log_file_size=256M
innodb_flush_log_at_trx_commit=2  # 性能与安全折中
innodb_buffer_pool_instances=4
key_buffer_size=64M               # MyISAM 用，织梦多为 InnoDB 可调小
max_connections=200
table_open_cache=512
sort_buffer_size=2M

调整后用 mysqltuner 脚本检测配置是否合理。

七、表维护与归档

定期执行：

mysqlcheck -o --all-databases   # 优化所有表
OPTIMIZE TABLE dede_archives;
ANALYZE TABLE dede_archives;

历史文章超过 10 万时，建议把三年前的文章归档到 dede_archives_history 表，主表保持精简。

八、注意事项

加索引前先用 EXPLAIN 验证执行计划，避免无效索引；
批量 UPDATE/DELETE 要分批，单次操作不要超过 1 万行；
云数据库 RDS 可直接开启“性能洞察”定位慢 SQL，比慢日志更直观；
升级到 MySQL 8.0 前确认织梦版本兼容性，旧版织梦 SQL 写法可能不兼容。

数据库优化不是一次性的工作，建议把“慢日志周报 + 索引体检 + 配置随内存调整”纳入日常运维节奏。当主表行数稳定在合理区间、慢查询数量趋近于零时，再考虑读写分离或换用更高配置的实例，避免过早投入硬件成本。