商品筛选为什么慢？先看 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 和内存也扛不住流量高峰。
