>Т.е. речь про: >select * from cont_res cr join contracts ct on cr.cont_id=ct.cont_id >where cr.serv_id=14 and cr.resource is null >?
Да >Твоя правда :-) Кстати, NOT NULL ты таки снять можешь (если там UK, а не >PK). Но не удалить PK, это да. А на что тогда версионность метаданных? Сервер имеет полное право работать в препарированном запросе по старой версии >Насколько я понимаю, тут засада в композитном индексе, где NULL - не >последний сегмент. Я недавно это объяснял Болтику, цитирую: >"Это особенность реализации нуллов в индексах. Для ASC-индексов нуллы >хранятся как ключи нулевой длины. Поэтому при поиске на частичное >соответствие (полей в индексе больше чем в запросе) нулл будет равен >любому другому ключу. Аналогия для индекса с 4 сегментами: >A = a and B = b and C = c : field like 'abc%' >A = a and B = b and C is null : field like 'ab%' >.е. нулл после сегмента B есть, но его при поиске не видно, т.к. это >ключ нулевой длины. Отсюда и шире выборка, больше чтений." >Таким образом, де-факто имеем поиск лишь по первому сегменту >композитного индекса, а им выбираются все 100% значений. Ну значит неправильное какое-то хранение индекса выбрано, если он приводит к неожиданным тормозам там, где их совсем не ожидаешь, и даже по плану не отследишь Сечас время такое, что на объемах экономить не надо. Диски гигантские, память дешевая. А вот скорость оптимизировать наоборот - надо. >Попробуй пересоздать композитный PK как DESC-индекс. В этом случае нуллы >хранятся в виде 0xFF и все должно работать как ожидается. В общем, я вышел из положения создав дополнительный индекс на CONT_RES по двум полям. Благо, сервер его успешно подхватил >Ну, или если ты заранее знаешь, что эта выборка по PK фиктивная, то >добавь в предикат для CONT_RES любое значения столбца CONT_ID, тогда >индексный ключ станет полным и нуллы начнут искаться (и не находиться). Да эта выборка используется как подзапрос другого запроса, и получается что в нее в 95% случаев должен попадать NULL, вот и заметил тормоза Спасибо за участие и консультацию :) P.S. Так ждем 3.0 с реальной многопроцессорностью, что аж сил нет :)
