I thought it might be storage contention, too. BUT, as the documentation of SQLite said, in ?DELETE? mode, SELECTing do read for disk only. And I check the source code of SQLite, it uses unix file lock implement mutex. Will unix file lock keep one reading at one time ? If not, it might be other reasons making lower performance.
???? ???:Simon Slavinslavins at bigfraud.org ???:SQLite mailing listsqlite-users at mailinglists.sqlite.org ????:2015?11?2?(??)?11:38 ??:Re: [sqlite] Why SQLite take lower performanceinmulti-threadSELECTing? On 2 Nov 2015, at 3:12am, sanhua.zh sanhua.zh at foxmail.com wrote: I change my code to make it clear. That is must more easy for me to understand. I can think of no other explanation for your problem than storage contention. Multiple threads allow lots of processing at the same time but they do not allow four things to talk to your disk at the same time. Your disk interface can service only one thread at a time. Your threads are having a contest to read and write the same part of hard disk, and only one can do this at one time. The other three do nothing while that one is keeping the disk busy. So making four threads -- or forty threads -- is not going to help. Sorry. Simon. _______________________________________________ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
