When I see explicit mention of API, it implies there's no running memcache daemon. I dug MySQL 5.7 manual several times, but I couldn't find any proof that thi

When I see explicit mention of API, it implies there's no running memcache daemon. I dug MySQL 5.7 manual several times, but I couldn't find any proof that this is just an memcache API atop MySQL. But I found some proof that says there's a real memcache daemon atop MySQL. > Running memcached in the same process space as the MySQL server avoids the network overhead of passing requests back and forth. MySQL 5.7 manual clarifies that they're running memcache daemon inside the database engine in-process mode. So actually real memcache is serving the data atop the engine. So, if dataset is read-only and small enough, it's likely to happen that whole the data is being served by memcache. In that case, it cannot be slower than memcache. That's why I couldn't be impressed. The only thing MySQL doing is automatic handling of memcache daemon. That should be convenient, but not impressive. Maybe I am wrong. If you think I am wrong, please show me some reference that explicitly mentions this is just API, and there's no running memcache instance. Also, regardless of whatever is really happening under hood, this benchmark is still meaningless. Because database exists to store data and all the hard stuffs are only happening when storing data. Writing transactions usually degrade performance a lot. That's why writing transactions must be included in benchmark to show the real world performance.