PrestaShop 1.7.8.6 getProducts慢查询SQL优化方案咨询

核心结论 #

你提出的按车辆ID单独创建商品分表、直接查分表替代多表JOIN的方案，在你的业务场景下确实能明显提升查询速度，但代价极高，并不是性价比最高的选择。

该分表方案的实际表现 #

优势 #

• 完全消除车辆筛选表与ps_product主表的JOIN开销，查询时直接定位对应车辆ID的单表做过滤，在单车型关联商品量千级以内的场景下，查询耗时可比现有多表JOIN逻辑降低70%以上
• InnoDB引擎下，拆分后的单表数据量远小于200万行的主表，B+树层级更低，索引遍历速度更快，冷查询时的磁盘IO压力会明显下降
• 查询路径和你门店的用户访问路径完全匹配——用户基本都是先选车型再找对应配件，分表查询的缓存命中率会比现有多表关联逻辑高很多

劣势 #

• 数据一致性维护成本极高：商品价格、库存、上下架状态属于高频变更字段，每次更新都要同步修改所有关联该商品的车辆分表。如果单款配件平均适配10款车型，单次商品更新就要执行10次写操作，写性能损耗明显，一旦同步逻辑出问题，很容易出现不同车型页同一款商品信息不一致的问题
• 存储成本大幅上涨：单条商品记录30个字段，按单店覆盖千款常见车型、单车型关联2000款配件估算，分表总存储占用会是原ps_product主表的3-5倍，会拉低InnoDB缓冲池的整体命中率
• 非车型维度查询会退化：全店商品搜索、全局按品牌/价格筛选这类不选车型的场景，没法遍历所有车辆分表取数，只能回退到原主表查询逻辑，等于要长期维护两套查询链路，后续二次开发成本很高

性价比更高的替代优化方案 #

按优先级排序，建议先做前两项优化，90%以上的同类场景都能达到理想加载速度，不需要做全字段分表：

• 先补全覆盖索引：现有JOIN查询慢，大概率是索引设计不合理。给车辆筛选表创建(vehicle_id, product_id)的联合索引，给ps_product表创建(id_product, 商品查询高频返回字段)的联合覆盖索引，确保JOIN过程中直接从索引树拿到所需数据，不需要回表访问主键索引。这个优化没有任何额外维护成本，做完后多数场景查询耗时可以降到毫秒级
• 如果覆盖索引优化后性能仍不达标，不要做全字段冗余分表，改成轻量冗余关联表：表结构只保留vehicle_id、product_id，再加上商品名、价格、库存、默认图、上下架状态这几个查询必需的高频字段（控制在10个字段以内），剩下的低频字段依然通过product_id关联ps_product主表获取。这个方案既可以把JOIN的结果集缩小90%以上，又把冗余字段的同步更新成本降到最低，存储占用只有全字段分表的1/3不到
• 结合本地门店的业务特性，可以把车型和对应商品ID的映射关系提前预热到缓存，用户选完车型直接拿到商品ID集合，再批量从ps_product表取商品数据，完全去掉数据库层的JOIN逻辑。200万商品的ID映射总内存占用不到100M，查询性能比查数据库分表更高

适合用全字段分表的场景 #

只有当你的门店同时满足以下条件时，才建议用你提出的全字段分表方案：

• 覆盖车型极少，仅服务10款以内的固定热门车型
• 单车型关联商品量稳定，不会出现大幅波动
• 商品信息更新频率极低，价格、库存这类信息半个月以上才调整一次，同步成本可以忽略

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