>> only checks field a for comparing it to 1, and because that is true for one row, it would cause a physical WRITE operation, no matter the fact the value of b is already 5? > That's what the current behaviour unambiguously implies (keeping in mind that it might not just be 1 field to compare, but might be 47 of them, 30 of which may contain multi-MB blobs and/or data with custom collations). Implies. But not necessarily does. In some cases no I/O operation will be generated to write a page that is the same as what it was previously, and in some cases the useless I/O will not be performed. There are many places which may perform this sort of "useless I/O filtering" ranging from the application itself, all the way down to the physical storage media hardware.