Disable SQL Cache Temporary in Rails

Disable SQL Cache temporary in Rails?

Solved with model.connection.clear_query_cache

Run ActiveRecord commands on Rails console without SQL caching

I'm not sure if you can remove it FROM the console but I think you can add this to an initializer to remove it for development.

if Rails.env.development?
  Rails.configuration.middleware.delete ActiveRecord::QueryCache
end

How can I force the rails SQL cache to clear?

All you need to do is to reestablish database connection. Try:

system("bundle exec rake db:reset")
puts User.count
User.destroy_all("username = 'user3'")
puts User.count

system("bundle exec rake db:reset")
ActiveRecord::Base.clear_all_connections!
puts User.count
User.destroy_all("username = 'user3'")
puts User.count

The main question is: why do you need to do this? I am pretty certain there is a better way to achieve what you want.

Disable Rails SQL logging in console

To turn it off:

old_logger = ActiveRecord::Base.logger
ActiveRecord::Base.logger = nil

To turn it back on:

ActiveRecord::Base.logger = old_logger

Clearing ActiveRecord cache

To a first approximation:

ActiveRecord::Base.connection.query_cache.clear

How disable postgresql Cache optimization?

PostgreSQL doesn't have a "cache" optimisation, in the sense of a query result cache.

It does cache table blocks that were recently read in shared_buffers, but for most installs that only has a small effect. The main cache is the operating system's disk read cache. For more information see:

See and clear Postgres caches/buffers?

It sounds to me like you have a system with a reasonable amount of RAM and a fast CPU but a terribly slow disk. So queries that only hit the OS's disk cache are very fast, but queries that go to disk take a couple of seconds to read the data in. So caching effects are very strong.

You should explain (buffers, analyze, verbose) SELECT ... your queries. Try with a couple of different input values until you get a slow one. Compare plans.

If the plans are the same, that's probably it.

If the plans are different, you're probably hitting a situation where the query planner is making bad choices based on variations in the table statistics. Increasing the statistics targets for the columns of interest may help (see the manual). If you get different plans and are stuck / want help, feel free to post a new question on dba.stackexchange.com with details.

query_cache_type: enable or disable?

MySQL query cache is a cache mechanism that stores the text of the query (e.g. 'SELECT * FROM users WHERE deleted = 0') and the result of the query into memory. Please check this link to know how to enable mysql query cache in your server.

The wordpress DB cache plugins on the other hand, decreases count of queries to DB by caching queries in temp files (Check your cache directory wp-content/tmp/ for cache files).

Above two paragraphs prove that Wordpress db cache AND mysql query cache are different.

mysql query cache you should enable ONLY IF your site does more mysql reads than writes. since yours is a wordpress site, YES you can try by enabling mysql query cache.

Hope I answered your 2 questions.

MySQL 8 Disable Query Cache for current session

The query cache was removed in MySQL 8.

You can try clearing buffers, as described here:
how to clear/flush mysql innodb buffer pool?

However, there will be OS-level disk caching, and also hardware (HDD/SDD) caching. This makes a 2 order magnitude difference on what I'm personally testing at the moment. What you're proposing may not be possible.

I'd suggest using EXPLAIN queries and very carefully thinking about what indexes are used, how many rows are touched, whether it's creating temporary tables, and generally to think through the execution strategy MySQL will be having ot execute.

Once you believe you have fixed your performance issue, see how it performs on a cold boot.

---

Related Topics