I debugged this yesterday. Since the get: no matching rows warning is from getMulti() in SqlBagOStuff.php, I modified the statement that prints this warning to also emit the search key. Comparing the logs of both utf8 and binary versions, I found the first key that resulted in get: no matching rows to be actually present in the [[ https://www.mediawiki.org/wiki/Manual:Objectcache_table | objectcache table ]], but the keyname is the search key concatenated with \0s.

Unfortunately I am not familiar with with the MediaWiki codebase at all. Would you please provide some examples? Thanks...

Sorry but I previously forgot to mention in my two comments that there is an additional operation on the DB before the CONVERT TO CHARACTER SET conversions:

ALTER DATABASE wiki CHARACTER SET binary;

Well, please feel free to ask for more information if necessary. I have set up a test VM with the data from my wiki, and can switch between the binary and utf8 versions very easily. I can confirm that the exact difference between the two versions is the changed DEFAULT CHARSET plus the CONVERT TO CHARACTER SET conversions.

I am also hit by this problem on MW v1.27.2. My wiki site that worked well with DEFAULT CHARSET=utf8 (for historical reasons; its DB was already up to date after using update.php) now denies all logins with a localised version of

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.

after I switched to DEFAULT CHARSET=binary in LocalSettings.php and converted the DB using the following statement on every table (except for searchindex) in the DB:

ALTER TABLE sometable CONVERT TO CHARACTER SET binary;