Предыдущий разработчик имеет все свои Select * from TABLE where COLUMN = value;
с дополнительной проверкой, чтобы при выполнении проверок равенства для столбцов типа String предложение where было length(COLUMN) = length(value) and COLUMN = value
.
Причина (как я понимаю) такова что проверка длины может быть быстрее и, следовательно, повысить производительность запросов такого типа. Мои чувства
- , если это касается, почему бы не использовать индекс в БД? (Я не проверял, но они уже могут быть там)
- вероятно ли вообще улучшить запрос, и если вообще будет указывать c для определенного движка или версии БД?
- может ли это быть на самом деле хуже?
- если это будет намного лучше, не будет ли механизм БД выполнять свою собственную проверку под прикрытием? (например, компиляция операторов и оптимизация)
- при каких условиях кто-нибудь на самом деле заметит изменение?
- приводит ли это к некоторому (положительному или отрицательному) побочному эффекту типа БД?
Я полагаю, что изначально он был нацелен на MySQL 5.1, и теперь мы на MySQL 5.7, но мой запрос комментариев не указывает c для них. Мой Google-foo ничего не возвращал в topi c, но он пахнет преждевременной оптимизацией.
Обратите внимание, что они используются только для прямого равенства, обычно в уникальных полях, часто в небольших таблицах, а также часто для перечисление таблиц типов поиска.