expanding on the hakkikonu's Answer, and read it first or this will make no sense if it does at all ...
and agreeing with @spencer7593 's comments, such things as "concurrency killing (CK) operations with locks",
and the need to fix the formula for determining the update count in hak's Answer
i see no way of getting accurate insert and update counts without CK. Throwing in AFTER triggers
certainly doesn't help solve it without CK, "alone and at the same time being accurate".
were one to have the nullable table1.blabla column only for use with batches against table1, regardless of the frequency
of such batches. if a batch is not running against table1, blabla is guaranteed to be null even if the column is not dropped. it is obvious how.
i believe you can get insert and update counts
accurately. here is how and based on your Insert statement.
table1 has write lock given exclusive to the batch code. let's assume the MyISAM storage engine. hey why not, we
are making assumptions here.
blabla column shows null 'inserted' and 'updated' based on your statement (barely different that what Hakkikonu suggested).
You have your counts.
Concerning what spencer wrote in his Answer about updates and or inserts happening more than once for a given row based on
your Question's Insert statement, I don't see it that way. Unless your batch data has duplicate keys presented in which case what does accuracy matter anyway.
Either the row is there or not to begin with based on whatever threw the ON DUPLICATE KEY. If it threw it, it is an update,
if didn't, insert. Someone correct me.
Then at end the alter table drop blabla is performed or update to null. lock released.
so i guess how important is update and insert counts, the size of the table, and the frequency of batches.