TYPO3 7.6保存新闻记录超时、内容不全等异常的原因是什么？

核心原因定位 #

该故障表现为后台（BE）操作缓慢、保存超时，前台（FE）运行正常，基本可排除前端缓存、站点整体资源不足的问题，大概率为后台写入相关逻辑、数据库表或扩展兼容问题导致，常见诱因如下：

• 后台日志表sys_log、sys_history积累了海量历史记录，写入操作因锁表等待耗时过长
• 保存新闻时触发的实时引用索引（refindex）全量更新逻辑，关联数据量大的情况下会严重阻塞操作
• ext:news扩展版本过旧，存在标签关联MM表重复写入、重复查询的性能bug
• RTE编辑器开启了实时链接校验，保存时遍历校验所有内容内的链接导致超时
• 新闻、标签关联的业务表缺失索引或存在大量碎片，写入查询性能低下

排查步骤 #

1. 开启TYPO3慢查询日志：进入安装工具的All Configuration页面，配置$GLOBALS['TYPO3_CONF_VARS']['DB']['slowQueryLog'] = 1，设置慢查询阈值为1秒，复现新闻保存操作，定位耗时最长的SQL语句
2. 检查后台日志表数据量：执行SQL命令查询记录数

SELECT COUNT(*) FROM sys_log;
SELECT COUNT(*) FROM sys_history;

若记录数超过10万即可判定为日志表过大导致的写入性能问题
3. 验证引用索引影响：临时在AdditionalConfiguration.php中添加$GLOBALS['TYPO3_CONF_VARS']['SYS']['enable_refindex'] = false;，测试保存速度是否恢复，若恢复即可判定为实时refindex更新导致的故障
4. 检查新闻标签关联表：查询tx_news_domain_model_news_tag_mm表的记录数，对比实际新闻、标签关联的预期数量，排查是否存在重复冗余数据

修复方案 #

• 日志表过大修复：清理3个月以上的历史日志，再做表碎片整理

DELETE FROM sys_log WHERE tstamp < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 3 MONTH));
DELETE FROM sys_history WHERE tstamp < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 3 MONTH));
OPTIMIZE TABLE sys_log, sys_history;

同时调整后台日志保留周期，避免后续日志过度积累

• 引用索引更新优化：关闭保存时的实时refindex更新，改为每日定时离线更新。在AdditionalConfiguration.php中添加配置：

$GLOBALS['TYPO3_CONF_VARS']['SYS']['enable_refindex'] = false;

每日执行CLI命令更新引用索引：
php typo3/cli_dispatch.phpsh lowlevel_refindex -e

• 扩展兼容优化：将ext:news升级到适配TYPO3 7.6的最新兼容版本（3.2.x系列），修复旧版本标签关联的性能bug，清理MM表中的重复冗余记录
• 链接校验关闭：在linkvalidator扩展配置中关闭checkOnSave选项，取消保存时的实时链接校验
• 数据库优化：给新闻相关业务表添加缺失索引，定期做表碎片整理，调整数据库innodb_buffer_pool_size配置提升写入性能

内容的提问来源于stack exchange，提问作者luca