> тройной индекс может помочь.
Он определённо поможет. Сейчас у ТС идёт array merge двух индексов (тоже не самая простая штука), но группировка во временной таблице, при том группировка без малого 400тыс. записей — быстрой не может быть.
А индекс по checked, taken, task_id позволит группировать этот запрос по индесу, плюс, если запрашиваются только поля индекса — index scan, не стоящий почти ничего.
Так же подойдёт индекс по taken, checked, task_id
А вот task_id на первом месте — оптимизатор сразу откинет этот индекс как неподходящий, по нему ничего отфильтровать нельзя.
edogs, ошибаетесь. Этот приём называется «покрывающий индекс» — когда данных в индексе достаточно для ответа на запрос и данные не поднимаются вовсе.
Но поля селекта обрабатываются только после group — и если task_id поставить на первое место индекса — это индекс будет вообще неприменим для этого запроса, т.к. не отвечает необходимости левостороннего размещения полей. Чтобы узнать значения в select, сперва надо обработать where и group.
Потому что в составных индексах порядок столбцов имеет первостепенную важность. Если правда интересно — рекомендую книгу «MySQL. Оптимизация производительности», Бэрон Шварц. Много правильных вещей объясняется.
Если коротко и только на этом примере:
Чтобы было возможно сгруппировать результат по индексу, все поля, участвующие в where должны стоять левее в индексе. Сперва исполняется where, только потом — group. Если индекс не охватывает полностью where, для группировки он непригоден.
> Забавно, что ни один из трех основных поисковиков не умеет сортировать результаты по дате.
Яндекс, внизу страницы «Отсортировано по релевантности по дате»?
> Про какие, например, округления вы говорите?
Postgres, тип поля float:
update floattest set val=0.05;
update floattest set val=val+10000;
update floattest set val=val-10000;
-- всё штатные транзакции не так ли?
select val from floattest ;
=> 0.0499999999992724
А хде мои 50 копеек? Вот тут и придётся округлять.
> Поясните, пожалуйста.
См. пример выше. Просто встречается значительно чаще, что баланс на ровном месте гуляет вокруг нуля, внезапно отрицателен, но очень редко, когда действительно равен 0.
А вот что с этим делать для поддержки разных версий PHP — править ключи после var_export или делать свою реализацию. Ну или задокументировать как фичу.
Ну если есть куда — то сделайте посекторную копию диска и спокойно можно играться.
Да, именно стоит после описанных манипуляций запустить с дистрибьютива семёрки восстановление загрузки.
Возможно, силами какого-нибудь gparted понадобится подвинуть раздел, чтобы освободить те самые пару сот мб места.
Например, /dev/sda1 начинается с 64 сектора и заканчивается на 1024000 секторе. Мы хотим его выкинуть из массива, сохранив данные:
0) выкидываем из массива
1) записываем куда-нибудь в блокнот исходные его координаты
2) удаляем раздел
3) создаём на его месте новый раздел, смещая его старт на 2048 секторов, т.е. новый раздел будет начинаться с сектора 2112 и заканчиваться всё тем же 1024000 сектором.
4) всё, можно монтировать раздел как обычную ФС.
Само собой, сперва отмонтируйте раздел, иначе ФС не гарантирует свою консистентность.
Оговорка про раздел или диск относится к тому, что в массив можно отдать и напрямую весь диск, например массив /dev/md3 из /dev/sda2 и /dev/sdb
В этом случае в первых 2048 секторах как /dev/sda2, так и /dev/sdb будут метаданные mdadm, а после них — непрерывно данные до последнего сектора.
Он определённо поможет. Сейчас у ТС идёт array merge двух индексов (тоже не самая простая штука), но группировка во временной таблице, при том группировка без малого 400тыс. записей — быстрой не может быть.
А индекс по checked, taken, task_id позволит группировать этот запрос по индесу, плюс, если запрашиваются только поля индекса — index scan, не стоящий почти ничего.
Так же подойдёт индекс по taken, checked, task_id
А вот task_id на первом месте — оптимизатор сразу откинет этот индекс как неподходящий, по нему ничего отфильтровать нельзя.