|
|
|
Откуда временная таблица в 1GB TMPFS из таблиц MYISAM по 15 Мб
|
|||
|---|---|---|---|
|
#18+
Сделал tmpfs директорию в оперативке и указал mysql писать туда временные таблицы и увидел интересную картину. Запрос на вроде Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Таблицы все не более 20 Мб. А в директории временных таблиц во время этого запроса создается файл #sql_400_0.MYD размером чуть больше Гигабайта. Это как так?! Я пробовал таблицу content сделать тип memory и она стала 1,3 Гб тогда когда она в формате MyIsam около 20 Мб. Наводит на мысли, что там в директории с временными файлами создается таблица типа memory. Но как?! Mysql же считает, что это простая директория, а не оперативная память! И расширение у файла соответствующее - *.MYD Подскажите, почему так происходит?! Ведь если отправить парочку запросов одновременно или с разницей в пол секунды то памяти не хватит - у меня на директорию эту 1,5 Гб EXPLAIN прилагаю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 17:24:04 |
|
||
|
Откуда временная таблица в 1GB TMPFS из таблиц MYISAM по 15 Мб
|
|||
|---|---|---|---|
|
#18+
Уберите слово LEFT из запроса. Оно все равно не нужно. А MySQL-ю, возможно, полегче станет. Вместо звездочек перечислите только те поля, которые реально нужны, меньше будет гонятся на диск и по сети. А за поля, которых нет в группировке, но есть в секциях SELECT и ORDER BY, пожалуй, в аду скоро отдельный котел организуют. Memory так раздуваются за счет того, что в них под строки VARCHAR всегда выделяется полный объем памяти согласно декларации поля, а не по длине фактических данных. Относится ли это также к filesort-таблицам - не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 17:46:01 |
|
||
|
Откуда временная таблица в 1GB TMPFS из таблиц MYISAM по 15 Мб
|
|||
|---|---|---|---|
|
#18+
авторТаблицы все не более 20 Мб. А в директории временных таблиц во время этого запроса создается файл #sql_400_0.MYD размером чуть больше Гигабайта. Это как так?! ну что значит как ? Объединение, это когда берется одно значение в первой таблице и к нему "присоединяются" тысячи значений из другой. И так к каждому значению. То есть, при умении, можно из десятка строк сделать миллионы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.07.2014, 20:55:42 |
|
||
|
Откуда временная таблица в 1GB TMPFS из таблиц MYISAM по 15 Мб
|
|||
|---|---|---|---|
|
#18+
netwind, Ну так это нормально? или запрос составлен не корректно и его нужно оптимизировать? Может изменить порядок присоединения таблиц? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2014, 12:26:28 |
|
||
|
Откуда временная таблица в 1GB TMPFS из таблиц MYISAM по 15 Мб
|
|||
|---|---|---|---|
|
#18+
kodmnetwind, Ну так это нормально? или запрос составлен не корректно и его нужно оптимизировать? Может изменить порядок присоединения таблиц? некорректно. GROUP BY `content`.`field_prodcode` груп бай не по всем полям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2014, 13:01:25 |
|
||
|
Откуда временная таблица в 1GB TMPFS из таблиц MYISAM по 15 Мб
|
|||
|---|---|---|---|
|
#18+
kodm, вы спрашивали откуда так много временных данных - я вам описываю откуда. Поведение mysql нормальное. Разумеется, стоит оптимизировать если вам это доставляет опасения. Для начала уже данные вам советы miksoft попробуйте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2014, 13:06:01 |
|
||
|
Откуда временная таблица в 1GB TMPFS из таблиц MYISAM по 15 Мб
|
|||
|---|---|---|---|
|
#18+
miksoftУберите слово LEFT из запроса. Оно все равно не нужно. А MySQL-ю, возможно, полегче станет. А за поля, которых нет в группировке, но есть в секциях SELECT и ORDER BY, пожалуй, в аду скоро отдельный котел организуют. Да уж... Не вникал в эти детали. Не понимаю зачем такое правило в "серьезных" БД?! Вот бралась первая попавшаяся запись и выводились бы поля от нее. Зачем ошибку то выводить?! Ну ладно, допустим если я сделаю подзапросы (а другого выхода видимо нет), чтобы мой запрос работал как и прежде и выполнялось условие про GROUP BY. Но тогда я, пользователь MySql попрощаюсь с кешем, ибо насколько мне известно mysql не кеширует подзапросы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2014, 15:03:28 |
|
||
|
Откуда временная таблица в 1GB TMPFS из таблиц MYISAM по 15 Мб
|
|||
|---|---|---|---|
|
#18+
kodmНе понимаю зачем такое правило в "серьезных" БД?! Вот бралась первая попавшаяся запись и выводились бы поля от нее. Зачем ошибку то выводить?!Тогда результат запроса был бы не детерминирован. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2014, 15:37:18 |
|
||
|
Откуда временная таблица в 1GB TMPFS из таблиц MYISAM по 15 Мб
|
|||
|---|---|---|---|
|
#18+
kodmНе понимаю зачем такое правило в "серьезных" БД?! Вот бралась первая попавшаяся запись и выводились бы поля от нее. Зачем ошибку то выводить?!и правда, вот при делении на ноль зачем ошибку выводить? проще же выдать какое-нибудь число от балды! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2014, 16:22:22 |
|
||
|
Откуда временная таблица в 1GB TMPFS из таблиц MYISAM по 15 Мб
|
|||
|---|---|---|---|
|
#18+
kodmНу ладно, допустим если я сделаю подзапросы (а другого выхода видимо нет), чтобы мой запрос работал как и прежде и выполнялось условие про GROUP BY. Но тогда я, пользователь MySql попрощаюсь с кешем, ибо насколько мне известно mysql не кеширует подзапросы...откуда на этой неделе такой наплыв спецеолиздофф? каникулы вроде бы давно уже начались... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2014, 16:25:58 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38700562&tid=1834491]: |
0ms |
get settings: |
5ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
29ms |
get topic data: |
8ms |
get forum data: |
1ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 190ms |
| total: | 293ms |

| 0 / 0 |
