SQL Server, где сравнения пунктов с различными типами и поведением кастинга значения по умолчанию
Я выяснил, что значения TimeStamp не являются строковыми. Спасибо @meW за упоминание о том, что в данных могут быть некоторые проблемы.
Итак, я преобразовал значения в строку перед преобразованием времени строковых данных в эпоху.
dataframe['TimeStamp'] = dataframe['TimeStamp'].astype(str)
dataframe['TimeStamp'] = pd.to_datetime(dataframe['TimeStamp'])
.values.astype(np.int64) // 10 ** 6
6 ответов
Data type precedence is well defined - http://msdn.microsoft.com/en-us/library/ms190309.aspx
Edit - to clarify, it is not that sql always converts the column type to the param type. It just follows the type precedence in the link I gave. This could mean the param gets converted to the column type, if the type precedence dictates so.
Я не вижу, в чем проблема. Почему SQL-сервер знает, что запись # 232 из 1000 будет бомбить? Нет, пока не доберется до этой записи.
Между тем, он передает результаты обратно клиенту по мере их генерирования. Это поможет повысить производительность.
Чего еще ожидать?
Вы прекрасно описываете, что происходит, поэтому я не понимаю, что вы хотели бы знать, чего еще не знаете?
Исправить запрос достаточно просто, просто спросите Sql Сервер для преобразования вашего параметра в varchar вместо преобразования столбца varchar в bigint:
SELECT * FROM Phones WHERE Mobile = cast(@biMobile_1 as varchar(50))
Ваше логическое описание процесса действительно правильное.
SQL Server - это простота, применяя функцию Cast / Convert к мобильному столбцу (в данном случае неявное преобразование из nvarchar). в Bigint). Функции, конечно, применяются по принципу строка за строкой , и, следовательно, поведение, которое вы наблюдаете, в результате чего оператор SELECT не выполняет бомбардировку, пока не прекратится функция приведения.
Эту проблему можно избежать путем преобразования одиночная числовая переменная, которая ищется (@ biMobile_2) для nvarchar, вместо того, чтобы неявно преобразовывать столбец Mobile для всех строк.
Например:
SELECT * FROM Phones WHERE Mobile = convert(nvarchar,@biMobile_2)
Надеюсь, это поможет.
Проблема в том, что неявное преобразование из nvarchar в bigint недопустимо, только если содержимое nvarchar содержит нечисловые символы. Ядро базы данных не будет выполнять запрос один раз только для того, чтобы проверить каждое значение, которое будет возвращено , чтобы убедиться, что отправленный вами запрос действителен для каждой строки, только для того, чтобы затем развернуться и выполнить запрос снова, чтобы вернуть результаты.
Выполнение запроса и возврат данных начинается до тех пор, пока не будет найдено сравнение, которое окажется недействительным.
Лично вместо того, чтобы преобразовывать параметр в правильный тип, я бы для начала объявил его как этот тип.