> это значительно сократит скорость выборки.
хорошая оговорка ;-)
Партицирование данных — да, попробовать можно.
> IP хранить как 4 части по 3 знака int. + сделать индекс: на каждую часть, на 1+2 часть и 2+3 часть.
И в чём смысл, кроме как раздуть объём базы? ip и есть unsigned int сам по себе.
А индексы по ip здесь использоваться не будут. Чтобы дойти до тяжёлого distinct'а — сперва надо where пройти.
> При это я так понимаю в обоих случаях индекс не используется, так как обычно в конце пишется using where; using index;
Неправильно понимаете. Используется ли индекс и какой — колонка key. dev.mysql.com/doc/refman/5.1/en/explain-output.html
using index — это использован покрывающий индекс, когда в индексе есть всё, чтобы ответить на запрос и читать данные не нужно.
В два раза объём рядов сократился, а что с реальным временем исполнения?
Боюсь, что оптимизациями запросов тут больше ничего не выиграть, полтора миллиона записей пробегать с группировкой… Надо строить таблицы, в которые складывать аггрегированные данные и следить за их своевременным обновлением.
Имел в виду количество символов в строке. Для группировки строки по индексу, индекс надо строить по всему полю, а не по префиксу. Если же строки объёмны — то индекс распухнет и будет неэффективен.
Это значит, что нету индекса. Сперва идёт группировка, потом поля в селекте — индекс не подходит для запроса, получается файловая группировка.
Попробуйте на индексе по page создать. Если page не слишком большой — можно попробовать uid добавить сюда же, а если большой — не имеет смысла.
egorinsk, любопытно, можете рассказать поподробнее, что за условие?
Почему это вообще становится возможным, я представляю — если комментарий в mp3 хранится как plain-text, то да, может быть исполнен.
А, ну и если файлу дать имя соответствующее (или другим образом натравить интерпретатор PHP на него) — точно, будет выполнен.
Интересно, не задумывался о таком.
Имя файла тем более не имеет никакого отношения к формату. php.net/manual/en/book.fileinfo.php можно как первый уровень
Совет RuslanCC как основная валидация.
Если критичен именно этот запрос — пара дополнительных полей firstLetter & strLength и составной индекс по ним решат вопрос. Для сопровождения актуальности — пару триггеров.
Да, на эти пару параметров тоже обратил внимание. Их мониторить надо, меняются ли со временем. Можно badblocks прогнать, посмотреть, что изменится после чтения всей поверхности диска. Пока вроде бы не смертельны.
PS: как вам вообще удалось на паре дисков, различающихся возрастом на 9 месяцев, получить синхронные количество старт-стопов?
RTree только myisam, инвертированный индекс — так он не перестаёт быть B-tree от этого (если я, конечно, думаю про то же, что и вы, т.к. ман по словосочетанию Inverted index ничего не знает).
BTree и остаётся только.
Конвертируйте в innodb. Остальное значения не имеет, конфиг — тем более. MyISAM использует на любой чих табличную блокировку. Даже не говоря об отсутствии транзакционности, под конкурирующее чтение-запись не подходит.
Ставите себе какую-нибудь задачу, реализовываете. В процессе вы уже знаете, где у вас пробелы знаний. Соответственно этому подбираете книгу и читаете. Если пробела не нашли и задача решена — выбираете любую книгу из пожеланий «обязательно к прочтения» и читаете. Например: habrahabr.ru/post/135897/
Точного списка знаний быть не может. Программирование охватывает слишком много областей, чтобы познать все. Пробуйте всё подряд, что понравилось — углубляйтесь, останавливайтесь и закапывайтесь с головой в практику в этой области или же ищите дальше.
Мне нравится веб-программирование и я не понимаю, какие могут быть трудности в базе данных на пару десятков миллионов записей. Но я совершенно не знаю какое-нибудь там winAPI.
Вы тоже из Питера, так что я гарантирую, найти отличную работу программистом без корочки вуза — проблемы не составляет. Отправляйте резюме, сходите на пару собеседований — это очень быстро поможет если не найти работу, то понять, в каких областях пробелы.
Увлекаясь этим с 9-го класса вы уже точно должны знать одну или несколько областей, где вам нравится.
хорошая оговорка ;-)
Партицирование данных — да, попробовать можно.
> IP хранить как 4 части по 3 знака int. + сделать индекс: на каждую часть, на 1+2 часть и 2+3 часть.
И в чём смысл, кроме как раздуть объём базы? ip и есть unsigned int сам по себе.
А индексы по ip здесь использоваться не будут. Чтобы дойти до тяжёлого distinct'а — сперва надо where пройти.