Iphone Sqlite3 쿼리가 너무 느리다

Question

안녕하세요. 내 앱이 정말 붙어 있습니다. SQLite3을 사용하여 aprox 250.000 행 (50MB)을 사용하여 내 테이블에서 간단한 SELECT를 작성해야합니다. Iphone Simulator로로드하면 쿼리에 3 초가 걸립니다. 기기에서 내 앱을 테스트 할 때 검색어에 90 초가 걸립니다. 불행히도 90 초의 기다림으로 앱을 출시 할 수 없습니다. 여기에 내 코드를 게시 :

-(void) loadResults { 

sqlite3 *database; 
NSMutableString *street; 
zone = [[NSMutableArray alloc] init]; 

if(sqlite3_open([databasePath UTF8String], &database) == SQLITE_OK) { 
    const char *sqlStatement = [[NSString stringWithFormat:@"select street from streets "] UTF8String]; 
    sqlite3_stmt *compiledStatement; 
    if(sqlite3_prepare_v2(database, sqlStatement, -1, &compiledStatement, NULL) == SQLITE_OK) { 
     while(sqlite3_step(compiledStatement) == SQLITE_ROW) { 

      street = [NSMutableString stringWithUTF8String:(char *)sqlite3_column_text(compiledStatement, 0)]; 
      [zone addObject:street]; 
     } 
    } 
    sqlite3_finalize(compiledStatement); 
} 
sqlite3_close(database);} 

이 더 WHERE 문이 당신이 볼 수 있듯이 내가 sqlite3를

CREATE TABLE streets (id INTEGER PRIMARY KEY, street TEXT, province TEXT, country TEXT, from TEXT, to TEXT, lat TEXT, lon TEXT); 
CREATE INDEX strIndx on streets(street); 

를 사용하여 내 테이블을 만들어 한 방법이다, 그것은 단지 간단 "로부터 거리를 선택 거리 "

여기에서 도움이 필요하십니까 미리 감사드립니다.

Answer 1

무엇을하려하십니까? WHERE 절이 없다는 것을 인정하면서 Obj-C 측에서 행을 필터링하는 것과 같은 일을하지 않는다고 가정합니다. 따라서 내가 생각하는 유일한 것은 당신이하려고하는 것입니다 (제가 틀렸다면 주석을 달아주세요). 디스플레이를 위해 모든 행을로드합니다. 애플은 이것에 대한 아주 간단한 표준 권고안을 가지고있다. 기본적으로 원래 쿼리에 15 개의 행 제한을 추가하고 더 많이 검색하는 방법이 있습니다 (일반적으로 '더 많이로드 ...'라는 파란색 텍스트가있는 테이블 바닥 글이됩니다). 또는 요청할 때까지 (사용자가 스크롤 할 때 발생하는) 제한 아래로 셀을로드하지 않고 구현할 수도 있습니다.

Answer 2

답장을 보내 주셔서 감사합니다. Jared, 내가 필요한 것은 UITableView에 모든 거리를 표시하고 사용자가 UISearchBar에서 검색을 필터링하거나 목록에서 선택하도록 허용하는 것입니다. 내가

SELECT DISTINCT(street) from streets 

내 쿼리를 변경했습니다 이것은 3000 행의 원인이 있지만, 그 90 초입니다 DISTINCT없는대로 동일한 시간이 소요 돌아왔다. 나는 또한 "GROUP BY 거리"로 아무런 이득도 얻지 못했습니다. 그러나 내가 .. LIMIT 3000을 추가하면 결과가 즉시 나타납니다. 나는 질의가 LIMIT과 관련이없는 DISTINCT 값을 얻기 위해 전체 테이블을 이동해야한다고 생각합니다. INDEX의 문제 일 수 있습니까? 색인이 작동하는지 어떻게 알 수 있습니까? 다시 한번 감사드립니다!

Answer 3

3000 개의 결과 만있는 250,000 개의 행이있는 경우 각 거리는 평균 83 시간 동안 데이터베이스에 있습니다.

아마도 거리를 별개의 정규화 된 테이블로 분리하고 각 값이 한 번만 발생하면 주소 테이블의 해당 거리를 ID로 참조하는 것이 적절할 것입니다. 그런 다음 TableView에 대해 Streets 테이블의 값만 되돌릴 수 있습니다.

앞서 언급 한 것처럼 UI 패러다임 문제가있을 수도 있습니다. UI에 3000 개의 항목이있는 표가 있으면 잠재적으로 사용자에게 지루할 수 있습니다. (한 번에 한 번 클릭하여 Yabar Street으로 내려가는 것을 상상해보십시오.)

이전에 제안한 것처럼 테이블을 적어도 게으른로드 할 수 있습니다. 또는 사용자가 거리 이름을 입력하도록 허용하고 Google 추천 유형 인터페이스를 제공하여 입력 할 때 잠재적 인 일치 항목을 표시 할 수 있습니다.