I've found MySQL to have issues with datasets that don't fit into the innodb buffer pool. Are you doing a lot of partitioning to make everything work well?

If everything is behind an ORM, have you considered trying out PostgreSQL w/ the MySQL FDW? pgsql 10's improvements to FDW's make it a truly viable option.

Also to clarify: I'm just saying this as pgsql seems to handle queries that involve disk access and large datasets much better. I have found that as long as your hot dataset fits into the innodb buffer pool and/or you're doing only key lookups (e.g.: select * from tbl where pk=1;) MySQL is most certainly faster for real-world usage. If you're pulling and sorting/filtering millions (or billions) of rows per query, I find that pgsql stands up extremely well to that. Even in a single huge server setup.

Also a semi-unrelated ditty, but as someone who has to run migrations on pretty big (100m rows) tables, ALTER TABLE LOCK=NONE ALGORITM=INPLACE is pretty great (here's a table of what you can user per-situation https://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-...)

If you made it this far in my comment you'll probably realize I didn't grasp the article well. I just re-read it and tl;dr, MyRocks works well (as expected) with datasets that don't fit into the innodb buffer pool. :)

Our workload is application specific and currently requires MySQL - 100% of queries are on primary keys so most 'hot' paths I think tend to stay resident, at least as far as query operations go. Also, we tend to fetch 'chunks' and operate on those in memory rather than running server side so some of the processing is offset by local operations.

Would be good to dig a bit deeper into this - thanks for the pointers.

Yeah. Innodb is heavily optimized for PK lookups.

The percona toolkit is critical for any MySQL DBA. So flexible and invaluable for many aspects of running a production fleet.

edit: I'm getting nostalgia of doing things with the toolkit like running a 24 hour lagged slave because one Developer kept dropping tables from the live primary database he'd decided were "obsolete" (when they weren't). Sadly we could never remove his root access.

Also of particular value: pt-online-schema-change, pt-table-checksum and pt-query-digest. The latter you can do some neat stuff, like tcpdump live traffic and pump it in to find out interesting stuff about live performance.

Thank you (Percona Founder)

Couldn't agree more.

Back in the day I used to be a Cloud Engineer at a small ISP/VPS provider + managed support(largely LAMP). Percona server was our MySQL install and we used their other tools pretty heavily for operations(backups, migrations, etc).

If I ever really needed a MySQL consultant, they would be top of the list for sure. I would say they are Tier N support, and I'm somewhere around Tier N-Y lol.

> Just going to point out that percona IMHO is potentially hugely underappreciated in the MySQL world...

Certainly not by MySQL users. Percona has run the yearly MySQL conference (now Percona Live) for years and has done excellent work on tools, DBMS distributions, and performance. Vadim's work in the cited article is pretty typical of the high standard of performance analysis.

(Nice work Vadim.)

indeed it is quite possible i am hugely out of the loop..

for those of us less 'in the know', i think there is a tendency to look at mariadb and oracle, and kind of overlook percona - this is what I was getting at.