Slava Rozhnev

...
HAVING COUNT(*) > 1
   AND SUM( (name IN ('зеленый', 'красный')) :: INT ) = 1

[value.language]: i

Вы ничего не считаете, а записываете индекс элемента в массиве. Си у вас идёт в нулевом элементе, вот и получается 0.

Документацию полезно иногда читать.
В ней шрифтом по фону написано, что

To use a literal instance of a special character in a regular expression, precede it by two backslash (\) characters. The MySQL parser interprets one of the backslashes, and the regular expression library interprets the other.

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

Ответ - регулярные выражения, синтаксис чуть сложнее чем * и ? но возможности выше
preg_replace для однобайтовых кодировок или mb_ereg_replace для любых.

регулярное выражение для твоей задачи будет выглядеть примерно так /word.*/ если после слова может присутствовать любое количество любых символов, включая нулевое (иначе использовать .+). Тут точка - это любой символ, а следующий за ним * или + - любое их количество

upd. совсем забыл, preg_replace с модификатором /u понимает utf8 строки

Не добавляются данные в таблицу phpmyadmin?

первый раз работаю с git

В первую очередь вам надо почитать учебник. Git это не та программа, с которой вы сходу можете начать работать. Он конечно простой, но вообще не интуитивно понятный.

выдает 10000 файлов в каталоге

Причина проста — вы инициализировали репозиторий находясь в корне вашего домашнего каталога. Нельзя так делать, если не хотите потерять свои файлы, бездумно вбивая команды типа stash.

Что мне делать

Удалить (или переименовать) подкаталог .git в котором хранится репозиторий. Затем создать его в правильном месте — в каталоге вашего проекта.

Хороший вопрос, хотя и задавался миллион раз.

Когда у вас выполняется запрос

SELECT * FROM users WHERE DATE(created_at) = '2024-04-14'

то СУБД должна пройти весь индекс до конца, получить каждое значение created_at, применить к нему функцию, сравнить с переданным значением, и добавить строку в результат запроса.

Когда у вас выполняется запрос

SELECT * FROM users WHERE created_at BETWEEN '2024-04-14 00:00:00' AND '2024-04-14 23:59:59'

То СУБД находит бинарным поиском первое нужное значение, потом бежит по заранее отсортированному индексу и возвращает все значения до последнего, подходящего под второе условие.

Кластерный индекс... это на самом деле понятие крайне виртуальное.

Что такое обычный некластерный индекс? берём выражение индекса, считаем его значение для каждой записи, сортируем и пишем на диск. Получаем отдельную структуру, в которой выражение индекса сортировано. Когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи сразу половинным делением быстренько найдём нужное значение, возьмём из него уникальный идентификатор записи, и обратимся за записью. Если в таблице 1000 записей, то для поиска заданного значения без индекса нам в среднем пришлось бы просмотреть 500 записей, а с индексом - всего 10.

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

В MySQL (точнее, в используемом по умолчанию движке InnoDB) первичный индекс, во-первых, существует ВСЕГДА, во-вторых, определяется так (в статье, на которую дали ссылку, имеются неточности в пункте 2):

1. Если первичный ключ задан явно, то его выражение является также и выражением кластерного индекса. Или иначе - первичный ключ и есть кластерный индекс.
   
2. Если первичный ключ явно не задан, но в таблице имеется индекс, отвечающий всем следующим требованиям:
   
   • является уникальным
     
   • не является функциональным, в т.ч. не использует в выражении вычисляемые поля
     
   • не использует в выражении поля, которые определены как допускающие значение NULL
     
   
   то именно такой индекс используется в качестве первичного. А если таких индексов несколько, то используется первый по тексту запроса на создание таблицы
   
3. Если не имеется ни того, ни другого - генерируется синтетический скрытый 6-байтовый номер записи, который и используется как первичный ключ. Следует отметить, что штатных способов доступа к этому значению не существует.
   

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

Фактически - именно так.

Создаётся ли отдельная таблица или просто упорядочивается хранение существующих данных?

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

Если данные упорядочиваются этим индексом, допустим по ID, то почему при select без сортировки данные могут возвращаться в произвольном порядке, а не отсортированные по ID по-умолчанию?

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

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

===

PS. Кстати, правило выбора индекса, который будет использоваться в качестве кластерного, имеет неприятный побочный эффект. Если у некоторых полей, входящих в какие-то индексы, изменяется свойство NULLability, то это может привести к изменению того, какой из имеющихся индексов станет использоваться в качестве первичного по пункту 2. В результате мы получим невозможность использования INSTANT / INPLACE методов, и будет использован длинный COPY. Впрочем, ситуация такая крайне редка.

Как сделать так, чтобы из сохраняемого JSON создать новую таблицу

Такой скрипт не должен создавать новые структуры в СУБД, он должен делать только вставки записей (insert-ы) в заранее подготовленные таблицы на этапе проектирования базы данных.

id-question: "идентификатор_вопроса_с_указанием_типа"
answer: "value":<ответ_на_вопрос>
date: "created":"<дата_ответа>"

Вот и создайте эту структуру ручками, create table вам в помощь.

и далее объединить с таблицей, где будут поля

Опять же, при вставке данных в базе не должно происходить модификации самой структуры базы.
Вы при выборке данных сопоставляете данные из одной таблицы с другой таблицей при помощи внешних ключей.
Запрос выборки будет иметь конструкцию join:

select *
 from  Answer A
  join Question Q on Q.id_question = A.id_question -- как раз соединение по ключам
  ...

В общем, учите мат. часть по реляционным СУБД.