Unsupported Screen Size: The viewport size is too small for the theme to render properly.

Schedule Backup

  • This topic is empty.
Viewing 4 reply threads
  • Author
    Posts
    • #12444
      dbachacha
      Member

      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,

    • #32632
      peterlaursen
      Participant

      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?

    • #32633
      dbachacha
      Member
      '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

    • #32634
      peterlaursen
      Participant

      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.

    • #32635
      peterlaursen
      Participant
Viewing 4 reply threads
  • You must be logged in to reply to this topic.