Я экспортировал живую базу данных MySQL (с mysql 5.0.45) в локальную копию (с mysql 5.1.33) без ошибок при импорте. В базе данных есть представление, которое при локальном выполнении возвращает другой набор данных, чем при удаленном выполнении. Он возвращает 32 результата вместо 63. Когда я выполняю необработанный sql, возникает та же проблема. Я проверил данные во всех объединяемых таблицах, и подсчеты совпадают.

Запрос прост и не имеет условий где - но около 10 соединений. Помимо различий в версиях mysql ... Я не могу найти причину, по которой этот запрос будет возвращать разные результаты между базами данных ... поскольку они фактически являются точными копиями.

Кто-нибудь сталкивался с подобной проблемой раньше?

0
mwalsher 9 Мар 2010 в 06:01
3
Похоже, ваш экспорт не был завершен.
 – 
Seth
9 Мар 2010 в 06:03
1
Счетчики такие же, поэтому экспорт, вероятно, завершен. Повторный экспорт из локальной копии во второй файл и diff второй файл с первым файлом (который вы использовали для импорта в локальную БД). Они должны быть одинаковыми. Кроме того, если какие-либо столбцы автоинкремента используются в JOIN (например, в качестве внешних ключей), убедитесь, что ваш экспорт сохранил значения из исходной БД и не заставил импорт регенерировать последовательности автоинкремента.
 – 
vladr
9 Мар 2010 в 06:32
Хороший совет, Влад - Я обнаружил проблему до того, как ты упомянул об этом, но хотел бы сначала прочитать твой пост. Проблема заключалась в том, что некоторые строки в экспортированной БД имели идентификаторы 0, но при импорте им давали положительный целочисленный идентификатор. Поскольку запрос выполнял соединение для некоторых из этих полей 0 id, при выполнении в новой БД некоторые результаты были пропущены из-за неработающих ссылок FK.
 – 
mwalsher
12 Мар 2010 в 21:50

2 ответа

Лучший ответ

Проблема заключалась в том, что некоторые строки в экспортированной БД имели идентификаторы 0, но при импорте им давали положительный целочисленный идентификатор. В результате неработающие ссылки FK привели к различным результирующим запросам.

0
mwalsher 12 Мар 2010 в 21:52

У меня были подобные проблемы при обновлении с 4.1 до 5.0, вызванные изменениями в том, как SQL был реализован в разных версиях. На ваши взгляды может повлиять что-то вроде этого.

Наш процесс обновления теперь включает в себя создание синхронизированных реплик двух версий, извлечение выдержек из журналов запросов в реальном времени, их сопоставление с обеими версиями и сравнение результатов. При обновлении с 4.1 до 5.0 нам потребовалось 6 месяцев, чтобы проработать изменения, необходимые для обеспечения совместимости нашей системы с обоими, учитывая, что у нас более 1000 различных запросов.

В Maatkit есть несколько инструментов, помогающих с обновлением:

mk-table-checkum - создавайте контрольные суммы ваших таблиц в обеих версиях . Это позволит определить мельчайшие различия, которые могут возникать по нагрузке.

Возможно, это тоже можно было бы использовать:

mk-query-digest - извлечение запросов из журналов для воспроизведения. (Я не уверен, работает ли это с журналом запросов или просто с журналом медленных запросов: мы написали аналогичный инструмент и поэтому не использовали его.)

0
Martin 9 Мар 2010 в 10:42