mysql - mysql POINT坐标的导出/导入问题

Question

我在将 MySql 数据库从本地导出然后导入到产品时遇到问题:

(我在“简单模式”下使用默认选项通过 phpMyAdmin 导出和导入。)

---

源数据库:本地环境MySql 5.7.19 (working)

表:lieux |数据库 | utf8_unicode_ci

列:

• 名称 => 坐标
• 类型 => 点
• Value => 'POINT(48.6863316 6.1703782)',0(好的)

---

目标数据库:生产环境MySql 5.6.?

表:lieux |数据库 | utf8_unicode_ci

列:

• 名称 => 坐标
• 类型 => 点
• Value => 'POINT(-0.000000000029046067630853117 -3.583174595546599e227)',0(坏的)

---

导出/导入后，点值发生变化，所有坐标均为false。

当我在 VSCode 编辑器中打开 .sql 导出时，我也有一个奇怪的显示:

点值看起来像这样: (文件为UTF-8格式)。

您知道 utf-8 是否与 MySql 中的坐标点有问题，或者产品服务器上的旧 MySql 版本是否可能导致此问题？我应该使用 utf8_mb4 字符集吗？

---

编辑:添加更多细节

1. 在我的项目(Laravel + Google Maps JavaScript API)中，我(在本地环境中)使用这些坐标创建了一个地点:48°41'10.8"N 6°10'13.4"E，在数据库中存储为 POINT(48.6863316 6.1703782) 并位于此处:

1. 然后，我进入 phpMyAdmin 的导出选项卡并进行简单的 sql 导出(使用默认选项)。

2. 然后我在 prod 服务器上登录 phpMyAdmin，进入导入选项卡并导入我的 sql 文件(也使用默认选项)。

3. 当我查看新数据库(在生产服务器上)时，该值存储为 POINT(-0.000000000029046067630853117 -3.583174595546599e227)，并且位于此处(在谷歌地图更正后它通过删除多余的字符):

我通过使用 Heidi SQL 而不是 phpMyAdmin 解决了这个问题，后者以不同的方式存储值:

• 在 phpMyAdmin 中导出 .sql 文件:
• 在 Heidi SQL 中导出 .sql 文件:

---

编辑:导出文件

-- phpMyAdmin SQL Dump
-- version 4.7.4
-- https://www.phpmyadmin.net/
--
-- Hôte : 127.0.0.1:3306
-- Généré le :  jeu. 26 juil. 2018 à 03:46
-- Version du serveur :  5.7.19
-- Version de PHP :  7.1.9

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET AUTOCOMMIT = 0;
START TRANSACTION;
SET time_zone = "+00:00";


/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;

-- --------------------------------------------------------

--
-- Structure de la table `lieux`
--

DROP TABLE IF EXISTS `lieux`;
CREATE TABLE IF NOT EXISTS `lieux` (
  `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  [...],
  `coords` point DEFAULT NULL,
  [...],
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

--
-- Déchargement des données de la table `lieux`
--

INSERT INTO `lieux` (`id`, `created_at`, `updated_at`, [...], `coords`, [...]) VALUES
(1, '2018-03-23 09:13:45', '2018-04-19 19:47:22', [...], '\0\0\0\0\0\0\0��I�mH@�D[@', [...]),
(2, '2018-03-23 18:11:59', '2018-07-12 16:15:06', [...], '\0\0\0\0\0\0\0���WH@.�s�w�@', [...]),
(3, '2018-04-02 14:00:29', '2018-04-19 19:47:32', [...], '\0\0\0\0\0\0\04j��E@�mWCu@', [...]);

-- --------------------------------------------------------

我用 [...] 替换了多余的数据

---

编辑:尝试 phpMyAdmin 选项和命令行 mysqldump

我尝试了 PHPMyAdmin 中的所有相关选项，但没有任何改变。我还尝试从具有不同版本的 PHPMyAdmin => 的远程环境中导出数据库 => 仍然无法正常工作。

我正在尝试使用以下指令在命令行中从本地导出:

C:\laragon\bin\mysql\mysql-5.7.19-winx64\bin
λ mysqldump.exe --host=localhost --user=root mydatabase > mydatabase.sql

但它仍然给我一个错误的编码:

-- MySQL dump 10.13  Distrib 5.7.19, for Win64 (x86_64)
--
-- Host: localhost    Database: db
-- ------------------------------------------------------
-- Server version   5.7.19

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `lieux`
--

DROP TABLE IF EXISTS `lieux`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `lieux` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  [...],
  `coords` point DEFAULT NULL,
  [...],
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `lieux`
--

LOCK TABLES `lieux` WRITE;
/*!40000 ALTER TABLE `lieux` DISABLE KEYS */;
INSERT INTO `lieux` VALUES (1,'2018-03-23 09:13:45','2018-04-19 19:47:22',[...],'\0\0\0\0\0\0\0��I\�mH@�D[@',[...]),(2,'2018-03-23 18:11:59','2018-07-12 16:15:06',[...],'\0\0\0\0\0\0\0��\�WH@.\�s�w�@',[...]),(3,'2018-04-02 14:00:29','2018-04-19 19:47:32',[...],'\0\0\0\0\0\0\04j��E@�mWCu@',[...]);
/*!40000 ALTER TABLE `lieux` ENABLE KEYS */;
UNLOCK TABLES;

部分mysqldump命令行导出文件

• 如何获取有关导出过程的更多信息？

• 您认为这可能是由于 row 上的错误值存储引起的吗创建(我的意思是当用户创建位置项时)？

• 可能与this other issue有关(也是我的，只是部分解决了)...

Answer 1

https://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html

看起来像 WKB 格式:

mysql> select HEX(ST_PointFromText('POINT(-0.000000000029046067630853117 -3.583174595546599e227)')); 
+---------------------------------------------------------------------------------------+
| HEX(ST_PointFromText('POINT(-0.000000000029046067630853117 -3.583174595546599e227)')) |
+---------------------------------------------------------------------------------------+
| 0000000001010000000E1BEFBFBDEFBFBDEFBFBD5748402EEF                                    |
+---------------------------------------------------------------------------------------+

这是“坏”数字中的两个 float :

mysql> select HEX(MID(REVERSE(ST_PointFromText('POINT(-0.000000000029046067630853117 -3.583174595546599e227)')), 1, 8));
+-----------------------------------------------------------------------------------------------------------+
| HEX(MID(REVERSE(ST_PointFromText('POINT(-0.000000000029046067630853117 -3.583174595546599e227)')), 1, 8)) |
+-----------------------------------------------------------------------------------------------------------+
| EF2E404857BDBFEF                                                                                          |
+-----------------------------------------------------------------------------------------------------------+

mysql> select HEX(MID(REVERSE(ST_PointFromText('POINT(-0.000000000029046067630853117 -3.583174595546599e227)')), 9, 8));
+-----------------------------------------------------------------------------------------------------------+
| HEX(MID(REVERSE(ST_PointFromText('POINT(-0.000000000029046067630853117 -3.583174595546599e227)')), 9, 8)) |
+-----------------------------------------------------------------------------------------------------------+
| BDBFEFBDBFEF1B0E                                                                                          |
+-----------------------------------------------------------------------------------------------------------+

他们看起来很合理。

不清楚您所说的“坏”或“假”是什么意思。请提供此类的 SQL 证据。

CHARACTER SET 应该完全无关。

啊哈。所以数字代表纬度和经度？那么，-3.583174595546599e227 (-3.58*10^227) 不是有效值。因此，从该值向后工作并显示生成/导出/导入数字的所有步骤。我们需要找出它被破坏的地方。首先查看导出文件。

mysqldump

根据您最近的编辑，mysqldump 正在处理 POINTs。我不知道确切的解决方案，但二进制内容需要以十六进制(或文本以外的其他方式)完成。

• phpadmin 可能有一个参数??
• 也许你可以得到 mysqldump 命令？

mysqldump 示例

构建测试表:

mysql> CREATE TABLE `lieux` (
    ->   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    ->   `coords` point DEFAULT NULL,
    ->   PRIMARY KEY (`id`)
    -> ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO lieux (coords) VALUES (ST_PointFromText('POINT(11.22 33.44)'));
Query OK, 1 row affected (0.01 sec)

mysql> 
mysql> SELECT HEX(coords) FROM lieux;
+----------------------------------------------------+
| HEX(coords)                                        |
+----------------------------------------------------+
| 000000000101000000713D0AD7A3702640B81E85EB51B84040 |
+----------------------------------------------------+
1 row in set (0.00 sec)

mysql> exit 
Bye

并转储它:

~$ mysqldump  --hex-blob try lieux -u root
-- MySQL dump 10.13  Distrib 5.7.23, for Linux (x86_64)
--
-- Host: localhost    Database: try
-- ------------------------------------------------------
-- Server version   5.6.22-71.0-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `lieux`
--

DROP TABLE IF EXISTS `lieux`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `lieux` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `coords` point DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `lieux`
--

LOCK TABLES `lieux` WRITE;
/*!40000 ALTER TABLE `lieux` DISABLE KEYS */;
INSERT INTO `lieux` VALUES (4,0x000000000101000000713D0AD7A3702640B81E85EB51B84040);
/*!40000 ALTER TABLE `lieux` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2018-08-20 13:38:24