If you look at the slides from the Users conference on MySQL Cluster
they provide most of the answer to your
The short story is that there are 4 access methods
1) Full table scan (when no indexes present)
This scans all nodes in parallel and sends the result to the MySQL
Server. There is a controller in the parallel
scans such that scans proceed in the speed which the MySQL server
digests the result.
2) Range scan (using ordered index)
This uses the same scan protocol but scans using the ordered index and
only the assigned range.
3) Unique hash index
This is always a lookup for one record. It uses the unique key to make
a single lookup in the unique index table
and uses the result of this query to query the original table with a
primary key lookup.
4) Primary key index
This uses the hash index on the primary key of the original table
(always present) to lookup.
Both 3) and 4) are single record lookups and uses the hash key to
discover which node to get the data from.
Later on we will add support also for pushing down parts of the WHERE
clause to 1) and 2) to perform some of
the filtering down in the storage engine.
PS: If you look at the code it is fairly easy to find those methods in
2004-08-11 kl. 02.09 skrev Clint Byrum:
> There is much talk about how MySQL Cluster stores data, but I can't
> to find a definitive answer as to how it retrieves data.
> My thought was that it would submit the query to each node-group, do
> processing there, and then the API must collate/join the results from
> each node group. That, or the node groups somehow work together to join
> their result sets.
> Is this far off the mark? Is there a diagram somewhere I can look at?
> MySQL Cluster Mailing List
> For list archives: http://lists.mysql.com/cluster
> To unsubscribe:
Mikael Ronström, Senior Software Architect
MySQL AB, www.mysql.com