forums › forums › SQLyog › Sync tools, Migration, Scheduled Backup and Notifications › Schedule Backup
- This topic is empty.
-
AuthorPosts
-
-
September 3, 2011 at 12:38 pm #12444dbachachaMember
Hello,
In SQlYog ver 8.0 and up, I understand that it does a select on the table and the # of records fetched depends on the CHUNK SIZE.
Does this SELECT cache results or store results in the QUery Cache? I did not see SELECt *SQL NO CACHE* when the backup was running.
I did not see any option the backup wizard that disables storing of results in the Query Cache.
Thanks,
-
September 3, 2011 at 8:57 pm #32632peterlaursenParticipant
There is currently no option to use SELECT SQL_NO_CACHE. But why is it a problem? Because of same considerations as here: http://code.google.c…detail?id=1538?
-
September 4, 2011 at 4:11 am #32633dbachachaMember'peterlaursen' wrote:
There is currently no option to use SELECT SQL_NO_CACHE. But why is it a problem? Because of same considerations as here: http://code.google.c…detail?id=1538?
The link http://code.google.com/p/sqlyog/issues/detail?id=1538 gave 404 http error.
I tried chunk size of 1000,000 records and backup got over within 1.5 hours. During the backup users found that the pages were loading slowly when they switched between various options in the web based ASP.Net application that was connected to MySQl database server. The database server is dedicated to mysql.
I found that SELECt does not use *SQL No Cache*, so MySQL will cache the result set. The QUery Cache is 2GB.
Next day I tried reducing the CHUNK SIZE to 10,000 and it took 15 hours for backup to complete. This is understandable because with reduced CHUNK SIZE, the # of times a SELECt is done on a table is more compared to CHUNK SIZE of 1000000.
Isn't it beneficial to have SQL No Cache in the SELECT statement?
Thank you
-
September 4, 2011 at 7:15 am #32634peterlaursenParticipant
The link works fine for me.
I don't thin SQL_NO_CACHE will make any difference for the performance of backup. But the problem is that if not used all teh SELECts we send will be cached and then what is already in the cache will/may be flushed. And that could result in slowing down queries by other applications (as the result is gone from the Query Cache)
So yes .. an option to use SQL_NO_CACHE in the export and backup tools is a good idea.
-
September 4, 2011 at 7:19 am #32635peterlaursenParticipant
Added to our issue tracker:
-
-
AuthorPosts
- You must be logged in to reply to this topic.