Marico's space

最近给一个朋友的公司做Magento 2（电商建站系统）性能优化，他们仓库里堆了35万个SKU（库存量单位）。一开始我还挺乐观，毕竟之前处理过几万产品的项目，感觉这套系统应该能hold住。结果一跑起来，分类页面加载要8秒，分层导航直接超时，后台管理员打开产品列表等得能泡杯茶——这才意识到10万产品以上的规模和几万完全不是一个游戏。 好消息是Magento 2确实能扛住这种量级，只是得知道往哪儿使劲。这篇把我踩过的坑和实际验证过的优化方案捋一遍，不整虚的。

EAV瓶颈：你遇到的第一个坎

Magento 2用的EAV（实体-属性-值）数据模型，灵活性是好，但规模大了就是噩梦。每个产品页加载可能触发几十次JOIN查询，查的还是catalog_product_entity_*这些表。1万个产品的时候这都不是事，到20万，产品一多数据库直接被拖死。

怎么办：

先梳理一下哪些属性是真正需要搜索、过滤、或者在产品列表里显示的。每一个被标记为"可过滤"或"用于产品列表"的属性，都在给EAV查询加负担。大型目录里，只启用用户真正会用到的属性。

其次，用catalog_product_flat平展表——但要谨慎。平展表把EAV数据反向规范化成一行一个产品，分类和列表查询能快不少。不过代价也明显：重建索引时间更长、占用空间更大、多店铺场景下更复杂。超过50万产品的目录，平展表可能帮倒忙——一定要做压力测试。

第三，考虑把属性密集型查询搬到Elasticsearch或OpenSearch。搜索引擎处理分面导航的效率比MySQL的EAV查询高出一大截。这是大型目录性能提升最明显的一招。

分类树导航：大目录下的坎

分类页通常是一个Magento商城里访问量最高的页面。目录一大，渲染包含数千产品、层级又深的分类树，成本很高。

关键优化点：

• 控制分类层级深度。层级嵌套太深（5层以上）的分类会触发递归查询，根本没法scale。有条件的话尽量把树拍平。
• 把整页缓存用到位。分类页默认是可以缓存的。确保TTL设置合理，缓存预热要覆盖访问量最高的100-200个分类。
• 锚点分类开销大。锚点分类会继承所有子分类的产品。目录一大，靠近根节点的锚点分类可能涵盖80%的产品。锚点用得越少越好。
• 考虑分页大小。每页24个产品意味着更多的页面加载和更多的数据库查询。B2B场景下，每页48-96个反而能减轻服务器压力。别给"显示全部"选项，那真的会崩。

分层导航：性能杀手本杀

分层导航（分类页上可过滤的属性）在大目录里经常是头号性能问题。Magento默认实现去查EAV索引表，20万产品以上能慢到离谱。

按效果排序的解决方案：

1. 上Elasticsearch/OpenSearch——搜索引擎原生支持聚合查询，速度快。大型目录这是必须的。
2. 不需要在分类页显示的属性，把"用于搜索结果分层导航"开启就行，别开"用于分层导航"。
3. 限制可过滤属性数量。10-15个足够了。每多一个属性就多一条聚合查询。
4. 价格区间特别耗资源。动态价格区间计算要扫描整个价格索引。考虑改成固定价格区间。
5. 给分层导航状态加缓存，用独立的Redis缓存来存目录层数据。

价格计算和阶梯价

大规模下的价格计算涉及：

• 原价、促销价、阶梯价、目录规则、客户组价格、税费规则
• 要在可能数十万产品上全部算一遍
• 通常在索引操作时进行，但有时也会实时计算

大目录的处理方式：

• 避免复杂的目录价格规则。每条规则在索引时都要过一遍所有适用产品。一条"买X送Y"带条件的规则能把索引时间拉长三倍。
• 能用阶梯价和客户组价格就别用目录规则。前者在产品级别计算，不走规则逻辑，效率高得多。
• catalog_product_price索引器用"按计划更新"模式，绝对别用"保存时更新"——而且要监控它的运行时间。
• 复杂目录可以考虑分拆：基础价格正常索引，动态定价走定制模块或PPC（按价格缓存）扩展。

大型目录的索引策略

这是大多数大型目录Magento站点的通病。默认索引器设置压根没考虑规模。

核心原则：

• 所有索引器都设成"按计划更新"——50万产品以上的目录千万别用"保存时更新"。
• 错开索引器运行时间。别同时跑所有索引器。搞个cron排程，让它们按顺序执行。
• 监控索引表大小。catalog_product_index_price和catalogrule_product这些表，行数跟 产品数×客户组数×网站数 成正比。20万产品×5个网站×10个客户组，那就是1000万行。
• 用--batch-size参数控制内存。默认批次是1000，太大的目录设成500比较稳，能避免内存峰值。
• 尽量用增量索引。有些索引器支持基于变更日志表的局部重建。

搜索引擎扩容

大型Magento目录必须上Elasticsearch或OpenSearch。但搜索引擎本身也得调优。

大规模搜索的tips：

• 给堆内存留够。50万产品、30个属性建索引，至少需要8GB-16GB的JVM堆。千万别用默认配置。
• 优化mapping。只索引真正用于搜索、过滤、排序的属性。每个多索引的属性都会增加索引体积和查询时间。
• 分片策略要合理。单个Magento站3-5个分片就够了。分片太多会碎化索引，反而拖累性能。
• 刷新间隔有讲究。ES默认1秒刷新间隔意味着持续写入。Magento场景下30-60秒足够，还能降低I/O压力。
• 产品数超过100万的目录考虑独立搜索集群。ES和MySQL、PHP共跑一台机器，资源争抢是迟早的事。

数据库层面优化

MySQL配置在大规模场景下必须调整：

• 把innodb_buffer_pool_size调到可用内存的70-80%。50万产品的复杂EAV目录，工作集轻松到8-16GB。
• 开启innodb_parallel_read_threads（MySQL 8+），并行执行EAV JOIN查询。这一项单独就能把分类页加载时间砍掉30-40%。
• 对大表做分区。catalog_product_index_price和catalogrule_product按网站或客户组分表是很好的候选。
• 关注慢查询。Magento在大规模下会产生一些天生就慢的查询。用MySQL慢查询日志捞出来，考虑用插件重写。
• 连接池变得关键。200个以上并发后台+前台用户时，Magento默认的连接处理会产生太多连接。用ProxySQL之类的连接池，或者PHP-FPM的持久连接。

后台管理面板性能

大目录不只是坑用户，运营团队也遭罪。20万产品的后台产品表格根本没法用。

后台专项优化：

• 限制后台产品表格——默认别显示全部产品。分页默认设成20，表格里禁用"显示全部"。
• 批量操作走后台_massaction，别在产品表格里逐条改。表格直接编辑每次触发单独的AJAX保存请求。
• 给后台角色分配范围受限的目录访问权限——如果团队只管一部分产品，就给他们对应的过滤访问。
• 产品数实在太大的可以考虑无头后台或者接个专门的PIM（产品信息管理）系统。

实际跑出来的数据

这是调优后一个35万SKU的Magento 2站跑出的结果：

关键不是某一项单独优化，而是ES驱动的导航、顺序执行的索引器、数据库调优、再加上激进的缓存策略组合在一起，才有这个效果。

总结清单

☐ 所有分层导航迁移到Elasticsearch/OpenSearch
☐ 所有索引器设为"按计划更新"
☐ 索引器cron任务错开执行
☐ MySQL缓冲池调到内存的70-80%
☐ 可过滤属性控制在10-15个
☐ 避免复杂的目录价格规则
☐ 用阶梯价和客户组价格替代
☐ 分类层级控制在3-4层以内
☐ 给搜索引擎留足堆内存
☐ ES/OpenSearch刷新间隔调到30-60秒
☐ 在你的实际规模下测试平展表vs EAV
☐ 每天监控索引器运行时间
☐ 限制后台表格默认显示数量

大目录性能优化没有银弹，是一整套策略。先从搜索引擎迁移入手，再逐层搞索引器和数据库。每个优化点相互叠加，等你回过神来，可能发现那个35万的目录跑得比隔壁5万的还快。