This requires that a transaction that starts as a read-only transaction can be later applied on the master if it issues a command that causes a transaction to really start.

markus makela, we have do a survy on our users who use read write split service, to our surprise,
most of their instances are not scale out properly, the master's qps is greater than sum of all read only replica's qps, there are two reasons:

1. need to keep session read consist, so add hint to route to master, or encapsulate all the statement in a transaction;
2. miss use transaction, most of statements are in transaction, some ORM framework let even worse;

cause this situation is very common among our users, so we need a way to make rwsplit more transparency；

found a worklog maybe helpful, https://dev.mysql.com/worklog/task/?id=6631
for example, the transaction below
BEGIN
SELECT
SELECT
SELECT
INSERT/UPDATE
SELECT
COMMIT;

in RC iso level; we can route first three select to slave, and route DML statement and all the statements behind DML to master;

we found in most cases, read is ahead of write, so this may very useful;
if combine with MXS-199 will be much better

Yes, we have planned to make the readwritesplit more aggressive so that slave servers are utilized to their full capacity. I believe that a good first step would be to implement MXS-199 to some degree and then think of a way to more effectively split the execution of transactions.

A few questions that need to be answered before anything is implemented:

• Should the slave and master start the transaction at the same time? (pessimistic transaction execution, assume write transactions)
• Should SELECT statements on slave be done outside of transaction? (would work quite well with MXS-199 and READ COMMITTED)
• Should the transaction be started on the master before the first select or only when a DML statement is done? (I am not completely sure if this affects the server in some way)