我喜欢用InnoDB将纬度和经度以非常精确的方式存储到MySql数据库中。然而，float并没有提供足够的内部小数位数，所以我改为double。我有点奇怪，但MySql接受了30号的双人间，所以我使用了双人间（30,27），因为只需要3个常规位置，其余的必须在逗号后面。
在MySql中，到目前为止效果良好，另一方面，我在json_decode上收到浮动，当我回显它们时，逗号后面最多有18或19个位置。所以，即使在这里，一切都如预期。
但是，当我构建一个更新查询来填充空的双字段（双30/27）时，它只是用零填充所有数字，免除了前9个数字。或者有时打破规则从7开始。一行9的数字。
例如，当我在mysql中更新47.2608691999999877时——无论是按脚本还是按PhpMyAdmin，在klicking保存按钮后，47.260869-199999990000000000000将出现在应显示47.260869159999987000000000的表中或中
11396251100000000633，因为表中的更新给了我一个11396251100000000000000000000
因此，它似乎忽略了从7开始的可能位置。或者有时用9填充，但在大多数情况下只有零。
谁能给我一个小费来解决这个问题吗
请记住，我也遇到了PHPMyAdmin的问题，但它是由PHP组成的。现在我不确定这是MySQL还是PHP问题。
谢谢
例如I MYSql我可以很容易地将其存储在例如PHPMyAdmin:
注意到DOUBLE（30，27）是如何对16-17个有效数字有意义的，然后就失控了吗？
FLOAT具有24位精度。这对于大约7个有效数字来说已经足够了。特别是，对于纬度和经度来说，这足够精确到1.7米（5.6英尺）以内。对于大多数lat/lng应用，这就足够了。因此，插入时出现舍入错误（从十进制转换为二进制）和读取时出现另一个错误（转换回十进制）并不重要。
DOUBLE具有53位精度，约为16位有效数字——南北或东西方向3.5纳米！
DOUBLE（30，27）-插入时，它说（1）舍入到小数点后27位，（2）舍入到精度的53位。阅读时，它会颠倒步骤，导致你出现奇怪的混乱。
我从未见过在FLOAT或DOUBLE上使用（M，N）的有效需求。不要这么做。
对于DECIMAL（M，N），您将精确地存储小数点后N位的内容。对于纬度/lng，考虑十进制（6,4）表示纬度，（7,4）表示经度——16米（52英尺）。或者，为了更精确，（8,6）和（9,6）-16cm（6英寸）。
进一步注意，FLOAT占用4个字节（始终），DOUBLE:8，DECIMAL（6,4）:3，（7,4）:4，（8,6）:4和（9,6）:5。如果你有几十亿个lat/lng条目，那么存储的字节数就会加起来。
您的脚本和PHPMyAdmin是在PHP上编写的，它使用精度来显示浮点数，但mysql和PHP处理的数字尽可能准确。
尝试更改.ini精度设置：http://php.net/manual/ru/ini.core.php#ini.precision
对于lat/long存储，我不会相信任何浮点数字，几乎可以保证您会立即出现舍入错误。浮点数字根本没有那么准确。
您是否考虑过一个不动点整数（47.2608691999999877在需要显示/从输入返回时（甚至只是执行显示的字符串操作）通过乘以10000000000000000并除以10000000000000000而变为472608691999999877。）
这种规模的数字应该非常适合64位整数的范围（见鬼，你甚至可以得到第17位小数，但仍然可以：p。）