Вас всех в гугле забанили походу (

ща попробую

Вас всех в гугле забанили походу (

я не нашел

https://www.w3schools.com/sql/sql_update.asp

update table1 set state is null where id=123 and state<>0

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'is null where mark<>0' at line 1

спасибо всем)

не за что

спасибо всем)

без лишних слов)))

У меня вопрос созрел. Я сделал leftjoin. Во таблице к первой соотносится несколько строк. Как мне из второй таблицы выбрть максимальное в колонке?

Table1 id,name Table2 id,id_table1,chtoto Как выбрать из второй таблицы только 1 строку с максимальным значением в chtoto

Table1 id,name Table2 id,id_table1,chtoto Как выбрать из второй таблицы только 1 строку с максимальным значением в chtoto

https://stackoverflow.com/questions/14678056/sql-getting-max-id-field-on-a-left-join

спасибо1 попробую разобраться

спасибо1 попробую разобраться

тебе нужно сделать select (max.id_from_table_one) и сгруппировать по joinTable.relation_from_table_one_id

пока не понятно, я щас на русских гляну :)

я просто чот тупанул, не знал как загуглить. сейчас задача проще)

mysql 8 ещё не релизнулся?

релиз кандидатнулся

а релиз по планам когда намечается?

вообще есть смысл с 5.7 на 8.0 например переезжать, даже если не использовать новые фичи, а с тем что он будет быстрее за счёт внутренней потимизации?

Как показывает практика, без использщования фичей версии с четвёртой идёт только деградация))))

если не использовать новые фичи, он будет на 5-10% медленнее, если смотреть на одно соединение

но масштабируемость на многих соединениях будет лучше, особенно на записи, на high end железе и т. д.

тоесть как с условным пхп 5.6 - на 7.0 не прокатит с приростом под 40 процентов по умолчанию)

Ринат, абсолютно нет

понял)

@alexey_kopytov Кстати про деградацию. Версии с 5,6, если не ошибаюсь, начали сильно просаживаться запросы с большими данными для агрегации. В 5,7 сели ещё сильнее. Есть ли универсальные советы по исправлению этого дела, кроме "перепишите отчёты руками, а не тем, чем их писали ранее"??

а кстати с maridb как обстановка?

т.е там аналог 8ки будет? по сути одна и та же база же сейчас

@alexey_kopytov Кстати про деградацию. Версии с 5,6, если не ошибаюсь, начали сильно просаживаться запросы с большими данными для агрегации. В 5,7 сели ещё сильнее. Есть ли универсальные советы по исправлению этого дела, кроме "перепишите отчёты руками, а не тем, чем их писали ранее"??

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

т.е там аналог 8ки будет? по сути одна и та же база же сейчас

"аналог" 8ки — это 10.2, которая уже вышла. там есть cte и window functions

но там текстовый json и .frm :)

и так себе gis. в обшем, разъезжаются они с mysql

т.е если узаешь марию-то лучше там и оставатьс?

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

перкона где-то делала неплохое сравнение

ну я и говорил-без погружения не прокатит

https://www.percona.com/blog/2017/11/02/mysql-vs-mariadb-reality-check/

это сравнение написано перебежчиком из mariadb в percona. но он очень старался быть объективным. и у него почти получилось

@alexey_kopytov планы абсолютно одинаковые, данные одинаковые. Отчётов с деградацией десятки, т.е. проблема массовая. Понятное дело, что вопрос ещё и в убогих запросах, но всё-таки. Возьмём пример: интернет-магазин хочет построить отчёт по покупкам с группировкой по пользователю и статусу (например). Хороший отчёт: сделали группировку по таблице с заказами, потом приджойнили справочники на результате. Плохой отчёт: приджойнили справочники к сырым данным ( вывелифио пользователя, пол и пр.) а потом сгруппировали. Хорошие работают примерно одинаково, плохие раза в 1,5-2 медленнее на 5.7 по сравнению с 5.6. Причина - непонятна. По-тихоньку перепиливаю запросы, но их много и моя скорбь от этого очень велика.

а можно ссылку на десятки отчётов?

Боюсь что нет, поэтому и написал небольшой примерчик, и именно поэтому спросил исключительно в общих чертах изначально.

Не все мы работаем в интернет-магазинах))))

но исходные данные точны. Я держал слейвы на разных версиях от одного мастера, т.е. данные в копейку. Железки в копейку, планы выполнения - тоже

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

ну, без конкретики я вряд ли чего полезного скажу

единственное, что приходит на ум в связи группировкой — в 5.7 переехали на innodb для временных таблиц по умолчанию

он в целом должно быть не хуже. но в особо тяжёлых случаях может выстрелить в ногу

хм, а вот не пробовал, надо попробовать, спасибо!

есть же вроде параметр такой, где-то находил

попробуйте установить internal_tmp_disk_storage=myisam. если поможет, значит оно. и дальше нужно innodb оптимизировать

понял, обязательно попробуем. Спасибо!

@alexey_kopytov планы абсолютно одинаковые, данные одинаковые. Отчётов с деградацией десятки, т.е. проблема массовая. Понятное дело, что вопрос ещё и в убогих запросах, но всё-таки. Возьмём пример: интернет-магазин хочет построить отчёт по покупкам с группировкой по пользователю и статусу (например). Хороший отчёт: сделали группировку по таблице с заказами, потом приджойнили справочники на результате. Плохой отчёт: приджойнили справочники к сырым данным ( вывелифио пользователя, пол и пр.) а потом сгруппировали. Хорошие работают примерно одинаково, плохие раза в 1,5-2 медленнее на 5.7 по сравнению с 5.6. Причина - непонятна. По-тихоньку перепиливаю запросы, но их много и моя скорбь от этого очень велика.

А можешь на sql переписать оба примера? Чтобы нагляднее получилось :)

Они у тебя доступны

Type=all в таких ситуациях обычно бывает на очень маленьких таблицах

так я их юзаю в джйонах и where

Или при косяке

Type=all в таких ситуациях обычно бывает на очень маленьких таблицах

да там вся таблица в 90к

вот я хочу ее допилить немного запрос

Это не маленькая

поэтому просил пример выше

Так там планы были хорошие

А почему у тебя он плохой - пока непонятно.

Сделай analyze table для начала

А, это не тот запрос, что по телефону?

Ты же мне вроде писал

Если там не сделал - вот тебе фуллскан таблицы и есть

Если там не сделал - вот тебе фуллскан таблицы и есть

это другой запрос. реверс в процесс реализации

я пока просто номер телефона вывожу в одном из столбиков

по этой колонке поиска нет

чисто вывод

А поиск по чем?

поиск под ругим таблилицам, explain показывает что там норм поиск

то есть я скрестил 50 таблиц, сделал там поиск. в одной колонке есть клиент id, я потом по этому клиент id еще еще в одной таблице номер телефона и все выводится

Тогда тебе помогут force index и straigh join

записи джойна без разницы в каком порядке?

Да

STRAIGHT_JOIN с ним вместо 80к поиск по 600к)

чот он на пользу не идет)

Но если сервак не догнал сам о порядке ему надо помочь.

Значит не там

я даже убрал ордер-бай из запроса, это не повлияло

Я пока в дороге, чуть попозже давай покажу,

Я пока в дороге, чуть попозже давай покажу,

спасиб

Если хочешь сам задать порядок - поставь старайтесь джойн сразу после селекте и перепиши джойны по порядку

*страйт джойн

знать бы порядок, они вроде и так в нужном порядке стоят

да я думаб деле не в страйтджон

думаю запрос кривой, ты там пример выше напиши) а я свой запрос перепилю)

— ALTER TABLE ClientContact ADD PRIMARY KEY (id), ADD KEY createPerson_id (createPerson_id), ADD KEY modifyPerson_id (modifyPerson_id), ADD KEY client_id (client_id), ADD KEY contactType_id (contactType_id); это значит индексы висят?

или надо create index..?

Да, дай запрос

оказывается replace можно в select воткнуть! это вобще законно?

или лучше потом на стороне клиента менять получаемый ответ?

есть replace функция, а есть replace оператор

это разные вещи