原文地址：https://github.com/memcached/memcached/wiki/ProgrammingFAQ#setup-questions
With memcached, you can't list all keys. There is a debug interface, but that is not an advisable usage.
Think about why you need to do it. If you're trying to troubleshoot your application, we find that it's often more informative to look at the flow rather than the current state. Run memcached in a screen session with -vv or -vvv to have it print what it's doing. You may also use MaatKit to use tcpdump to analyze traffic to an instance.
Watching the flow is very useful. You can see if your application is fetching keys inappropriately (one at a time vs multiget, or repeatedly in a single request), or you can see why memcached decided to invalidate a key (if ran in -vvv mode). Inspecting the state can't tell you any of this useful information anyway.
If it's a requirement that your application is able to pull or walk keys, you really want a database. Tokyo Tyrant, MySQL, etc, are good candidates for this. Memcached as a caching service cannot support the ability to safely walk keys without locking out all other operations. Adding indexes, multiversioning, etc, can make this possible but will lower memory and cpu efficiency.
You "can" via the debug interface stats cachedump, but that will only ever be a partial dump, and is slow.
Everything memcached does is an attempt to guarantee latency and speed. If you have to sometimes hit disk, that's no longer true.
All operations should run in O(1) time. They must be atomic. This doesn't necessarily mean complex operations can never happen, but it means we have to think very carefully about them first. Many complex operations can be emulated（模仿） on top of more basic functionality.
If a session disappears, often the user is logged out. If a portion of a cache disappears, either due to a hardware crash or a simple software upgrade, it should not cause your users noticable pain. This overly wordy post explains alternatives. Memcached can often be used to reduce IO requirements to very very little, which means you may continue to use your existing relational database for the things it's good at.
Like keeping your users from being knocked off your site.
The MySQL query cache can be a useful start for small sites. Unfortunately it uses many global locks on the mysql database, so enabling it can throttle（压制） you down. It also caches queries per table, and has to expire the entire cache related to a table when it changes, at all. If your site is fairly static this can work out fine, but when your tables start changing with any frequency this immediately falls over.
Memory is also limited, as it requires using a chunk of what's directly on your database.
Aside from any bugs you may come across, yes all commands are internally atomic. Issuing multiple sets at the same time has no ill effect, aside from the last one in being the one that sticks.
Because it's awesome. TODO: link to the new protocol page.
See [Timeouts] for help.
