тайпкастинг
A4
запросов, расскажу немного о том, как можно этой конверсией управлять.
Предположим у нас есть 2 одинаковых даты, но в разных форматах:
'2007-07-01 и '20070701 .
Необходимо средствами БД (например в SQL-запросе) ставнить их на
равенство:
Очевидно, что простым сравнением тут не обойдешься:
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 конверсию
Стоит добавить что в результате конверсии типов (как явной так и
неявной) возможно "выпадание" индекса из сценария запроса, что
приводит к существенному понижению производительности.