don.bidon совершенно прав. Речь совершенно определённо о mysql, значит совершенно рядовой btree и никаких триграмных индексов. btree не может эффективно ускорять like '%const%' запросы.
Планировщик в принципе может сказать, что пойдёт в индекс - но лишь чтобы прочитать полностью весь индекс потому что он чуть компактнее чем вся таблица.
Lolya пишет:
Получаем ид, потом в торрент-табле.пхп подключать через него весь основной обвес старого запроса в цикле. Но это выходит не 1 запрос на страницу с 25 фильмами, а 1+25=26. Да, они будут быстрыми по исполнению
Не будут. Даже на смешных объёмах данных в сотни тысяч строк.
Lolya пишет:
перечисленными через запятую для каждой новой строчки-новости
Сначала приведите в нормальную форму.
Затем уже можно думать, какую дальнейшую задачу необходимо решать. Поиск по тегам? В нормальной форме элементарен.
Похожие слова как подсказка ввода? Это like 'const%' обычно, чудесно работающие по btree т.к. префиксный поиск.
Похожие теги относительно того тега что сейчас смотрит пользователь? Отдельная таблица, из веба только читаемая, а заполняемая асинхронно в фоне (крон, брокер очередей, etc)
К примерно половине индексов показанных в начале темы есть вопросы "зачем оно вам понадобилось".
Кстати, что вы можете сказать по поводу решения ботом задач по арифметике?
То могу сказать, что это хорошая классическая учебная задача по программированию. Правильное направление - обратная польская запись, "Reverse Polish notation".
При $b = 12; получаем константу в $condition как результат конкатенации строки с числом.
$string = 'a = 12';
или
$string = 'a = '.$b;
у вас удивления не вызывает? Что в $string окажется строка "a = 12"?
А в чём разница с $string = '$a = '.$b; или $string = '#a = '.$b; ? Никакой разницы. Конкатенация строки и переменной (приводимой к строке).
Могу попробовать угадать, что вы хотите сделать что-то вроде:
А почему бы должно работать? Сравниваете несуществующую переменную $b и число 12. Потом присваиваете переменной $condition результат сравнения строки с несуществующей переменной. В этот самым момент условие и вычисляется. Таким образом в array_filter передаёте константное условие и, следовательно, сам array_filter лишний.
Для нескольких запросов последовательно в рамках одного tcp коннекта не делайте curl_close, а формируйте следующий запрос в рамках всё того же ресурса.
И? Да хоть бинарного мусора. password_hash и password_verify как-то без разницы.
Olegarh1a пишет:
как правильно фильтровать или экранировать ?
Зачем?
Вот не поверите - неверен сам вопрос.
Верный вопрос:
- как передать значение в SQL так, чтобы СУБД не могла воспринять часть данных за команду
- как представить данные в HTML так, чтобы браузер отображал именно эти данные, а не считал что это разметка
- как корректно использовать данные в любом_заданном_формате, чтобы они воспринимались как эти самые данные при чтении этого самого заранее известного формата
"оой, ну наверное кавычки это страшная хакерская штука, их не должно быть в пароле"? "ой, уравнение a<b and b>c никто в здравом уме не напишет, это же опаснейших HTML тег"?
Вам нужно подставить данные в CSV? Что, будете удалять все запятые из текста? Да нет, конечно. Возьмёте не менее стандартные функции форматирования CSV
Нужно передать JSON? Реально будете вырезать регуляркой всё, что имеет значение в JSON? Опять нет. Возьмёте стандартный json_encode
Нужно подставить параметр в ссылку? urlencode к вашим услугам.
Вам нужно вывести данные в HTML? htmlspecialchars.
Передать данные базе данных? У каждой базы есть родной интерфейс для этого. В частности, механизм prepared statements.
На сладкое мой любимый пример:
Введите сумму перевода: _
Везде проверили, что прислали число, что у пользователя есть столько денег, пользователь существует. Всё отлично, делаем одному balance = balance + ?, второму вычитаем с баланса
А потом некто просто вводит отрицательное число.
Потому второй верный вопрос: какие данные мы тут ожидаем и где их будем использовать.
Проверьте минимальную длину пароля. Всё. Какая вам разница, какой пароль хочет использовать пользователь? Какой смысл в ограничении всего лишь в 30 символов?
"в программировании есть только две сложные вещи: инвалидация кеша, выбор имени переменной, и ошибки на единицу" (Джефф Этвуд)
При обновлении данных сбрасывайте связанные с этими данными кэши. Возможно потребует порядком усилий для поиска всех мест, откуда изменения выполняются.
SELECT d FROM generate_series('2020-12-01','2020-12-07', interval '1 day') d WHERENOTEXISTS(SELECTFROM tablename WHERE created_at >= d AND created_at < d + interval '1 day')
Запросите свой скрипт curl'ом и посмотрите внимательно (любой hex редактор в помощь) что именно у вас в ответе получается. Может BOM или ещё что сложно-заметное, может order_id пустой
MariaDB [test]>SELECT*FROM speedlimit WHERE lim >20;
Empty SET(0.000 sec)
MariaDB [test]>SELECT*FROM speedlimit WHERE lim >'20';
+------+------+
| i | lim |
+------+------+
| 2 | 60 |
| 3 | 60 |
+------+------+
2 rows INSET(0.000 sec)
Всё понятно почему работает именно так? Будет ли это понятно вашим коллегам тоже? А тому, кто будет читать код через год?
В общем, не надо в enum числа использовать. Работает оно как задокументировано в мануале, но порой неожиданно для неподготовленного наблюдателя.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 11869
