otimização de consultas SQLite (subconsulta e juntar-se)

Question

Eu tenho uma tabela para um projeto de Estatística.

A estrutura é assim:

CREATE TABLE NewStatHistory (
    StatHistoryID uniqueidentifier PRIMARY KEY NOT NULL,
    DateEntered dateTime NOT NULL,
    DateApplies dateTime NOT NULL,
    WhoEnteredID uniqueIdentifier NOT NULL,
    PostingID uniqueIdentifier NULL,
    EnteredValue decimal(19,5) NOT NULL,
    StatID uniqueIdentifier NOT NULL,
    StatStatus int NOT NULL,
    Notes varchar(500) NULL,
    CampusID uniqueidentifier NOT NULL,
    IsTarget bit NOT NULL DEFAULT 0
)

Eu preciso puxar o valor mais recentemente introduzido para cada "DateApplies".

Esta consulta é executada quase que instantaneamente em SqlServer mas em SQLite ele apenas vezes fora e eu não consigo descobrir como otimizar para obtê-lo para o trabalho.

SELECT NewStatHistory.* 
FROM NewStatHistory
INNER JOIN (
  SELECT MAX(DateEntered) entered, statID, DateApplies
  FROM NewStatHistory
  WHERE StatID = @statID 
    AND campusID = @campusID
    AND IsTarget = 0
  GROUP BY DateApplies, statID
) summary 
ON summary.entered = newstathistory.dateEntered AND
  summary.statID = newStatHistory.statID AND 
  summary.DateApplies = newStatHistory.DateApplies
WHERE NewStatHistory.StatID = @statID AND
  IsTarget = 0 AND
  campusID = @campusID
ORDER BY NewStatHistory.DateApplies DESC

Alguém tem alguma idéia sobre como fazê-lo funcionar. Caso contrário, eu vou ter que encontrar outro db incorporado para usar. Outros que esta consulta, SQLite tem feito tudo o que pedi dela.

Quanto índices ir, em SQLServer, eu só tenho a chave primária indexado. No SQLite, eu tentei apenas com a chave primária, mas, em seguida, adicionado em várias outras colunas sem sucesso.

Os executa subconsulta em nenhum momento em SQLite também, por isso parece ser a junção que faz com que o lento.

Answer 1

eu descobri que realmente está especificado na documentação que este tipo de junção não é bem suportado. A maneira de contornar o problema é usar outra tabela em vez de uma sub-consulta. Em seguida, ele voltou a ser incrivelmente rápido.

Answer 2

Running EXPLAIN QUERY PLAN na sua consulta sugere que ele está a fazer 2 varreduras de tabela para esta consulta.

Você pode querer ler a página O SQLite Query Optimizer Overview para obter mais informações sobre como funciona o otimizador

algo semelhante a isto ajuda pode (não testado, que não vê-lo sendo usado):

CREATE INDEX foo ON NewStatHistory(statID, campusID, IsTarget, DateApplies);