This section discusses the characteristics of the
      DECIMAL data type (and its
      synonyms) in MySQL 5.1, with particular regard to the
      following topics:
    
Maximum number of digits
Storage format
Storage requirements
          The nonstandard MySQL extension to the upper range of
          DECIMAL columns
        
Possible incompatibilities with applications that are written for older versions of MySQL are noted throughout this section.
      The declaration syntax for a
      DECIMAL column is
      DECIMAL(.
      The ranges of values for the arguments in MySQL 5.1
      are as follows:
    M,D)
          M is the maximum number of digits
          (the precision). It has a range of 1 to 65. (Older versions of
          MySQL allowed a range of 1 to 254.)
        
          D is the number of digits to the
          right of the decimal point (the scale). It has a range of 0 to
          30 and must be no larger than M.
        
      The maximum value of 65 for M means
      that calculations on DECIMAL values
      are accurate up to 65 digits. This limit of 65 digits of precision
      also applies to exact-value numeric literals, so the maximum range
      of such literals is different from before. (In older versions of
      MySQL, decimal values could have up to 254 digits. However,
      calculations were done using floating-point and thus were
      approximate, not exact.)
    
      Values for DECIMAL columns in MySQL
      5.1 are stored using a binary format that packs nine
      decimal digits into four bytes. The storage requirements for the
      integer and fractional parts of each value are determined
      separately. Each multiple of nine digits requires four bytes, and
      any remaining digits left over require some fraction of four
      bytes. The storage required for remaining digits is given by the
      following table.
    
| Leftover Digits | Number of Bytes | 
| 0 | 0 | 
| 1 | 1 | 
| 2 | 1 | 
| 3 | 2 | 
| 4 | 2 | 
| 5 | 3 | 
| 6 | 3 | 
| 7 | 4 | 
| 8 | 4 | 
| 9 | 4 | 
      For example, a DECIMAL(18,9) column has nine
      digits on either side of the decimal point, so the integer part
      and the fractional part each require four bytes. A
      DECIMAL(20,6) column has fourteen integer
      digits and six fractional digits. The integer digits require four
      bytes for nine of the digits and three bytes for the remaining
      five digits. The six fractional digits require three bytes.
    
      Unlike some older versions of MySQL (prior to 5.0.3),
      DECIMAL columns in MySQL
      5.1 do not store a leading +
      character or - character or leading
      0 digits. If you insert
      +0003.1 into a DECIMAL(5,1)
      column, it is stored as 3.1. For negative
      numbers, a literal - character is not stored.
      Applications that rely on the older behavior must be modified to
      account for this change.
    
      DECIMAL columns in MySQL
      5.1 do not allow values larger than the range implied
      by the column definition. For example, a
      DECIMAL(3,0) column supports a range of
      -999 to 999. A
      DECIMAL(
      column allows at most M,D)M -
      D digits to the left of the decimal
      point. This is not compatible with applications relying on older
      versions of MySQL that allowed storing an extra digit in lieu of a
      + sign.
    
      The SQL standard requires that the precision of
      NUMERIC(
      be exactly M,D)M
      digits. For
      DECIMAL(,
      the standard requires a precision of at least
      M,D)M digits but allows more. In MySQL,
      DECIMAL(
      and
      M,D)NUMERIC(
      are the same, and both have a precision of exactly
      M,D)M digits.
    
      For more detailed information about porting applications that rely
      on the old treatment of the DECIMAL
      data type, see the MySQL 5.0 Reference
      Manual.
    


User Comments
There are programming languages and database accessing interfaces (e.g. Delphi 7 using DBExpress) which handle MySQL database columns with a NUMERIC type as BCD values, and have their own limitation of assuming that the fractional part has an even number of digits to use bytes optimally.
Although MySQL will be able to store odd numbers of fractional digits, such columns may not be handled correctly by those languages and interfaces.
Example: I used a column of the type NUMERIC(6,3) and got values in return which were off by the factor 16 in an application written in Delphi 7, using the DBExpress interface.
As far as I know, recent PHP 4 and 5 versions don't have issues with such columns.
Add your own comment.