SQLite在使用WHERE子句或条件时花费太多时间

SQLite在使用WHERE子句或条件时花费太多时间,sqlite,select,where-clause,Sqlite,Select,Where Clause,我有一个SQLite数据库(表),有1亿行 SELECT * FROM users WHERE u_status = 1 AND u_country = 'US' ORDER BY u_score DESC LIMIT 10 OFFSET 100000; SELECT * FROM users WHERE u_status = 1 AND u_country = 'IN' ORDER BY u_score DESC LIMIT 10 OFFSET 100000; 表架构: CREATE TA

我有一个SQLite数据库(表),有1亿行

SELECT * FROM users WHERE u_status = 1 AND u_country = 'US' ORDER BY u_score DESC LIMIT 10 OFFSET 100000;

SELECT * FROM users WHERE u_status = 1 AND u_country = 'IN' ORDER BY u_score DESC LIMIT 10 OFFSET 100000;
表架构:

CREATE TABLE users
(
    u_id      VARCHAR(32) PRIMARY KEY,
    u_status  BOOLEAN,
    u_country VARCHAR(2),
    u_score   INT
);

CREATE INDEX dex_sta ON users (u_status);
CREATE INDEX dex_cou ON users (u_country);
CREATE INDEX dex_sco ON users (u_score);

CREATE INDEX dex_sns ON users (u_status, u_score);
CREATE INDEX dex_mul ON users (u_status, u_country, u_score);
当我在不选择多个国家的情况下使用下面这些简单的查询时,我在15毫秒内得到了响应

SELECT * FROM users WHERE u_status = 1 AND u_country = 'US' ORDER BY u_score DESC LIMIT 10 OFFSET 100000;

SELECT * FROM users WHERE u_status = 1 AND u_country = 'IN' ORDER BY u_score DESC LIMIT 10 OFFSET 100000;
问题从下面的查询开始 当我尝试用条件匹配多个国家时,查询需要60秒才能响应

SELECT * FROM users WHERE u_status = 1 AND (u_country = 'US' OR u_country = 'IN') ORDER BY u_score DESC LIMIT 10 OFFSET 100000;
查询改进1: 当我通过(INDEX BY)强制查询使用特定索引时,它在1秒内做出响应

SELECT * FROM users INDEXED BY dex_mul WHERE u_status = 1 AND (u_country = 'US' OR u_country = 'IN') ORDER BY u_score DESC LIMIT 10 OFFSET 100000;
查询改进2: 当我使用UNION ALL查询时,需要500毫秒才能响应

SELECT * FROM users WHERE u_status = 1 AND u_country = 'US'
UNION ALL
SELECT * FROM users WHERE u_status = 1 AND u_country = 'IN'
ORDER BY u_score DESC LIMIT 10 OFFSET 100000;

是否有可能在<50 ms中获得响应,就像第一个匹配多个国家/地区的查询一样?

使用查询中的
条件不允许使用索引。您可以将查询转换为
UNION ALL
子句-

SELECT *
FROM users
WHERE u_status = 1 AND u_country = 'US'
UNION ALL
SELECT *
FROM users
WHERE u_status = 1 AND u_country = 'IN'
ORDER BY u_score DESC LIMIT 10 OFFSET 100000;

这可能会解决您的问题。

请发布查询的解释计划。
限制10个偏移量100000
所以,这就像从整个数据集中最大的
100000个
元素开始?你的
dex\u mul
索引使得
dex\u sta
毫无用处,顺便说一句,因为后者是前者的前缀。有关详细信息,请参阅。(在这些查询中也不太可能使用
dex\u cou
dex\u sco
的方法;不过,请用
解释查询计划
确认)您还应尽量避免较大的
偏移量
。根据您正在做的事情,查看讨论和备选方案。最后,如果您还没有这样做,在桌面上运行可能会有所帮助。至少查询计划器能够更好地决定使用哪一个索引。