Ебанатский дегенератизм - нередкое явление при работе с любыми СУБД, так уж складывается, что их разработкой занимаются довольно странные люди. Режим NO_ZERO_DATE пополняет список ебанизма. По умолчанию он включен с 5.7, и ровно с этого же момента он и начинает портить нам жизнь.

Проблема в том, что несмотря на его наличие, дата '0000-00-00 00:00:00' всё равно КАК-ТО БЛЯДЬ В БАЗУ ПОПАДАЕТ ёб вашу мать, а ошибка

MySQL Incorrect datetime value: '0000-00-00 00:00:00'

появляется только тогда, когда у вас горят сроки и надо в продакшене срочно что-то поправить. Ну естественно.

Поэтому мы делаем следующее:

  1. Мысленно посылаем инноваторов, внедривших NO_ZERO_DATE сначала в пизду, затем нахуй, а после - в ёбаный сатанинский ад.
  2. Заходим под root пользователем в базу.
  3. Выполняем запрос
SHOW VARIABLES LIKE 'sql_mode';

читире. Получаем в ответ что-то вроде "ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_..."
5. Ищем полчаса блядскую галочку "Full texts", спрятанную разработчиками phpMyAdmin в мелкошрифтную ссылку + Options.
6. Получаем в ответ что-то вроде

ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

сем. Вычёркивам нахуй этот сучий гонорежим NO_ZERO_DATE.
8. Выполняем что-то вроде

SET GLOBAL sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

девить. Пишем пост в интернете про это блядство.
10. Охуеваем от того, что wordpress превращает вручную набранные цифры в списки и сбрасывает блядскую нумерацию, ведь до этого момента такого никогда еще не происходило. Ни разу.
11. Понимаем, что вести войну с вордпрессом нет уже ни сил, ни времени, ни желания.
12. Идём отвечать на 45 пропущенных звонков и 194 новых письма, накопившихся, пока мы исправляли этот внезапно свалившийся на голову дятлоебизм.

Имеем таблицу, в которой строки ссылаются друг на друга по pid, либо вообще не ссылаются никак (pid=null). Делаем запрос:

SELECT *
FROM `tasks`
WHERE `tasks`.`id` NOT IN (SELECT DISTINCT `pid` FROM `tasks`)

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

SELECT *
FROM `tasks`
WHERE `tasks`.`id` NOT IN (496,NULL)

Упрощаем запрос до минимального

SELECT *
FROM `tasks`
WHERE `tasks`.`id` NOT IN (NULL)

Результат запроса: хуй (0 строк). Пишем:

EXPLAIN SELECT *
FROM `tasks`
WHERE `tasks`.`id` NOT IN (NULL)

Получаем:

Array ( [id] => 1 [select_type] => SIMPLE [table] => [type] => [possible_keys] => [key] => [key_len] => [ref] => [rows] => [Extra] => Impossible WHERE noticed after reading const tables )


Теперь необходимо переписать сраные 50 запросов, каджый из которых довольно сложен и в нужных местах повставлять OR IS NULL и OR IS NOT NULL, потомучто раньше вместо NULL был объект-костыль с ID=-1.

UPD:

Ха. Ха. Ха. Пехепе меня решило добить. Данные в выборке есть, а в результате - нет. Ну, об этом гениальном быдлопассаже я уже писал.