针对你遇到的Left Join后关联表字段排序性能问题，我有几个比反规范化（denormalization）更优的方案，既可以提升查询性能，又能避免数据冗余带来的维护成本：

1. 延迟关联+覆盖索引组合 #

核心思路是先排序主键再关联取数，减少排序阶段处理的数据量，同时利用覆盖索引避免回表查询。

首先给products表创建覆盖索引，包含排序字段和关联主键：

CREATE INDEX idx_products_name_id ON products (name, id);

然后给inventory_items表创建联合索引，覆盖过滤条件和关联字段：

CREATE INDEX idx_inv_vendor_product ON inventory_items (vendor_id, product_id);

接下来改写查询，先通过子查询获取排序后的inventory_items主键，再关联两张表取完整字段：

SELECT ii.*, p.*
FROM (
    SELECT ii.id, COALESCE(p.name, '') AS sort_key
    FROM inventory_items ii
    LEFT JOIN products p ON ii.product_id = p.id
    WHERE ii.vendor_id = 123
    ORDER BY sort_key
    LIMIT 100
) AS sorted_ids
JOIN inventory_items ii ON sorted_ids.id = ii.id
LEFT JOIN products p ON ii.product_id = p.id;

这个写法让数据库只需要排序100条主键数据，而不是原始的5万行，同时覆盖索引可以让products表的排序直接走索引，无需回表读取额外字段。

2. 拆分查询+Union ALL处理边界情况 #

考虑到Left Join存在product_id为NULL的记录（这类记录排序时会统一排在最前/最后），可以将查询拆分为两部分，分别处理无关联产品和有关联产品的记录，减少排序的数据量：

-- 先获取无关联产品的记录（如果数量超过100则直接返回）
SELECT ii.*, p.*
FROM inventory_items ii
LEFT JOIN products p ON ii.product_id = p.id
WHERE ii.vendor_id = 123 AND ii.product_id IS NULL
UNION ALL
-- 再获取有关联产品的记录，按name排序取剩余数量
SELECT ii.*, p.*
FROM inventory_items ii
JOIN products p ON ii.product_id = p.id
WHERE ii.vendor_id = 123
ORDER BY p.name
LIMIT GREATEST(100 - (
    SELECT COUNT(*) FROM inventory_items ii 
    WHERE ii.vendor_id=123 AND ii.product_id IS NULL
), 0)
-- 最后统一排序取前100
ORDER BY COALESCE(p.name, '')
LIMIT 100;

如果无关联产品的记录很少，第二部分只需要排序少量数据；如果这类记录超过100条，第一部分直接返回结果，无需排序。

3. 物化视图（Materialized View） #

如果你的数据库支持物化视图（如PostgreSQL、Oracle、MySQL 8.0.19+），这是平衡性能和数据一致性的绝佳方案。你可以创建一个包含所有需要排序、筛选字段的物化视图，然后在视图上创建针对性索引：

创建物化视图： #

CREATE MATERIALIZED VIEW mv_inv_product AS
SELECT 
    ii.id, ii.vendor_id, ii.product_id,
    p.name AS product_name, p.price AS product_price,
    -- 加入所有需要排序/筛选的字段
    ii.stock_quantity
FROM inventory_items ii
LEFT JOIN products p ON ii.product_id = p.id;

创建索引： #

-- 针对vendor_id+product_name排序的索引
CREATE INDEX idx_mv_vendor_name ON mv_inv_product (vendor_id, product_name);
-- 其他需要排序字段的索引（如价格）
CREATE INDEX idx_mv_vendor_price ON mv_inv_product (vendor_id, product_price);

查询时直接使用物化视图： #

SELECT * FROM mv_inv_product WHERE vendor_id=123 ORDER BY product_name LIMIT 100;

物化视图可以定期刷新（比如每天凌晨），或者在原表数据变更时自动刷新（如PostgreSQL的REFRESH MATERIALIZED VIEW CONCURRENTLY），既避免了反规范化的数据冗余，又能利用索引快速排序和筛选。

4. 引导优化器选择更优执行计划 #

如果上述方案都不适用，可以尝试调整查询写法，引导数据库优化器利用现有索引：

SELECT ii.*, p.*
FROM products p
RIGHT JOIN inventory_items ii ON p.id = ii.product_id
WHERE ii.vendor_id = 123
ORDER BY p.name NULLS FIRST
LIMIT 100;

结合products的(name, id)覆盖索引和inventory_items的(vendor_id, product_id)索引，优化器可能会先按name排序products表，再关联符合vendor_id=123的inventory_items记录，直到凑够100条，避免全量排序。

这些方案各有适用场景：如果需要实时数据，优先选择延迟关联或索引优化；如果对数据实时性要求不高，物化视图是最省心的方案。

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