SELECT id, c_name
FROM `campaign`
WHERE c_status != '1'
AND user_id = '1'
ORDER BY RAND()
а еще и со статусом поколдовать...WHERE c_status != '1'
Если отсортировать записи по 1 + 2, взять (1 + 2) тридцатой из них, и поделить это на 1.43, то получим такое хорошее число, что записи, имеющие 1+2 меньше оного нас в принципе не интересуют при любом раскладе случайности1. Бюджет - 35% коэффициент значимости
2. Стоимость перехода по ссылке - 35% -//-//-//-
3. Случайность - 30% -//-//-//-
я читал здесь. народ уже рассказал, что индекса строются по схеме b-tree, который допускает "быстрый" поиск ( кол-во шагов = sqrt(n), где n- общее кол-во записей ) только по условию равноА что, существует реальная разница в производительности между WHERE id = '0' и WHERE id != '1'? С чем это связано? Где почитать можно?
Попробую подругому ...Необходимо вывести все значения id, c_name отсортированные в порядке убывания по "значимости" с лимитом к примеру 50 (на страницу). За значимость отвечают три параметра:
1. Бюджет - 35% коэффициент значимости
2. Стоимость перехода по ссылке - 35% -//-//-//-
3. Случайность - 30% -//-//-//-
а не O(ln(n)) ?что индекса строются по схеме b-tree, который допускает "быстрый" поиск ( кол-во шагов = sqrt(n), где n- общее кол-во записей )
тогда уж log2(n)а не O(ln(n))
1. Алгоритм поиска по бинарному дереву.
Суть этого алгоритма достаточно проста. Представим себе, что у нас есть набор карточек с телефонными номерами и адресами людей. Карточки отсортированы в порядке возрастания телефонных номеров. Необходимо найти адрес человека, если мы знаем, что его номер телефона 222-22-22. Наши действия? Берем карточку из середины пачки, номер карточки 444-44-44. Сравнивая его с искомым номером, мы видим, что наш меньше и , значит, находится точно в первой половине пачки. Смело откладываем вторую часть пачки в сторону, она нам не нужна, массив поиска мы сузили ровно в два раза. Теперь берем карточку из середины оставшейся пачки, на ней номер 123-45-67. Из чего следует, что нужная нам карточка лежит во второй половине оставшейся пачки... Таким образом , при каждом сравнении , мы уменьшаем зону поиска в два раза. Отсюда и название метода - половинного деления или дихотомии.
Не буду приводить математического доказательства, так как это не является целью данной статьи, а просто отмечу, что скорость сходимости этого алгоритма пропорциональна Log(2)N ? . Это означает буквально то, что не более, чем через Log(2)N сравнений , мы либо найдем нужное значение, либо убедимся в его отсутствии.
1) если ты делаешь такую поправку, то ты не понимаешь смысла символа O(). http://algolist.manual.ru/misc/o_n.php - велкам.тогда уж log2(n)
это почему же в индексе - дерево не бинарное?если тебя интересует именно конкретика, то там основание явно не 2, потому что дерево у нас все-таки не бинарное.