Выберите “где пункт” порядок оценки
Я также столкнулся с этой проблемой. Я хотел иметь возможность повторно использовать код во многих EditTexts. Это мое решение:
Использование:
CurrencyFormat watcher = new CurrencyFormat();
priceEditText.addTextChangedListener(watcher);
Класс:
public static class CurrencyFormat implements TextWatcher {
public void onTextChanged(CharSequence arg0, int start, int arg2,int arg3) {}
public void beforeTextChanged(CharSequence arg0, int start,int arg2, int arg3) {}
public void afterTextChanged(Editable arg0) {
int length = arg0.length();
if(length>0){
if(nrOfDecimal(arg0.toString())>2)
arg0.delete(length-1, length);
}
}
private int nrOfDecimal(String nr){
int len = nr.length();
int pos = len;
for(int i=0 ; i<len; i++){
if(nr.charAt(i)=='.'){
pos=i+1;
break;
}
}
return len-pos;
}
}
7 ответов
Нет никаких гарантий порядка оценки. Оптимизатор попытается найти самый эффективный способ выполнить запрос, с помощью доступной информации.
В Вашем случае, так как c индексируется, и d не, оптимизатор должен изучить индекс для нахождения всех строк, которые соответствуют предикату на c, затем получают те строки от данных таблицы для оценки предиката на d.
Однако, если это решает, что индекс на c не является очень выборочным (хотя не в Вашем примере, гендерный столбец редко полезно индексируется), он может решить сделать сканирование таблицы так или иначе.
Для определения порядка выполнения необходимо получить объяснить план относительно запроса. Однако поймите, что тот план может измениться в зависимости от того, что думает оптимизатор, лучший запрос прямо сейчас.
SQL Server генерирует оптимизированный план относительно каждого оператора, который он выполняет. Вы не должны приказывать, чтобы Ваш где пункт извлек ту пользу. Единственный garuntee, который Вы имеете, - то, что это выполнит операторы в порядке так:
SELECT A FROM B WHERE C
SELECT D FROM E WHERE F
выполнит первую строку перед вторым.
Можно посмотреть на план выполнения запроса и определить то, что он на самом деле пытается сделать. Я думаю, что механизм запроса SQL Server, как предполагается, делает этот тип сканирования и разумно переведет его в операции. Как, если Вы делаете "дорогой-op И ложный", это быстро оценит ко лжи.
Из того, что я учился, что Вы вводите, (и может быть), отличающийся от того, что на самом деле выполняется. Вы просто говорите сервер, какие результаты Вы ожидаете. Как это добирается, ответ не коррелирует слева направо кода, который Вы предоставляете.
Если Вы хотите быть уверенными, что можно проверить План Выполнения запросов. План выполнения, который создает/оптимизирует MSSQL, достаточно умен для проверки индексированного столбца перед varchar столбцом.
Оптимизатор запросов SQL Server MS действительно срывает, да. Гарантируемый.
Выполнение это:
select 1 where 1 = 0 and 1 / 0 = 10
Это будет работать очень хорошо и не ошибка даже при том, что Вы делитесь на нуль, потому что оптимизатор запросов закоротит, оценивают где пункт. Это имеет последствия для любого, где пункт, где Вы "и" - луг и один из и части, является константой.
Один способ управлять порядком оценки с выражением CASE.
[Редактирование]
популярное мнение, которое я пытался выразить, было:
Вы не можете зависеть от порядка вычисления выражения на вещи как “WHERE ИЛИ вЂњ, так как оптимизатор мог бы выбрать план, который оценивает второй предикат перед первым. Но порядок оценки выражений в Операторе выбора фиксируется, таким образом, можно зависеть от детерминированной оценки короткого замыкания Оператора выбора.
Это действительно становится немного более сложным, чем это, как объяснено в сайте ниже:
Короткое замыкание выполняется, когда условие, на которое мы ссылаемся, включает только литералы или константы. Так, например, допустим, что у нас есть таблица TableA, в которой есть столбец num со всеми положительными числами от 1 до 10, а затем, если я напишу этот запрос.
Выберите num из TableA, ГДЕ TableA.num <0 И 1/0 = 10.
Это приведет к ошибке.
Достаточно ли умен компилятора, чтобы определить, что мое второе предложение состоит из констант, поэтому он должен оценить это перед вычислением предложения, которое требует любого сканирования из таблицы или индекса?