650) this.width=650; "class=" AlignCenter wp-image-70519 "src=" http://www.linuxprobe.com/wp-content/uploads/2017/06 /mysql-300x150.jpg "alt=" MySQL query caching feature is now a bottleneck! MySQL's query caching feature is now a bottleneck! "Width=" 448 "height=" 224 "title=" MySQL query cache function is now a bottleneck! MySQL's query caching feature is now a bottleneck! "Style=" vertical-align:middle;height:auto;margin:10px auto; "/>
If you search the Web for "Tuning MySQL Query Cache" (optimized for MySQL queries) and see so many results and a plethora of suggestions, the news is not entirely surprising.
As Morgan Tock Morgan Tocker, a product manager at MySQL server, wrote here, the problem is extensibility.
The cached operation looks simple: The Select command is stored in a hash table (also known as a hash table); If the inbound request matches the hash, the server can return the result of the last query execution (and there is a protection mechanism so that the server does not return stale stale results.) )
The problem, says the trader, is that "it is well known that caching does not scale well with high-throughput workloads on multicore machines." ”
Even if the problem can be solved, he continues, the solution will not make the performance of the query cache more predictable (the implication is more stable), and for a user-oriented system, performance stability is often more important than peak throughput.
Instead of sticking to fixing cache issues, a group of developers at MySQL Server have decided to "work on other improvements that are more common to all workloads."
Developers who really need a caching mechanism can use Proxysql, and other users who upgrade to MySQL 8.0 "will be encouraged to use server-side query Rewrite (query rewriting). ”
This article is from the "12629896" blog, please be sure to keep this source http://12639896.blog.51cto.com/12629896/1933612
MySQL's query caching feature is now a bottleneck!