We run a website with a few few million visits per day. If I have ~8k records to update on a user table, at what point should we not do a SQL Update and instead do an Export/Import? Usually I do Export/Imports when I have a few million rows to update, but a few thousand may be too much for a database with our traffic.
I normally worry about this decision when we are talking millions of rows to update. But it really depends on your application's use of those 8000 rows. are they used by each visitor to your page?
It is an extension to the main user table that only records things like last session, last login, last order, and is queried once per login or when a timestamp has to update. i dont' think anything else is needed but if so, then it would be saved on login as a session variable to prevent unnecessary queries.
I ran the update a few nights ago in 10 chunks after hours during a slow time but our chief architect told everyone I should have run it using export/import instead but it did not make sense to me why. I normally know what I'm doing. This said person has a history of discrimination against only me.
Sounds like you are in a bad situation. For high concurrency I would perform updates of less than 100,000 rows with commits after every 10,000 or so. I would only do an export/import if changing 20% or more of the data in the table.