sql-запрос, обрабатывающий int как строку - проблемы?

Question

Если я сделать запрос, как этот

SELECT * from Foo where Bar = '42' 

и Bar является ИНТ столбец. Будет ли это строковое значение оптимизировано до 42 в движке db? Будет ли это иметь какое-то воздействие, если я оставить его, как это вместо того, чтобы изменить его на:

Select * from Foo where Bar = 42 

Это делается на SQL Compact базы данных, если это делает разницу.
Я знаю, что это не правильный способ сделать это, но это большая боль, хотя весь код смотрит на каждый запрос и схему БД, чтобы увидеть, является ли столбец типом int или нет.

Answer 1

SQL Server автоматически преобразует его в INT, что из-за INT имеет higher precedence чем VARCHAR.

Вы также должны знать о влиянии, которое неявные преобразования могут иметь значения . Для того, чтобы продемонстрировать, что я имею в виду, я создал и заселена следующую таблицу в базе данных AdventureWorks2008:

USE AdventureWorks2008; 

IF OBJECT_ID ('ProductInfo', 'U') IS NOT NULL 
DROP TABLE ProductInfo; 

CREATE TABLE ProductInfo 
(
    ProductID NVARCHAR(10) NOT NULL PRIMARY KEY, 
    ProductName NVARCHAR(50) NOT NULL 
); 

INSERT INTO ProductInfo 
SELECT ProductID, Name 
FROM Production.Product; 

Как вы можете видеть, таблица содержит первичный ключ, выполненный с типом данных NVARCHAR. Поскольку столбец ProductID является первичным ключом, будет автоматически настроен с кластеризованным индексом.Далее я набора статистика IO, чтобы на так я могу посмотреть информацию о диске деятельности:

SET STATISTICS IO ON; 

Затем я запускаю следующий ЗЕЬЕСТ для получения продукта информации для продукта 350:

SELECT ProductID, ProductName 
FROM ProductInfo 
WHERE ProductID = 350; 

Поскольку статистика IO включена, мои результаты включают в себя следующее информация:

Таблица 'ProductInfo'. Количество сканирования 1, логического чтения 6, физических чтений 0, упреждающего чтения читает 0, нескладный логический читает 0, нескладный физической читает 0, подбросить упреждающего чтения читает 0.

Два важных пунктов, чтобы заметить, что запрос выполнил сканирование и , что для получения данных потребовалось шесть логических чтений. Поскольку в предложении WHERE указано значение в столбце первичного ключа как часть условия поиска , я бы ожидал, что будет выполняться поиск индекса, , а не сканирование. Как показано на рисунке ниже, механизм базы данных выполнил сканирование, а не поиск. На следующем рисунке показаны детали этого сканирования (доступ к которому осуществляется путем наведения указателя мыши на значок сканирования).

Обратите внимание, что в разделе Predicate, функция CONVERT_IMPLICIT является используется для преобразования значений в столбце ProductID для того, чтобы сравнить их со значением 350 (представлен @ 1) Я перешел в пункт WHERE. Причина, по которой данные неявно конвертируются , состоит в том, что я передал значение 350 в качестве целочисленного значения, а не значение , поэтому SQL Server преобразует все значения ProductID в целые числа , чтобы выполнить сравнения.

Поскольку в таблице ProductInfo относительно мало строк, производительность в этом случае не очень важна. Но если ваша таблица содержит миллионы строк, вы говорите о серьезном ударе по производительности. Способ обойти это, конечно, пройти в 350 аргумента в виде строки, как я сделал в следующем примере:

SELECT ProductID, ProductName 
FROM ProductInfo 
WHERE ProductID = '350'; 

еще раз, оператор возвращает информацию о продукте и данные статистики IO, как показано в следующих результатах:

Теперь этот указатель правильно используется для определения местоположения записи. И если вы видите , см. Рисунок ниже, вы увидите, что значения в столбце ProductID больше не будут неявно конвертированы перед сравнением с 350, указанными в условии поиска.

Как показывает этот пример, вы должны быть осведомлены о том, как производительность может зависеть от неявных преобразований, так же, как вы должны быть знать о любых типов неявных преобразований, проводимых по базе данных базы данных . По этой причине вы часто захотите явно преобразовать ваши данные, чтобы вы могли контролировать влияние этого преобразования.

Вы можете узнать больше о Data Conversion in SQL Server.

Answer 2

Если вы посмотрите на MSDN chart, который рассказывает о неявном преобразовании, вы обнаружите, что строка неявно преобразуется в int.

Answer 3

оба должны работать в вашем случае, но Нормативы является использование цитаты в любом случае. cuz если это работа.

Select * из Foo где бар = 42

это не

Select * из Foo где бар =% 42%

и это будет

SELECT * из Foo где бар = '% 42%'

ps: вы все равно должны взглянуть на структуру сущности и запрос linq, это упростит ...

Answer 4

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

Мое предложение в статье WHERE, если вы сравниваете integer, не ставьте одинарной кавычки. это лучшая практика, чтобы избежать ошибки и неожиданного результата.

Answer 5

Вы должны использовать всегда параметры при выполнении sql кодом, чтобы избежать недостатков безопасности (EJ: Sql injection).