Spatial Type Storage Requirements The  NDB  storage engine supports variable-width columns. This means that a  VARCHAR  column in an NDB Cluster table requires the same amount of storage as would any other storage engine, with the exception that such values are 4-byte aligned. Thus, the string  ’abcd’  stored in a  VARCHAR(50)  column using the latin1  character set requires 8 bytes (rather than 5 bytes for the same column value in a  MyISAM  table). TEXT  and  BLOB  columns are implemented differently in  NDB ; each row in a  TEXT  column is made up of two separate parts. One of these is of fixed size (256 bytes), and is actually stored in the original table. The other consists of any data in excess of 256 bytes, which is stored in a hidden table. The rows in this second table are always 2000 bytes long. This means that the size of a  TEXT  column is 256 if  size  <= 256 (where  size  represents the size of the row); otherwise, the size is 256 +  size  + (2000 × ( size −  256) % 2000). The size of an  ENUM  object is determined by the number of different enumeration values. One byte is used for enumerations with up to 255 possible values. Two bytes are used for enumerations having between 256 and 65,535 possible values. See Section 11.3.5, “The ENUM Type” . The size of a  SET  object is determined by the number of different set members. If the set size is  N , the object occupies  ( N +7)/8  bytes, rounded up to 1, 2, 3, 4, or 8 bytes. A  SET  can have a maximum of 64 members. See Section 11.3.6, “The SET Type” . MySQL stores geometry values using 4 bytes to indicate the SRID followed by the WKB representation of the value. The  LENGTH()  function returns the space in bytes required for value storage. For descriptions of WKB and internal storage formats for spatial values, see Section 11.4.3, “Supported Spatial Data Formats” . In general, the storage requirement for a  JSON  column is approximately the same as for a  LONGBLOB  or LONGTEXT  column; that is, the space consumed by a JSON document is roughly the same as it would be for the document’s string representation stored in a column of one of these types. However, there is an overhead imposed by the binary encoding, including metadata and dictionaries needed for lookup, of the individual values stored in the JSON document. For example, a string stored in a JSON document requires 4 to 10 bytes additional storage, depending on the length of the string and the size of the object or array in which it is stored. In addition, MySQL imposes a limit on the size of any JSON document stored in a  JSON  column such that it cannot be any larger than the value of  max_allowed_packet . For optimum storage, you should try to use the most precise type in all cases. For example, if an integer column is used for values in the range from  1  to  99999 ,  MEDIUMINT UNSIGNED  is the best type. Of the types that represent all the required values, this type uses the least amount of storage. All basic calculations ( + ,  - ,  * , and  / ) with  DECIMAL  columns are done with precision of 65 decimal (base 10) digits. See Section 11.1.1, “Numeric Data Type Syntax” . If accuracy is not too important or if speed is the highest priority, the  DOUBLE  type may be good enough. For high precision, you can always convert to a fixed-point type stored in a  BIGINT . This enables you to do all calculations with 64-bit integers and then convert results back to floating-point values as necessary. 2091 11.9 Using Data Types from Other Database Engines 11.8 Choosing the Right Type for a Column JSON Storage Requirements Spatial Type Storage Requirements