title: Cost / performance of COMMIT vs. ROLLBACK if no data has been changed in the transaction
body: <p><strong>Disclaimer:</strong></p>
  
  <p>I already have read <a href="https://stackoverflow.com/questions/18473280/for-a-writeless-transaction-which-is-cheaper-quicker-commit-or-rollback">For a writeless transaction which is cheaper/quicker: COMMIT or ROLLBACK?</a>, which is similar to my question, but relates to MS SQL Server and is quite old. Furthermore, the answer surprised me somehow, so I would like to know how the situation with MySQL 5.7 is in 2018.</p>
  
  <p><strong>Having said this:</strong></p>
  
  <p>Suppose the following scenario:</p>
  
  <ul>
  <li>I am running MySQL 5.7.</li>
  <li>I have turned off implicit transactions.</li>
  <li>I have an InnoDB table.</li>
  <li>I <code>BEGIN</code> a transaction.</li>
  <li>I <code>SELECT ... FOR UPDATE</code> which locks a few rows in the table (in most cases, one row).</li>
  <li>I examine the row(s) being selected / locked and come to the conclusion that the data is fine as it is, and therefore ...</li>
  <li>... I decide to <em>not change any data at all in the rows being locked</em>.</li>
  </ul>
  
  <p>Now I want to finish the transaction. I could do that either the normal way, that is, by issuing a <code>COMMIT</code>, which in this case will just remove the locks, or, as an alternative, by issuing a <code>ROLLBACK</code>, which in this case also will just remove the locks.</p>
  
  <p>The outcome of the two methods would be the same, but my feeling is that there may be a big difference regarding cost / performance.</p>
  
  <p>Could somebody please tell me which of the methods is recommended if the fraction of the rows being locked is always negligible (i.e. something like 1/1e6), and perhaps give some background (or a link to some background)?</p>