
Making full table scan 10x faster in InnoDB - aritraghosh007
http://yoshinorimatsunobu.blogspot.com/2013/10/making-full-table-scan-10x-faster-in.html
======
jjoe
Yoshinori is the engineer who developed MHA, MySQL replication auto failover.
It's essentially a perl script that ensures a master is always available and
functional. This is so DBAs don't have to spend hours manually fixing a broken
master/slave replication.

------
jey
> When doing full table scan, InnoDB scans pages and rows by primary key
> order.

What the fuck?

~~~
chrisbolt
Doesn't that make sense if data is clustered by the primary key, as InnoDB
does?

~~~
jey
Derp, yes. It's not an auxiliary index. However, it still seems weird for a
full table scan to be implemented this way instead of whatever's convenient
given the page layout. Why does it guarantee that the results will be in PK
order?

~~~
bickfordb
Many MySQL applications expect results to be delivered in primary key order if
no "order by" clause is supplied

~~~
jey
That seems dumb. If you require a particular ordering, you should have to
specify it and it might cost extra to put the results in that order.

------
rkalla
Only because it was the first thing that popped into my head, you can use
async file IO in Java 7+ with the AsynchronousFileChannel class[1]

Currently digging through Google to see if I can find how those async calls
are implemented on Linux/Windows to see if you can expect similar speedups in
performance as Yoshinori saw in this article.

[1]
[http://openjdk.java.net/projects/nio/javadoc/java/nio/channe...](http://openjdk.java.net/projects/nio/javadoc/java/nio/channels/AsynchronousFileChannel.html)

------
b0b0b0b
I would guess that InnoDB is trying to preserve some behavior of MySQL where
full table scans are expected to proceed by primary key order.

The solution sounds fragile; I guess you can't query by extent?

