PostgreSQL大表查询优化：品牌产品高效查询及动态视图实现

一、基础SELECT vs 索引、视图的性能对比 #

1. 基础SELECT的局限性
   你当前用的SELECT ... WHERE brand = "ABC"，如果brand字段未建索引，数据库会执行全表扫描——把10万条记录逐一排查匹配项。单查一次可能耗时不长，但品牌页面访问量高、并发上来后，全表扫描会持续占用数据库资源，导致性能下降。

2. 索引是性能提升的核心方案
   给brand字段创建普通索引，是最直接有效的优化手段：

CREATE INDEX idx_products_brand ON products(brand);

建索引后，数据库会通过索引快速定位所有brand="ABC"的记录，无需扫全表，查询速度能提升数倍，并发场景下效果更显著。
如果你的查询还需要按created_at排序（如示例中的ORDER BY），可以创建复合索引进一步优化：

CREATE INDEX idx_products_brand_created ON products(brand, created_at DESC);

这样连排序的开销都能省去，性能更优。

3. 普通视图不具备性能优化能力
   你示例中的CREATE VIEW属于普通视图，它本质只是存储了一条查询语句，每次调用视图时，数据库仍会执行底层的SELECT逻辑，不会提前缓存结果。所以单纯创建普通视图无法提升性能，最多只是简化查询写法。
   部分数据库（如PostgreSQL、Oracle）支持物化视图，它会将查询结果提前存储在磁盘上，相当于缓存，但需要定期刷新才能保证数据最新，仅适合数据更新不频繁的场景。如果你的产品数据更新频繁，物化视图可能导致数据不一致，需谨慎使用。

二、关于动态视图的实现 #

你示例里的WHERE brand = %ABC%写法有误，正确模糊匹配应为LIKE '%ABC%'，但核心需求是实现可动态切换品牌的视图——普通视图无法接收参数，没法直接实现这种动态效果，可采用以下替代方案：

1. 应用层拼接参数化SQL
   在代码中接收品牌参数，通过参数化查询拼接SQL（必须用参数绑定，防止SQL注入），比如Java用PreparedStatement、Python用SQLAlchemy参数绑定，这是最常用的实现方式。

2. 存储过程
   用数据库存储过程接收品牌参数，返回对应结果。以MySQL为例：

DELIMITER //
CREATE PROCEDURE get_brand_products(IN p_brand VARCHAR(100))
BEGIN
    SELECT id, image, title, price, brand, created_at
    FROM products
    WHERE brand = p_brand
    ORDER BY created_at DESC;
END //
DELIMITER ;

调用时执行CALL get_brand_products('ABC');即可。

3. 带参数的函数（部分数据库支持）
   比如PostgreSQL可编写返回结果集的函数：

CREATE OR REPLACE FUNCTION get_brand_products(p_brand VARCHAR)
RETURNS SETOF products AS $$
BEGIN
    RETURN QUERY
    SELECT id, image, title, price, brand, created_at
    FROM products
    WHERE brand = p_brand
    ORDER BY created_at DESC;
END;
$$ LANGUAGE plpgsql;

调用时执行SELECT * FROM get_brand_products('ABC');。

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