Primary key и другие баги mySQL с join на фоне ORDER BY

Да, чтобы воспроизвести нужен запрос с left join в конце которого стоит order by и тогда можно увидеть что первичные ключи где-то потерялись. Здесь все четко описано https://bugs.php.net/bug.php?id=47547 Однако дело было в 2009, а я напоролся на те же грабли пару дней назад. Условия такие. wamp на winXP SP2 mySQL 5.6.12. Это сейчас, а позавчера mySQL был где-то в районе 5.3 с теми же самыми симптомами. Я поменял локальный сервер два раза - все осталось как было.

Кроме того, возможно это и связано, при тех же условиях слетает оригинальное имя поля. Превращается в алиас.

Кто-нибудь знает как это починить? Временно я сделал затычку - беру PRI с information_schema, но это значит от API mysqli остается только query. fetch_field походу придется полностью переписывать.

Кстати, еще, предустановленные константы типов полей не совпадают с реальными показаниями API. Мне пришлось показания просто передефайнить.

0

Сообщение от sqlnub Да, чтобы воспроизвести нужен запрос с left join в конце которого стоит order by и тогда можно увидеть что первичные ключи где-то потерялись. Здесь все четко описано https://bugs.php.net/bug.php?id=47547 MySQL 1 2 3 4 select cn.id from c_news cn LEFT JOIN c_news_categories cc ON cc.id = cn.area ORDER BY cc.name; Однако дело было в 2009, а я напоролся на те же грабли пару дней назад. Условия такие. wamp на winXP SP2 mySQL 5.6.12. Это сейчас, а позавчера mySQL был где-то в районе 5.3 с теми же самыми симптомами. Я поменял локальный сервер два раза - все осталось как было. Кроме того, возможно это и связано, при тех же условиях слетает оригинальное имя поля. Превращается в алиас. Кто-нибудь знает как это починить? Временно я сделал затычку - беру PRI с information_schema, но это значит от API mysqli остается только query. fetch_field походу придется полностью переписывать. Кстати, еще, предустановленные константы типов полей не совпадают с реальными показаниями API. Мне пришлось показания просто передефайнить.

Как там у классика? "На зеркало неча пенять, коли рожа крива!"
В запросе явным образом указано, что первичный ключ использовать нельзя. И тут же автор запроса возмущенно удивляется тому, что запрос действительно не использует первичный ключ...

Автор, в чердаке порядок наведи, прежде чем о новом баге заявлять

0

Ничего не понял. Для тех у кого на чердаке порядок вопрос:

свойства поля могут поменяться в результате сортировки полей?

Добавлено через 56 секунд
И почему чего нельзя использовать в запросе?

Добавлено через 12 минут
Попросил explain - абсолютно одинаковые отчеты для сортировки и без сортировки. Однако в апи до сортировки примари есть, а после сортировки - в сортире, то есть выходит куда-то.

Добавлено через 6 минут
В натуре это выглядит так. Выбрали таблицу - все ок. Стобцы примарей скрыты. Нажали на заголовок столбца чтобы сортировать - чпок и таблица расширилась на все примари которые в ней оказались, потому что они уже не примари. Но главное что редактировать таблицу после этого уже невозможно в той модели которая выбрана для редактирования. То есть на примарях конкретно. Ну, конечно, можно зафигачить в условие все поля и все значения.

0

Сообщение от sqlnub Ничего не понял. Для тех у кого на чердаке порядок вопрос: свойства поля могут поменяться в результате сортировки полей? Добавлено через 56 секунд И почему чего нельзя использовать в запросе?

Отдельно мухи, отдельно котлеты.

Есть поля базы
Есть индексы
Поля базы могут быть указаны в индексах, причем одно поле может быть указано в разных индексах.
Пример:Внимание, вопрос: Какое "свойство" у поля parent_id? Какое у id?
Ответ:
parent_id: INT(11) DEFAULT NULL
id: INT(11) NOT NULL AUTO_INCREMENT

Сообщение от sqlnub Попросил explain - абсолютно одинаковые отчеты для сортировки и без сортировки. Однако в апи до сортировки примари есть, а после сортировки - в сортире, то есть выходит куда-то.

Без указания сортировки - MySQL выдает строки в произвольном порядке. Ему удобнее выдавать их в порядке кластерного индекса, но это не означает, что так будет всегда. Например, при параллелельной обработке запроса на нескольких процессорах первой в итог будет добавлена порция данных, полученная от наиболее быстро завершившего обработку задания процессора.
Напротив, при указании ORDER BY сервер обязан предоставить данные в затребованном порядке. В этом случае он первым делом проверит, нет ли индекса, обеспечивающего заданный порядок. При наличии индекса сортировка не требуется, и в итог сразу будут включены записи в требуемом порядке

Если подходящего индекса нет - сервер вынужден выполнить операцию сортировки.

Но вы и тут извратили ситуацию, заставив сервер сортировать по отсутствующему в итоговой выборке полю. Поэтому, скорее всего, оптимизатор просто проигнорировал (вполне справедливо) требование на сортировку, и предоставил данные в хаотичном порядке.

Учите азы, легче будет понимать и управлять процессами, происходящими при компиляции и выполнении SQL-запросов

0

Придется и мне сказать - бред нерелевантный. Во-первых у меня тотально все поля имеются, ну вот сейчас 17 штук из 3 таблиц ни одного не пропущено и еще одно concat. Все поля с уникальными псевдонимами. Следовательно у меня такое не должно было повториться согласно вашей "теории". Однако повторяется в точности. До сортировки все 3 pri - PRI, а после - шиш.

Ну раз пошла такая пьянка и я налью.

PRIMARY KEY (`id`),
UNIQUE KEY(`parent_id`,`id`)

Что ^^^ это значит? primary это и есть unique только not null и его имя всегда PRIMARY. Даже если вы не напишите not null - мотор это сделат за вас. Тавтология детектет.

Сообщение от cygapb-007 Внимание, вопрос: Какое "свойство" у поля parent_id? Какое у id? Ответ: parent_id: INT(11) DEFAULT NULL id: INT(11) NOT NULL AUTO_INCREMENT

Неправильный ответ, у id будет PRI, а у parent_id - MUL. Потому что вы два поля туда зафигачили и получили тн композитный индекс.

Короче, индексы и ключи не могут слетать от сортировки и тем более от какой-то там выборки полей. Если поле не выбрано, ежу понятно по нему и не отсортируешь. Ну, то есть в запросе можно написать что угодно, но я про интерфейсы. У меня все поля есть.

И вообще почему я должен обсуждать ваши баги, когда у меня работа стоит. Теперь надо решать или брать все из информационной схемы - ну толку-то с одного примари, там же не только он слетает, еще пара-тройка битов отскакивает - либо как-то чинить этот mysqli.

Добавлено через 10 минут
Без сортировки
49667 1100001000000011

После сортировки
32769 1000000000000001

Попробуйте объяснить в рамках своей собственной теории куда делись целых три бита?

Насколько моя теория подсказывает - все что я назначил полю - все должно оставаться при нем как те самые свойства объекта. Использует мотор индексы или нет - меня это ниразу неколебет. Я хочу найти свое поле по первичному ключу который я сам повесил и если не могу - значит это баг.

Для тех кто идентифицирует поля по именам это все равно что после сортировки бы имя поменялось. И ксати, оно тоже меняется. Я выше отметил.

Короче глюконат этот ваш бесплатный майскуль. Уж насколько дурацким был адодб, но там и близко такого не было.

0

Пилите, Шура, пилите... Не отвлекайтесь...

Не для подначить, но пользы для: 13.1.17. CREATE TABLE Syntax

Сообщение от http://dev.mysql.com/doc/refman/5.6/en/create-table.html Code 1 2 3 4 5 6 7 8 9 10 11 12 13 14 create_definition:     col_name column_definition   | [CONSTRAINT [symbol]] PRIMARY KEY [index_type] (index_col_name,...)       [index_option] ...   | {INDEX|KEY} [index_name] [index_type] (index_col_name,...)       [index_option] ...   | [CONSTRAINT [symbol]] UNIQUE [INDEX|KEY]       [index_name] [index_type] (index_col_name,...)       [index_option] ...   | {FULLTEXT|SPATIAL} [INDEX|KEY] [index_name] (index_col_name,...)       [index_option] ...   | [CONSTRAINT [symbol]] FOREIGN KEY       [index_name] (index_col_name,...) reference_definition   | CHECK (expr)

0

Слив защитан. Пошел писать свой fetch_field.

0

Сообщение от sqlnub Слив защитан. Пошел писать свой fetch_field.

Не надо столь ярко демонстрировать уровень своего развития. Привыкли к терминам "слив" - идите на форумы по обсуждению сантехники

0

Впрочем, я раньше всегда юзал атрибут автоикремента, но тут подумал вдруг мне захочется что-то еще уникально подсчитать и поэтому добавил к его биту бит примари.

Может быть проще будет не хотеть что-то еще подсчитать автоматически кроме индексов. С другой стороны портятся еще данные. Например то самое поле concat согласно документации обязано быть оригинально именем функции, а я имею - пусто. Ну ладно, но после сортировки вместо пусто внезапно там появляется алиас.

Может быть и это объясняется цитатой create table с мануала?

Добавлено через 5 минут

Сообщение от cygapb-007 Не надо столь ярко демонстрировать уровень своего развития.

После вашей демонстрации моя просто меркнет. Я уже третий день ищу ответ как на халяву получить обратно сведения которые я внес в БД, а имею одно только г. На переполненном стеке такой же умнег процитировал что-то насчет версии сервера, я ему процитировал версию, он процитированное свое удалил.

Проблема в том что никому этот fetch_field не стучит. Его вообще почти не юзают и кроме цитат с зенда о значении ключей ничего в каментах на пхп нет нету.

Ну вот вам когда в последний раз надобились данные о полях? Вы ж и так знаете какое где и по имени впишите в апликуху id=. Я такого не могу - определенно я знаю только имя БД. Все остальное заранее неизвестно и может быть получено только из самой БД. Если я оттуда что-то не могу получить - значит оно остается неизвестным. Работе капец.

0

не интересен.
пилите свои такие разные гири самостоятельно

0

Это надо было сделать с самого начала - пройти мимо не интересного вопроса если нечего ответить по существу. Но мы же мимо тещиного дома...

0

Уточню: гирю PHP не надо пилить одновременно с гирей MySQL
Стоните где-нибудь в другом месте

0

Вы не знали ответа на вопрос и все равно влезли. Это баг и этот факт отражен в статье по линку. Но вот почему этот баг до сих пор проявляется я могу объяснить только тем, что свойствами поля большинство не пользуется, а те кто пользуются не пользуются mysqli.

0

Вы знали, что вопрос по PHP, но тем не менее влезли в форум по MySQL.

В терминах MySQL я попытался объяснить вам, что MySQL возвращает разные наборы данных при указании ORDER BY и без оного. Соответственно описания полей возвращаемого набора данных - тоже разные

Однако вы по-прежнему считаете, что PHP должен директивно указать серверу MySQL, какого результата вы (не PHP и не MySQL) ждете от MySQL в рамках вашего мироощущения.

Пилите ваши гири дальше, не отвлекайтесь на трёп, отрывающий от остановившейся работы.

0

Так я и говорю что это баг оптимизатора. Данные берутся не из базы, а из каких-то его глюкавых умозаключений. Типа чтобы побыстрее отдать. Ну вот, теперь мне побыстрее пришлось лезть в информационню схему и оттуда брать данные о примари для поля.

Еще раз. Следуя вашей логике могут и имена поле поменяться. А что такого - подумал оптимизатор и выдал вам вместо Диссертация - Диссер. И так, типа, понятно. Enjoy.

0

Сообщение от sqlnub Так я и говорю что это баг оптимизатора. Данные берутся не из базы, а из каких-то его глюкавых умозаключений. Типа чтобы побыстрее отдать. Ну вот, теперь мне побыстрее пришлось лезть в информационню схему и оттуда брать данные о примари для поля. Еще раз. Следуя вашей логике могут и имена поле поменяться. А что такого - подумал оптимизатор и выдал вам вместо Диссертация - Диссер. И так, типа, понятно. Enjoy.

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

аве, Наполеон, соседи по палате ждут вас!

PS про изменение имен полей вы усердно твердите, но нигде не приводите ни одного конкретного примера того самого "произвольного" изменения имен полей сервером.
"Ты видишь суслика? А он - есть!" (С)

0

Ну что, придется все-таки писать свой fetch_field

Вот я цитировал полученные данные:

Сообщение от sqlnub Без сортировки 49667 1100001000000011 После сортировки 32769 1000000000000001

Не только бит примари пропал. Еще целых три. И самая мякотка в том, что пропал и бит автоинкремента - 512.

Может оппонент теперь доказать что и автоинкремент пропадает из-за сортировки потому что выборка и бла-бла-бла, или все-таки признает хотя бы факультативно свой бред.

Я просто уже одурел от глюков майскуля, честно говоря.

0

пилите, Шура, они золотые...

0

Сообщение от cygapb-007 PS про изменение имен полей вы усердно твердите, но нигде не приводите ни одного конкретного примера того самого "произвольного" изменения имен полей сервером. "Ты видишь суслика? А он - есть!" (С)

Поэтому получается id такое, до сортировки

После такое

"Фотка" это алиас concat() двух полей.

Согласно мануалу в первом случае я должен получить типа concat, и во втором concat.

Азы или буки будем поднимать?

Добавлено через 10 минут
Нормальный id должен быть таким и он такой для всех остальных полей:

Таблица[Поле][Флаги][Тип]

orgtable на concat не приходит, а orgname после сортира заменяется алиасом.

0

Ну и при чем тут MySQL?

Пилите, но уже без меня. Холистичность для меня важнее вашего мироощущения. Все золото что напилите - ваше, и только ваше.

0