+1  A: 

Hi,

What I recommend.

  1. Add an isProcessed column to your table.
  2. Make your script work on a chunk of, say, 1k rows for the first run (of course select only rows that are not processed).
  3. Benchmark it.
  4. Adjust the chunk size if needed.
  5. Build another script that calls this one at intervals.

Don't forget to add some sleep time in both your scripts!

This will work if your change does not need to be continuous (and I don't think it has to be). If you have to do it all at once you should put your database offline during the time the script runs.

Alin Purcaru
I'm not sure about adding new column, because altering 4GB table will take a lot of time.
sergeik
I doubt MySQL is that stupid. If you don't want that you can make a new temporary table with just `id` and `isProcessed` that you join with your original. The idea is that you should have a marker for the processed rows so you don't run the script twice on the same ones. Users may add more in the meantime or the script may fail and you will need to rerun it.
Alin Purcaru
In my case script process rows from bottom to top thats why I will not run script twice on the same ones.
sergeik
Well, if you want to use my proposed solution you'll have to use a marker because it does not do all the processing in one go. Also your argument does not stand if the script fails somewhere in the middle.
Alin Purcaru
+1  A: 

i will Add:

Why you create in each loop a new connexion and close it heh !!!

And maybe you can use db.autocommit(False) specially for the UPDATE and do a db.commit() for each 100 rows or something ;

and like Alin Purcaru you should do some benchmark as well.

Hope this can help :)

singularity
Thats why I'm asking this question=) We have some triggers on update and updating many rows could be a bottleneck.
sergeik
@sergeik: ok i understand now so forget about the autocommmit to false thing ; but create one connection to the database you don't have to repeat it each time; and do like S.Lott told you each time check if i proceed or pass (continue) and remember : "premature optimization is the root of all evil" Knuth ; unless you need to score a new record for the Guinness book and do a backup before we never know :)
singularity
@sergeik: "We have some triggers on update". Please **update** your question to include **all** the relevant facts. Please.
S.Lott
@singularity: "but create one connection to the database you don't have to repeat it each time" -- I know this, but don't understand the pros and cons of "persistent connection". OK, I can save some time on not repeating connection but maybe this long running connection eats memory or something.
sergeik
@sergeik : it's call database connection pooling ; and it very effective, because if you create each time a new connection so the script has to create each time a new instance Connection (more Memory) and the DBMS is also reserving a new connection (new thread ..) for this , so what do you think which is better :) .
singularity
@singularity: I'm running update with original script=) And you know memory consumption by python process is the same all time long.
sergeik
It took about 5 hours. Very fast in the beginning and very slow in the end...
sergeik
+1  A: 
    db_data = db.query('''
        SELECT id AS news_id, image AS src_filename
        FROM emd_news
        ORDER BY id ASC
        LIMIT %s, %s''', offset, LIMIT_ROW_COUNT)
     # Why is there any code here at all?  If there's no data, why proceed?
     if not db_data: break
S.Lott
You are right! Thanks.
sergeik