bin/magento indexer:reindex 抛出 No such entity with id = ... 时，真正损坏的往往不是索引表，而是某条关联记录指向了已经不存在的商品、分类、网站或库存实体。若一上来就 truncate 索引表，重建过程仍会读到同一条坏数据，报错不会消失。

先确定是哪一个索引器、哪一种实体

php bin/magento indexer:status
php bin/magento indexer:reindex catalog_product_price -vvv 2>&1 | tee /tmp/price-index.log
tail -n 120 var/log/exception.log
grep -n -B8 -A20 'No such entity' var/log/*.log

不要只记录报错 ID。堆栈里出现 ProductRepository、CategoryRepository、WebsiteRepository 或库存相关类，决定了后面要查哪组表。若全量 reindex 才报错，就逐个执行索引器，直到得到最小失败范围。

示例：价格索引读取到不存在的商品

假设日志明确给出商品 entity_id 2451，先做只读查询：

SELECT entity_id, sku FROM catalog_product_entity WHERE entity_id = 2451;
SELECT * FROM catalog_product_website WHERE product_id = 2451;
SELECT * FROM catalog_category_product WHERE product_id = 2451;
SELECT * FROM catalog_product_relation WHERE child_id = 2451 OR parent_id = 2451;

第一条无结果，而后几条仍有结果，就存在孤儿关联。先完整备份命中记录，不要凭一个 ID 直接删除：

CREATE TABLE repair_20250310_catalog_product_website AS
SELECT * FROM catalog_product_website WHERE product_id = 2451;

CREATE TABLE repair_20250310_catalog_category_product AS
SELECT * FROM catalog_category_product WHERE product_id = 2451;

确认备份表行数与原查询一致后，才在维护窗口删除已经确认无主的关联。若主商品其实存在但 repository 仍找不到，还要检查 store scope、row_id/entity_id 结构以及暂存版本，不能照搬上述删除。

批量找孤儿记录，比逐次追报错更可靠

SELECT cp.product_id, COUNT(*) AS rows_count
FROM catalog_category_product cp
LEFT JOIN catalog_product_entity p ON p.entity_id = cp.product_id
WHERE p.entity_id IS NULL
GROUP BY cp.product_id;

SELECT pw.product_id, pw.website_id
FROM catalog_product_website pw
LEFT JOIN catalog_product_entity p ON p.entity_id = pw.product_id
LEFT JOIN store_website w ON w.website_id = pw.website_id
WHERE p.entity_id IS NULL OR w.website_id IS NULL;

查询结果不应立即等同于可删除数据。先确认是否处于导入、暂存更新或部署中；生产站建议将结果导出并与最近一次商品删除、ERP 同步日志对齐。

修复后按顺序验证

  1. 只重建刚才失败的索引器，避免全量任务掩盖新的错误。
  2. 检查状态是否从 Reindex required 变成 Ready。
  3. 按报错 SKU 访问商品页、分类页并模拟加入购物车。
  4. 观察下一轮 Cron 增量索引是否再次产生异常。
php bin/magento indexer:reset catalog_product_price
php bin/magento indexer:reindex catalog_product_price
php bin/magento indexer:status catalog_product_price

如果报错实体来自分类或网站

堆栈指向 CategoryRepository 时，除了 catalog_category_product，还要检查分类本身是否仍在当前根分类树中；指向 WebsiteRepository 时，检查已经删除的网站是否仍被商品、价格或库存销售渠道引用。下面的查询只用于发现异常关系：

SELECT cp.category_id, COUNT(*) AS rows_count
FROM catalog_category_product cp
LEFT JOIN catalog_category_entity c ON c.entity_id=cp.category_id
WHERE c.entity_id IS NULL
GROUP BY cp.category_id;

SELECT pw.website_id, COUNT(*) AS rows_count
FROM catalog_product_website pw
LEFT JOIN store_website w ON w.website_id=pw.website_id
WHERE w.website_id IS NULL
GROUP BY pw.website_id;

若网站曾被业务迁移工具删除，还要检查 price scope、shared catalog 和 inventory sales channel。删除一张关联表的孤儿行可能只是把异常推迟到下一个索引器。

检查是否由并发导入制造瞬时缺口

如果重试后偶尔成功，比较 reindex 与 ERP/CSV 导入的时间。某些自定义导入先删主实体再重建，索引器恰好在中间读取就会得到 No such entity。修复方向是让导入使用事务或官方保存接口，并将全量重建安排在导入完成后，而不是给索引命令加无限重试。

grep -R 'import|reindex' /var/log/cron* /var/log/syslog 2>/dev/null | tail -n 100
SELECT job_code, status, scheduled_at, executed_at, finished_at
FROM cron_schedule
WHERE job_code LIKE '%index%' OR job_code LIKE '%import%'
ORDER BY schedule_id DESC LIMIT 50;

indexer:reset 只重置状态，不会修复脏数据。若没有找到孤儿关系，却每次在不同 ID 失败，应检查索引期间是否有并发导入或删除任务，并在测试环境复现同一批数据。修复的目标是恢复实体关系的一致性，而不是让命令暂时不报错。