Your thinking made a huge leap between "I am trying to learn memcached.." (which is a fine objective) and I want SQLite queries to fun faster. Your benchmark results are certainly believable (it runs slower when trying to use memcached). I certainly would not anticipate any role at all for memcached in an SQLite application.
in reply to learning memcached
First SQLite has its own memory cache and it can be dynamically adjusted by the user. Default is 2MB. A dynamic increase of cache to 200MB would look like this:
$dbh->do('PRAGMA cache_size = 200000'); #size in pages
Certain operations like index creation can take a LOT of cpu and memory. In the app I'm currently working on, when creating the DB from a "scratch" situation, I run the cache size way up to decrease index creation from 60 to 30 seconds in my app. Big "bang" for one line of code!
The SQLite code is C/C++ and will do a far faster job of local cache management than some app, that is potentially on another machine. Also problems can arise when inserting cache between you and the DB (the stale data problem, if records are being updated).
The big hitter in your benchmark probably is the file open operation. Move that out of the loop to get a better idea of what the DB can do. With 20,000 strings, if avg size is 100 bytes, that is 2,000,000 bytes, 2MB. SQLite is already caching that much stuff without you doing anything at all. Making a cache of SQLite's cache is pointless.