Коллеги, я тут вчера возился с запросцами, и хочу попросить консультации/brainstorm по оптимизации некоторых определенных запросов: https://docs.google.com/document/d/1pvGvKMZoiMCdadLrDElnSlIvG... спасибо!
там надо сделать две вещи (которые не помогут принципиально): 1) убрать nullability с полей timeline_id, post_id, fresh_at, чтобы индекс был четче. ‎- псы в рапиде
2) вместо явного запроса с перечислением адского списка айдишников сделать subquery (которая соптимизируется в JOIN, я проверял). это улучшит ситуацию, но не принципиально. ‎- псы в рапиде
(попробовал сымитировать в постгресе, если интересно — https://gist.github.com/little-arhat/a0da88c846ecb7cdf30b ) ‎- адский хардлайн в засаде
@larhat: я с места не понимаю, что там в плане. ‎- псы в рапиде
@larhat великовата разница между actual и estimate. но придумать лучший план чо-то не получается ‎- urquan
@squadette а ты их оптимизируешь потому что они тормозят или потому что в плане filesort написано? (потому что так-то filesort - это сорт в памяти, если данных немного, а у тебя в типовом случае это десятки килобайт) ‎- Monkey Ping
@elephantum: я на самом деле мечусь в панике. :) ну и я думал что есть простой алгоритм денормализации, чтобы восхититься ) ‎- псы в рапиде
http://www.slideshare.net/myxplain/mysql-indexing-best-practi... слайд номер 40, "unionizing filesort". для нашей задачи толку ноль, но подход понятный. ‎- псы в рапиде
еще я думал о том, чтобы джойнить таблицу саму с собой с двумя выборками (и добавить индекс по полям fresh_at и created_at) ‎- псы в рапиде
@squadette а почему ты не хочешь сделать индекс (fresh_at, timeline_id)? или в mysql он всё равно в твоём случае не будет использоваться для сортировки? в постгресе он используется, если в таком порядке. А если как у тебя — то тоже сорт в памяти + bitmap сканы. Кстати, а есть в mysql аналог постгревого analyze'а, чтобы с шагами и оценками? ‎- адский хардлайн в засаде