这取决于你需要的精度。

Datatype           Bytes       resolution
------------------ -----  --------------------------------
Deg*100 (SMALLINT)     4  1570 m    1.0 mi  Cities
DECIMAL(4,2)/(5,2)     5  1570 m    1.0 mi  Cities
SMALLINT scaled        4   682 m    0.4 mi  Cities
Deg*10000 (MEDIUMINT)  6    16 m     52 ft  Houses/Businesses
DECIMAL(6,4)/(7,4)     7    16 m     52 ft  Houses/Businesses
MEDIUMINT scaled       6   2.7 m    8.8 ft
FLOAT                  8   1.7 m    5.6 ft
DECIMAL(8,6)/(9,6)     9    16cm    1/2 ft  Friends in a mall
Deg*10000000 (INT)     8    16mm    5/8 in  Marbles
DOUBLE                16   3.5nm     ...    Fleas on a dog

来自:http://mysql.rjweb.org/doc.php/latlng

总结:

最精确的可用选项是DOUBLE。 最常见的使用类型是DECIMAL(8,6)/(9,6)。

从MySQL 5.7开始，考虑使用空间数据类型(SDT)，特别是POINT来存储单个坐标。在5.7之前，SDT不支持索引(5.6除外，当表类型为MyISAM时)。

注意:

使用POINT类时，用于存储坐标的参数的顺序必须是POINT(纬度，经度)。 创建空间索引有一种特殊的语法。 使用SDT的最大好处是您可以访问空间分析函数，例如计算两点之间的距离(ST_Distance)和确定一个点是否包含在另一个区域(ST_Contains)。

从一个完全不同和简单的角度来看:

if you are relying on Google for showing your maps, markers, polygons, whatever, then let the calculations be done by Google! you save resources on your server and you simply store the latitude and longitude together as a single string (VARCHAR), E.g.: "-0000.0000001,-0000.000000000000001" (35 length and if a number has more than 7 decimal digits then it gets rounded); if Google returns more than 7 decimal digits per number, you can get that data stored in your string anyway, just in case you want to detect some flees or microbes in the future; you can use their distance matrix or their geometry library for calculating distances or detecting points in certain areas with calls as simple as this: google.maps.geometry.poly.containsLocation(latLng, bermudaTrianglePolygon)) there are plenty of "server-side" APIs you can use (in Python, Ruby on Rails, PHP, CodeIgniter, Laravel, Yii, Zend Framework, etc.) that use Google Maps API.

这样，您就不必担心索引号和与数据类型相关的所有其他问题，这些问题可能会破坏您的坐标。

这取决于你需要的精度。

Datatype           Bytes       resolution
------------------ -----  --------------------------------
Deg*100 (SMALLINT)     4  1570 m    1.0 mi  Cities
DECIMAL(4,2)/(5,2)     5  1570 m    1.0 mi  Cities
SMALLINT scaled        4   682 m    0.4 mi  Cities
Deg*10000 (MEDIUMINT)  6    16 m     52 ft  Houses/Businesses
DECIMAL(6,4)/(7,4)     7    16 m     52 ft  Houses/Businesses
MEDIUMINT scaled       6   2.7 m    8.8 ft
FLOAT                  8   1.7 m    5.6 ft
DECIMAL(8,6)/(9,6)     9    16cm    1/2 ft  Friends in a mall
Deg*10000000 (INT)     8    16mm    5/8 in  Marbles
DOUBLE                16   3.5nm     ...    Fleas on a dog

来自:http://mysql.rjweb.org/doc.php/latlng

总结:

最精确的可用选项是DOUBLE。 最常见的使用类型是DECIMAL(8,6)/(9,6)。

从MySQL 5.7开始，考虑使用空间数据类型(SDT)，特别是POINT来存储单个坐标。在5.7之前，SDT不支持索引(5.6除外，当表类型为MyISAM时)。

注意:

使用POINT类时，用于存储坐标的参数的顺序必须是POINT(纬度，经度)。 创建空间索引有一种特殊的语法。 使用SDT的最大好处是您可以访问空间分析函数，例如计算两点之间的距离(ST_Distance)和确定一个点是否包含在另一个区域(ST_Contains)。

MySQL的空间扩展是最好的选择，因为你有空间操作符和索引的完整列表。空间索引允许您非常快速地执行基于距离的计算。请记住，作为6.0，空间扩展仍然是不完整的。我并不是在写MySQL Spatial，只是让你在深入了解它之前知道它的缺陷。

如果你严格地处理点，而只是DISTANCE函数，这是可以的。如果需要使用polygon、Lines或Buffered-Points进行任何计算，除非使用“related”操作符，否则空间操作符不会提供准确的结果。请参阅21.5.6顶部的警告。关系，如包含，内部，或交叉使用MBR，而不是确切的几何形状(即椭圆被视为矩形)。

此外，MySQL Spatial中的距离与第一个几何图形的单位相同。这意味着如果你使用的是十进制度数，那么你的距离测量就是十进制度数。当你离赤道越来越远时，这将使你很难得到准确的结果。

纬度范围从-90到+90(度)，因此DECIMAL(10,8)是可以的 经度范围从-180到+180(度)，因此需要DECIMAL(11,8)。

注:第一个数字是存储的总位数，第二个数字是小数点后的数字。

简而言之:latdecimal (10,8) NOT NULL, lng DECIMAL(11,8) NOT NULL

当我从ARINC424构建导航数据库时，我做了相当多的测试，并回顾了代码，我使用了DECIMAL(18,12)(实际上是NUMERIC(18,12)，因为它是firebird)。

浮点数和双精度数没有那么精确，可能会导致舍入错误，这可能是一件非常糟糕的事情。我不记得我是否发现了任何有问题的真实数据——但我相当肯定无法准确地存储在浮点数或双精度数中可能会导致问题

关键是，当使用角度或弧度时，我们知道值的范围——小数部分需要最多的数字。

MySQL空间扩展是一个很好的选择，因为它们遵循OpenGIS几何模型。我没有使用它们，因为我需要保持数据库的可移植性。