看来你在键值对结构的大数据量查询上遇到了性能瓶颈，结合你的场景——要快速找出特定公司下满足任意一种或多种数值筛选条件的用户，百万级数据量，现有索引组合没解决问题——我整理了几个实战中验证过的优化方案，你可以根据业务情况选择：

1. 把高频属性抽出来做宽表（垂直拆分） #

如果业务里常用的筛选属性（比如年龄、薪资）其实是相对固定的，没必要全塞在键值对表里。你可以把这些高频属性直接加到用户主表做成宽表，剩下的低频、偶发属性留在键值对表。

比如用户主表加age、salary列，查询特定公司+年龄范围时，直接走company_id + age的复合索引，速度会快一大截；如果涉及低频属性，再关联键值对表做二次过滤。这种方式兼顾了灵活性和查询性能。

2. 用数据库的JSON/结构化类型存属性 #

现在主流数据库都支持JSON类型的索引，比如PostgreSQL的JSONB、MySQL的JSON。你可以把用户的所有数值属性存在一个JSON字段里，比如user_attrs，然后给常用的属性键单独建索引。

举个PostgreSQL的例子，给年龄建索引：

CREATE INDEX idx_user_attr_age ON users ((user_attrs->>'age')::int);

查询的时候直接写：

SELECT user_id FROM users 
WHERE company_id = 'xxx' 
AND ( (user_attrs->>'age')::int BETWEEN 20 AND 30 
      OR (user_attrs->>'salary')::numeric > 10000 );

这种方式既保留了键值对的灵活性，又能给常用属性建立针对性索引，比纯键值对表的关联查询高效得多。

3. 预计算高频筛选组合的物化视图 #

如果你的筛选组合有复用性（比如经常查“公司A+20-30岁”、“公司B+薪资>10k”），可以用物化视图提前把符合条件的user_id算好存起来，查询时直接取，定期刷新就行。

比如创建一个针对公司A年龄20-30的物化视图：

CREATE MATERIALIZED VIEW mv_company_a_age_20_30 AS
SELECT user_id FROM key_value_table 
WHERE filter = 'age' AND value::int BETWEEN 20 AND 30 
AND user_id IN (SELECT user_id FROM users WHERE company_id = 'A');

别忘了给物化视图加索引：

CREATE UNIQUE INDEX idx_mv_company_a_age ON mv_company_a_age_20_30 (user_id);

这种方式能把查询耗时直接降到毫秒级，适合查询模式相对固定的场景。

4. 换用列式数据库/OLAP引擎 #

如果你的查询是分析型的（不是实时交易），经常要组合多个数值条件筛选，传统行式数据库可能扛不住。可以把数据同步到ClickHouse、Vertica这类列式数据库，它们对多条件筛选的性能天生就好，百万级数据的复杂查询基本能在几秒内搞定。

比如在ClickHouse里，你可以把键值对转成宽表，或者用Map类型存属性，直接执行多条件查询，性能比传统数据库提升N倍。

5. 纯键值对表的最后优化技巧 #

如果一定要保留纯键值对结构，试试这几个索引调整：

• 建(company_id, filter, value, user_id)的复合索引：把company_id放最前面（因为你每次都先限定公司），然后是filter（属性类型），接着是value，最后把user_id作为包含列，避免回表查原数据。
• 避免OR的坑：多个OR条件的查询，拆成子查询用UNION去重，往往比直接写OR高效。比如：

SELECT user_id FROM key_value_table 
WHERE company_id = 'xxx' AND filter = 'age' AND value::int BETWEEN 20 AND 30
UNION
SELECT user_id FROM key_value_table 
WHERE company_id = 'xxx' AND filter = 'salary' AND value::numeric > 10000;

每个子查询都能用到复合索引，UNION自动去重，执行计划会更高效。

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