Pull to refresh
3
0
erock @erock

User

Send message
1. Selectivity - количество разных элементов в индексе. Представьте - у вас есть запрос SELECT * FROM table WHERE field = 5. По полю field есть индекс. Чем больше РАЗНЫХ значений в индексе, тем больше будет от него пользы - тем меньше строк останется в выборке после использования индекса. Так вот при выборе индексов нужно страться выбирать индексы с бОльшей выборностью.

2. Есть таблица с полями field1, field2, field3 и есть составной индекс (field1, filed2, field3). Так вот для запроса select * from table where field1=a and field2=b индекс будет использоваться, а для запроса select * from table where field1=a and field3=b использоваться не будет. Подробно об этом расписано в мануале - советую почитать.

3. в статье есть пример :)

4. есть поле name varchar(50). Часто имеет смыл делать индекс alter table table name add index(name(10)). т.е. индексировать не все поле, а только первые скажем 10 букв.

5. запросы в цикле - это зло. часто люди выбирают скажем какие-нибудь основные данные(скажем статистику) и потом в цикле для каждой из строк делают запрос на выборку дополнительных данных из других таблиц.

6. Нужно делать постраничный вывод. Часто делают так: select * from table where ... limit 100, 10, а потом, чтобы узнать общее количество делают select count(*) from table where ... ТАк вот это все можно сделать так: select sql_calc_found_rows * from table where ... limit 100, 10. и потом для получения общего количества сделать SELECT FOUND_ROWS();

7. Часто встает задача - если в таблице есть запись, то проапдейтить поле, а если его нет, то вставить новую запись. Подобную задачу часто решают "в лоб": row = select * from table where ...; if(row) update ... else insert ...; Но решить можно(и нужно по-другому): добавить, если его нет, уникальный ключ определяющий поле и потом сделать inset into table set field1=a, field2=b on duplicate key update set field2=c.
До некоторых пор, я тоже был такого мнения про fixed rows. Однако на практике оказывается все совсем по-другому. Очень мало можно придумать случаев, когда преимущество fixed rows действительно будет использоваться. Дело в том, что поля в таблице могут идти(и чаще всего идут не последовательно). Кому интересно почитайте тему. Там как раз боролись с этими fixed rows.
Я про такие курсы не знаю. Думаю, для начала будет достаточно чтения литературы(ее написано немало. На русский, правда, ничего не переводят) ну и опыт конечно...
пока еще нужен кликам :)
enum по сути это и есть int. просто к каждому из int'ов привязано еще и строковое значение, которое хранится в метаданных таблицы.
Да, много каких тем не затронул. Здесь хотел лишь собрать вместе совсем не сложные советы. Если писать обо всем - это можно браться за книгу :)
> использование InnoDB, кстати, даёт ощутимый прирост скорости на выборках
ох и спорное это высказывание. Вот здесь например есть тесты. Заметьте, что при нагрузках < 10000 запросов\сек разницы между InnoDB и MyISAM практически нет.
как можно REPLACE'ом и ON DUPLICATE KEY UPDATE "затыкать" ошибки?
Не знаю про Postres, знаю то, что оптимизатор MySQL решает использовать или нет индекс по довольно большому количеству параметров. И чаще всего бывает прав. FORCE INDEX нужно использовать с большой осторожностью. Сегодня один индекс оптимальный, через месяц количество и типы данных в таблице могут измениться и оптимальным будет другой индекс.
напишите, пожалуйста, что конкретно не понятно. Постараюсь расписать.
> так как это уменьшает размер таблицы
вы уверены? Боюсь вас огорчить, но это не чаще всего не так. INT - 4 байта. ENUM с количиством элементов < 8 - 1 байт.
Заметьте, что в этом как раз используется покрывающий индекс, а на практике такое бывает далеко не всегда.
Полностью согласен. В статье только писалось о том, что не нужно выбирать записей больше, чем требуется.
да изменения в скорости будут, но фулл скан по 100000 записей это в любом случае - не лучший вариант.
гм. значит я точно не одинок(башорг к счастью не читаю)
это мой личный блог и мои личные мысли.
ага. я хотел раньше, но ошибка в habrawiki была.
ага. ctrl+insert имел ввиду

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity