MySQL 8.0 FAQ: NDB Cluster • Each primary key or hash index created for an  NDBCLUSTER  table requires 21 − 25 bytes per record. These indexes use  IndexMemory . •Each ordered index requires 10 bytes storage per record, using  DataMemory . •Creating a primary key or unique index also creates an ordered index, unless this index is created with  USING HASH . In other words: •A primary key or unique index on a Cluster table normally takes up 31 to 35 bytes per record. •However, if the primary key or unique index is created with  USING HASH , then it requires only 21 to 25 bytes per record. Creating NDB Cluster tables with  USING HASH  for all primary keys and unique indexes generally causes table updates to run more quickly—in some cases by a much as 20 to 30 percent faster than updates on tables where  USING HASH  was not used in creating primary and unique keys. This is due to the fact that less memory is required (because no ordered indexes are created), and that less CPU must be utilized (because fewer indexes must be read and possibly updated). However, it also means that queries that could otherwise use range scans must be satisfied by other means, which can result in slower selects. When calculating Cluster memory requirements, you may find useful the  ndb_size.pl  utility which is available in recent MySQL 8.0 releases. This Perl script connects to a current (non-Cluster) MySQL database and creates a report on how much space that database would require if it used the  NDBCLUSTER  storage engine. For more information, see Section 23.4.28, “ndb_size.pl — NDBCLUSTER Size Requirement Estimator” . It is especially important to keep in mind that  every NDB Cluster table must have a primary key . The  NDB  storage engine creates a primary key automatically if none is defined; this primary key is created without  USING HASH . You can determine how much memory is being used for storage of NDB Cluster data and indexes at any given time using the  REPORT MEMORYUSAGE  command in the  ndb_mgm  client; see Section 23.5.1, “Commands in the NDB Cluster Management Client” , for more information. In addition, warnings are written to the cluster log when 80% of available  DataMemory  or (prior to NDB 7.6)  IndexMemory  is in use, and again when usage reaches 90%, 99%, and 100%. Generally, any file system that is native to the host operating system should work well with NDB Cluster. If you find that a given file system works particularly well (or not so especially well) with NDB Cluster, we invite you to discuss your findings in the NDB Cluster Forums. For Windows, we recommend that you use  NTFS  file systems for NDB Cluster, just as we do for standard MySQL. We do not test NDB Cluster with  FAT  or  VFAT  file systems. Because of this, we do not recommend their use with MySQL or NDB Cluster. NDB Cluster is implemented as a shared-nothing solution; the idea behind this is that the failure of a single piece of hardware should not cause the failure of multiple cluster nodes, or possibly even the failure of the cluster as a whole. For this reason, the use of network shares or network file systems is not supported for NDB Cluster. This also applies to shared storage devices such as SANs. A.10.12. Can I run NDB Cluster nodes inside virtual machines (such as those created by VMWare, VirtualBox, Parallels, or Xen)? A.10.11. What file systems can I use with NDB Cluster? What about network file systems or network shares? 5249