商品筛选慢主因是WHERE条件未走索引；需按最左前缀原则建复合索引，等值字段（category_id、status）前置，范围字段（price）后置，并避免函数索引失效。
商品筛选为什么慢？先看 WHERE 条件有没有走索引
商城里常见的 WHERE category_id = ? AND price BETWEEN ? AND ? AND status = 1 查询，如果只在 category_id 上建了单列索引，price 和 status 字段仍会触发全表扫描。MySQL 的索引最左前缀原则决定了：复合索引 (category_id, status, price) 能覆盖这个查询，但 (category_id, price, status) 就不行——因为 status = 1 是等值条件，必须放在范围条件（如 BETWEEN）左边才能被索引下推。
实操建议：
- 用
EXPLAIN SELECT ...看key和rows，确认是否命中预期索引 - 把高频等值过滤字段（如
category_id、status、is_on_sale）放复合索引前面，范围字段（price、created_at）放后面 - 避免在筛选字段上用函数，比如
WHERE YEAR(created_at) = 2024会让索引失效，改用created_at >= '2024-01-01' AND created_at
多条件动态筛选怎么写 SQL 才不拖垮性能
用户可能只选分类，也可能加价格、品牌、属性组合，后端拼 SQL 容易写出 WHERE 1=1 AND (category_id = ? OR ? IS NULL) AND (brand_id = ? OR ? IS NULL) 这类“万能条件”。这种写法会让优化器放弃使用索引，尤其当参数为 NULL 时，执行计划常退化为全表扫描。
实操建议：
- 服务端按实际传参动态拼接 WHERE 子句，而不是用
OR ? IS NULL做兜底 - 对高频组合筛选（如“手机 + 华为 + 2000~5000元”）可预建冗余字段，比如把关键属性 hash 后存进
filter_code，配合前缀索引加速 - 用
UNION ALL拆分不同筛选路径（如纯分类查 vs 分类+价格查），让每条子查询都能走专用索引
商品属性筛选（如颜色、内存）为什么不能直接 JOIN 多张表
很多商城把 SKU 属性存在 product_attr_value 表，用 EAV 模式存储。一次查“iPhone 15 + 内存=256G + 颜色=黑色”，需要多次 JOIN 或子查询，数据量一上来就卡死。这不是 SQL 写得不好，而是模型本身不适合 OLTP 场景下的快速筛选。
实操建议：
- 避免运行时 JOIN 属性表，改为在商品主表或中间宽表中冗余常用筛选字段，例如
attr_memory、attr_color，并为它们建联合索引 - 如果必须用 EAV，给
product_attr_value(product_id, attr_id, value)建唯一联合索引，并用GROUP BY product_id HAVING COUNT(*) = 3替代多层 EXISTS - 属性值尽量用整型编码（如颜色=1、2、3），别存 “黑色”“Black” 这类字符串，减少索引体积和比较开销
分页深度大了（比如 LIMIT 10000,20）怎么办
用户翻到第 500 页，LIMIT 10000,20 要先扫出 10020 行再丢弃前 10000 行，I/O 和 CPU 开销陡增。这不是加个索引就能解决的，是 MySQL 分页机制本身的瓶颈。
实操建议：
- 用游标分页替代 OFFSET：记录上一页最后一条的
id或create_time，下一页查WHERE id > ? ORDER BY id LIMIT 20 - 对后台管理类场景，限制最大页码（如只允许查前 200 页），前端禁用跳转输入框
- 冷门长尾筛选结果（如“已下架 + 库存
真正卡住商品筛选的，往往不是 SQL 写错了，而是索引没对上查询模式，或者数据模型没对上业务读取路径。特别是属性筛选和深度分页，光调优 SQL 不够，得动表结构甚至加缓存层。这些地方一旦忽略，加再多 CPU 和内存也扛不住流量高峰。
