Skip to main content

Home/ ProgrammingPages/ Group items tagged caching

Rss Feed Group items tagged

Navneet Kumar

MySQL Performance Blog » MySQL Query Cache - 0 views

  • It does not cache the plan but full result sets
  • so it looks at first letter of the query and if it is “S” it proceeds with query lookup in cache if not - skips it.
  • Might not work with transactions
  • ...15 more annotations...
  • uses non-deterministic functions such as UUID(), RAND(), CONNECTION_ID() etc it will not be cached.
  • If table gets modification all queries derived from this table are invalidated at once
  • if you have high write application such as forums, query cache efficiency might be pretty low due to this.
  • all queries are removed from cache on table modifications - if there are a lot of queries being cached this might reduce update speed a bit
  • Qcache_free_memory and Qcache_lowmem_prunes
  • number of your selects - Com_select and see how many of them are cached. Query Cache efficiency would be Qcache_hits/(Com_select+Qcache_hits).
  • One portion of query cache overhead is of course inserts so you can see how much of inserted queries are used: Qcache_hits/Qcache_inserts Other portion of overhead comes from modification statements which you can calculate by (Com_insert+Com_delete+Com_update+Com_replace)/Qcache_hits
  • want to set query cache
  • means it is much more efficient as query which required processing millions of rows now can be instantly summoned from query cache
  • It also means query has to be exactly the same and deterministic, so hit rate would generally be less
  • full page caching
  • not using query_cache_wlock_invalidate=ON locking table for write would not invalidate query cache so you can get results evenif table is locked and is being prepared to be updated
  • it can serve responses very fast doing no extra conversion or processing.
  • but it is still not as fast as specially designed systems such as memcached or local shared memory.
  • It is not distributed If you have 10 slaves and use query cache on all of them cache content will likely be the same, so you have multiple copies of the same data in cache effectively wasting memory
  •  
    mysql query caching
Navneet Kumar

mysql query cache - 0 views

  •  
    tuning mysql performance with query caching
Navneet Kumar

When Not to Normalize your SQL Database - SWiK - 0 views

  • With the above design, it takes six SQL Join operations to access and display the information about a single user. This makes rendering the profile page a fairly database intensive operation which is compounded by the fact that profile pages are the most popular pages on social networking sites.
  • Database denormalization is the kind of performance optimization that should be carried out as a last resort after trying things like creating database indexes, using SQL views and implementing application specific in-memory caching. However if you hit massive scale and are dealing with millions of queries a day across hundreds of millions to billions of records or have decided to go with database partitioning/sharding then you will likely end up resorting to denormalization
    • Navneet Kumar
       
      De-Normalization is OK if you are'nt going to update
  • Denormalization means that you you are now likely to deal with data inconsistencies because you are storing redundant copies of data and may not be able to update all copies of a column value simultaneously  when it is changed for a variety of reasons. Having tools in your infrastructure to support fixing up data of this sort then become very important.
  •  
    De-normalizing database to improve speed.
1 - 4 of 4
Showing 20 items per page