Очевидно, что простым сравнением тут не обойдешься:
SELECT '2007-07-01' = '20070701'
#= 0
В данном случае MySQL считает оба значения строками и сравнивает их
лексикографически. В итоге получаем 0.

Для указания того, что мы работаем не со строками а с датами,
необходимо выполнить конверсию типов (или тайпкастинг).
Делается это с помощью функции CAST():
SELECT CAST('2007-07-01' AS DATE) = CAST('20070701' AS DATE);
#= 1

В случае когда MySQL "знает" тип одного из операндов, второй
приводится к этому типу автоматически:
SELECT '2007-07-01' = CAST('20070701' AS DATE);
#= 1
Аналогичная ситуация наблюдается если слева будет указано поле таблицы
- в таком случае второй операнд будет приводиться к типу этого поля.
Например:
SELECT myDatField FROM myTable LIMIT 1\G
myDatField=2007-07-01

SELECT myDatField=20070101 AS res FROM myTable LIMIT 1\G
res=1

Но такое поведение наблюдается только в случае, если не происходит
автоматическа конвертация из CHAR в INT и наоборот.
Пример:
SELECT '20070701'=CAST('2007-07-01' AS DATE);
#=0
# но в то же время
SELECT '2007-07-01 =CAST('20070701  AS DATE)
#=1

Или же ещё один пример (IMHO более презентабельный):

SELECT CAST('20070101  AS DATE)=CAST('20070101  AS UNSIGNED INTEGER);
#= 0
# Тут вопросов быть не должно, т.к. слева получаем что-то вроде
"2007-01-01
# но при этом
SELECT CAST('10  AS SIGNED INTEGER)=CAST('10  AS CHAR);
#= 1
# тут уже имеем автоматическую CHAR<->INT конверсию

Стоит добавить что в результате конверсии типов (как явной так и
неявной) возможно "выпадание" индекса из сценария запроса, что
приводит к существенному понижению производительности.