Игорь

1. Копируете файлы базы данных на хост
2. Архивируете/Переносите
3. Поднимаете проект на другом хосте
4. Копируете файлы с хоста в контейнер

В вашем распоряжении есть

docker compose cp

https://docs.docker.com/engine/reference/commandli...

А вообще не вижу проблем с созданием полного дампа с последующим восстановлением.

docker-compose exec [service] mysqldump -u [user name] –p [password] [options] [database_name] [tablename] > [dumpfilename.sql]

Или

docker exec -t [hash container] mysqldump -u [user name] –p [password] [options] [database_name] [tablename] > [dumpfilename.sql]

Если дамп содержит все необходимые данные и не нарушает целостность данных, можно отключить проверку внешнего ключа.

Вы можете отключить проверку внешнего ключа в MySQL, установив для системной переменной external_key_checks значение 0.
SET foreign_key_checks = 0

Точно так же вы можете включить проверку внешнего ключа в MySQL, установив для системной переменной external_key_check значение 1.
SET foreign_key_checks = 1

UPDATE `table_name` SET `name`='one\r\ntwo\r\nthree' WHERE  `id`=1;

В таблице orders должен быть внешний ключ person_id который ссылается на таблицу person на первичный ключ.

Фактически это выглядит так

CREATE TABLE `persons` (
	`id` INT(10,0) NOT NULL AUTO_INCREMENT,
	`name` VARCHAR(255) NOT NULL COLLATE 'utf8mb4_0900_ai_ci',
	`phone` VARCHAR(255) NULL DEFAULT NULL COLLATE 'utf8mb4_0900_ai_ci',
	PRIMARY KEY (`id`) USING BTREE
)
COLLATE='utf8mb4_0900_ai_ci'
ENGINE=InnoDB;


CREATE TABLE `orders` (
	`id` INT(10,0) NOT NULL AUTO_INCREMENT,
	`date` DATETIME NULL DEFAULT NULL,
	`person_id` INT(10,0) NOT NULL DEFAULT '0',
	`street` VARCHAR(255) NOT NULL DEFAULT '0' COLLATE 'utf8mb4_0900_ai_ci',
	`name` VARCHAR(255) NOT NULL DEFAULT '0' COLLATE 'utf8mb4_0900_ai_ci',
	`phone` VARCHAR(50) NOT NULL DEFAULT '0' COLLATE 'utf8mb4_0900_ai_ci',
	PRIMARY KEY (`id`) USING BTREE,
	INDEX `person_id` (`person_id`) USING BTREE,
	CONSTRAINT `FK1_OP` FOREIGN KEY (`person_id`) REFERENCES `rmok`.`persons` (`id`) ON UPDATE CASCADE ON DELETE CASCADE
)
COLLATE='utf8mb4_0900_ai_ci'
ENGINE=InnoDB;

Может ли запрос SELECT в MySql на PHP приводить к удалению данных?

Нет, не может.

Я особого смысла не вижу.
Так как, в большинстве случаев, не нужно индексировать longitude, latitude

Например есть продукт, у продукта есть локация.
Как вы выполните привязку?
По двум полям longitude, latitude?

Создайте внешний ключ и не морочьте себе голову.

К стати, привожу пример.

Проходил мимо.
Не супер спец по базам данных, но кое-что в есть в багаже.

Всё зависит от ситуации.

Ситуация номер 1

Атомарность.

В этом случае нет смысла использовать autocommit, а нужно использовать транзакции.
Во-первых это правильный подход.
А во вторых можно сделать откат если возникла ошибка.
В третьих это даст прирост.

Ситуация номер 2
Вы хотите задампить большой объем данных, с последующим восстановлением.

В этом случае на N количество запросов можно открыть транзакцию, а после зафиксировать.
Это тоже даст прирост.

Это как с дверью, когда туда-сюда носишь мешки и при этом открываешь и закрываешь дверь, вы тратитевремя на эту неблагодарную операцию.

Если вам нужно занести 15 мешков картошки, открыли дверь, подставили кирпич и носите мешки, а потом не забываем закрывать.

Не забывайте, если постоянно держать дверь, можно простудиться и словить ошибку переполнения журнала транзакций.

В обычных случаях используем autocommit.
Сами понимаете, зачем открывать транзакцию если вставляете всего одну запись.

Ответ на ваш вопрос.
Оптимизация запросов и тюнинг СУБД даёт прирост.

Вот такой дилетантский ответ.
Спасибо.

Почему нельзя просто выполнить SELECT с нужным условием, я не совсем понял зачем нужен JOIN.

Ваш запрос абсолютно неверный.
Все присоединения нужно делать в самом начале.
Если вы хотите выполнить JOINпосле WHERE то вам следует обернуть в полноценный подзапрос.

Мне кажется вы слишком усложнили вашу задачу, серьёзно ))

Есть такое понятие как накопительная миграция.
Если я не ошибаюсь то в доктрине она уже есть.

нужно удалить все миграции и выполнять специальную команду для создания файла накопительной миграции.

А далее всё начинается заново.

Укажите IP адрес как в приведённом ниже примере, что бы не возникало путаницы.

# Database
  db:
    ...
    ports:
      - 127.0.0.100:3306:3306
    ...

Коллега, самое простое и быстрое решение.

1. Написать скрипт для парсинга данных из JSON
2. Написать скрипт, генератор SQLDump.
3. Залить дамп в базу.

Нет, так невозможно.
Выполняйте запросы по отдельности, а после обрабатывайте и отдавайте пользователю данные.

docker-compose, за три секунды будет работоспособная база

# Development configuration
version: "3.1"

services:

  # Database
  db:
    image: percona:latest
    container_name: mydata
    restart: on-failure
    ports:
      - 127.0.0.200:3306:3306
    expose:
      - 3306
    environment:
      - MYSQL_ROOT_PASSWORD=rk3kw1UDdqOEF4L1pmNkcyQ2oL
      - MYSQL_DATABASE=mydata
      - MYSQL_ROOT_HOST=%

100 MB достаточно большой объём для онлайн-сервисов.

Вот здесь вы намудрили

Не правильно

"SELECT * FROM `w3m_404urls` WHERE `url`= '.$rqul.'"

Относительно правильно.
"SELECT * FROM `w3m_404urls` WHERE `url`= '$rqul'"

Коллега.

Вот здесь подробно об этом

UPDATE mytable SET mytable.name = LOWER(mytable.name);

Есть вероятность что сам file PHP не, utf 8