Akina

Если значение поля с типом TIMESTAMP некорректно (а пустая строка - это некорректное значение) - надо заменить его на корректное.

• Если поле NULLable - то например на NULL.
  
• Если настройки допускают нулевую дату - то на `0000-00-00 00:00:00`.
  
• Иначе - на некое предопределённое значение. В зависимости от смысла поля - либо в далёком прошлом, либо в столь же далёком будущем.
  

Прочитал, что в mysql в движке innodb индексы делятся на два больших типа - первичный и вторичный

Понятия первичного и вторичного индексов никак не связаны с СУБД. И это не типы индексов по большому счёту. Просто первичный - однозначно идентифицирует запись (что определяется ограничениями на значение выражения и используемых в нём полей), тогда как вторичный - всего лишь может использоваться для однозначной идентификации, но лишь при условии, что он отвечает всем требованиям-ограничениям для первичного.

В InnoDB - всего лишь есть дополнение, что при наличии первичного индекса он является также и кластерным. Для других движков и других СУБД такой зависимости может и не быть.

кластеризованный, как написано хранится с данными

Не-а. Кластерный индекс - это когда записи в теле таблицы (т.е. сами данные таблицы) хранятся в порядке сортировки по выражению этого кластерного индекса.

Всегда ли не кластиризованные индексы хранятся в оперативной памяти или это как-то можно регулировать?

Индексы всегда хранятся на диске. В оперативной памяти индексы могут всего лишь кэшироваться. Для ускорения доступа.

Я слышал что индексы должны быть в пределах мегабайт, а не гигабайт.

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

Читал, что бывает так, что индекс в таблице индекса хранит сразу данные определенных столбцов, а не ссылки на эти строки в основной таблице.

Вероятно, речь про INCLUDE-предложение в структуре индекса, имеющееся, например, в SQL Server... т.е. значения полей хранятся в выражении индекса как дополнительные данные, и не используются при сортировке.

Два LEFT JOIN, условие связывания - по id и определённому значению типа.

SELECT *
FROM Author
WHERE NOT EXISTS (
    SELECT NULL
    FROM Book
    WHERE Author.Authorld = Book.Authorld
      AND Book.PublishDateTime >= CURRENT_DATE - INTERVAL 2 YEAR
    )

SELECT table1.*, 
       EXISTS ( SELECT NULL
                FROM table2
                WHERE table2.table1_id = table1.id
                   AND table2.date = @needed_date
                ) AS row_exists
FROM table1

Если точная дата внутри месяца неизвестна, то

WHERE table2.date BETWEEN @needed_month_1st_day AND @needed_month_last_day

• Выделить диапазон с числами.
  
• Alt-F11
  
• Ctrl-G
  
• ввести

  for each onecell in selection:onecell.value="https://d21skl.com/"&onecell.value:next

  
  
• Enter
  
• Alt-F4
  
• Alt-F4
  
  

А решение было близко... раз нужны данные с разных уровней группировки, то либо вертеть подзапросы/CTE, либо использовать оконные функции. Как по мне, второе проще.

SELECT DISTINCT
       product_id,
       size,
       SUM(orders) OVER (PARTITION BY product_id, warehouse_id, size) AS orders,
       FIRST_VALUE(stocks) OVER (PARTITION BY product_id, warehouse_id, size 
                                 ORDER BY `date` DESC) AS stocks,
       warehouse_id
FROM stats
WHERE DATE(`date`) >= '2023-09-01' 
  AND DATE(`date`) <= '2023-09-04';

fiddle

созданы два дополнительных сайта на LARAVEL, с одинаковыми каталогами товаров.

Фраза интенсивно намекает, что эти сайты - полная копия основного. То есть и код, и, главное, структура БД, совпадают с точностью до запятой.

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

Если это по какой-то причине невозможно - то обновление стоимости товаров оформляется в виде необходимых для выполнения операции наборов INSERT/UPDATE/DELETE запросов и выполняется на всех трёх серверах.

Стоимость товаров часто меняется, и менять цены руками на всех сайтах, основном и региональных - трудозатратно.

Если это можно, хотя и затратно, сделать руками - то с точки зрения СУБД это ни разу не "часто", а наоборот - чертовски редко.

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

Произвольный текст, не содержащий тегов, является валидным содержимым, но не XML документом. Не-XML фрагмент игнорируется при проверке.

Попробуйте вставить нечто, являющееся документом/фрагментом XML, но с ошибкой в разметке - тут же схлопочете ошибку.
DEMO

В матрице Z(0..m, 0..n) элемент X(a,b) является соседом элемента Y(c,d), если выполняются условия

((a-b) MOD (m+1)) входит в {0, 1, m}
((c-d) MOD (n+1)) входит в {0, 1, n}

В случае, если соседи определяются только по вертикали/горизонтали, но не по диагонали, то одно из выражений должно быть нулём. Если только по диагонали - нуля быть не должно. Если оба выражения нулевые.. догадайся сам.

PS. MOD - оператор получения остатка от целочисленного деления.

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

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

Хотим открыть общий доступ к файлам Microsoft Office по сети, чтобы пользователи могли редактировать, но не удалять файлы.

Ставим сетевую корзину (программа третьей стороны, практически любая подойдёт, лишь бы запоминала, кто удалил). Удалённый файл, в отличие от обычной процедуры в Windows, не уходит в никуда, а помещается в сетевую корзину.

Если туда попал именно окончательно удалённый файл (а не удалённый в связи с созданием новой версии) - восстанавливаем, а потом находим виновного и выписываем ему крепких и качественных звездюлей. Без последнего этапа схема практически не работает - как удаляли что не надо, так и будут удалять..

Для решения задачи набор искомых значений должен быть (синтетическим) набором записей, который используется в источнике данных запроса.