Временные таблицы MYSQL - как просматривать активные таблицы - PullRequest
5 голосов
/ 17 августа 2011

У нас есть простое "crm-подобное" программное обеспечение в нашей компании. Есть некоторые сложные запросы, которые занимали некоторое время, ежедневные запросы ... поэтому я тестирую некоторые модификации, чтобы использовать временные таблицы для замены всех сложных объединений и подзапросов, которые нам нужны.

Пока все идет хорошо, набрал 90% + скорость.

Поскольку это веб-приложение (codeigniter + mysql), я планирую поместить его в среду «производственного тестирования», чтобы 50% пользователей могли помочь мне его протестировать. Я хотел бы отслеживать таблицы, которые являются активными, и, если возможно, для каждого соединения.

Мой вопрос: есть ли способ просмотреть все ВРЕМЕННЫЕ ТАБЛИЦЫ, которые активны в экземпляре mysql? Может быть, просмотреть его данные?

Я читал кое-что о ПЛУГИНЕ или что-то в этом роде, но статья была очень грязной, и я не могу понять.

Большое спасибо и извините за мой английский - не мой родной язык.

Ответы [ 4 ]

3 голосов
/ 17 августа 2011

временная таблица = временная, она удаляется сразу после запроса

прямого решения не существует, кроме регистрации всех запросов и выполнения одного за другим, чтобы проверить, какой запрос требует tmp_table

системные переменные типа Created_tmp_tables могут дать некоторые идеи

mysql> show status like '%tmp%';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0     |
| Created_tmp_files       | 0     |
| Created_tmp_tables      | 0     |
+-------------------------+-------+
1 голос
/ 17 августа 2011

Одной из проблем временных таблиц является фактическое отслеживание использования, а затем накладные расходы на их создание, индексацию и удаление, особенно в веб-приложении, в котором время жизни временной таблицы обычно равно времени жизни HTTP. запрос.

В тех случаях, когда предварительно скомпилированные результаты (т.е. материализованные представления) будут полезны, я создал обычную таблицу, добавив поля, которые ссылаются на идентификатор соединения MySQL / идентификатор веб-сеанса / исходный запрос + время, сгенерированное в зависимости от TTL для данных и того, будут ли они переданы или нет.

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

0 голосов
/ 17 августа 2011

Я считаю, что это не имеет смысла в просмотре временных таблиц, потому что они живут во время соединения и умирают после закрытия соединения. Но есть один важный факт о временной таблице. Поэтому, если вы используете постоянное соединение в своих скриптах, временная таблица будет жить в течение жизни этого соединения, и клиенты, которые используют это, получат доступ к тем же временным таблицам. Также в этом случае временная таблица будет потреблять системные ресурсы. Чтобы избежать этого, вам следует удалить временные таблицы вручную после выполнения запроса необходимого запроса, который использует эту временную таблицу.

0 голосов
/ 17 августа 2011

Когда ваш набор данных увеличивается, временные таблицы вам не помогут. В конце концов, как они помогают? Данные должны быть скопированы в эти таблицы после вычисления результата, почему бы не кэшировать результаты с помощью memcached?

Кроме того, я видел базы данных, которые несколько велики (десятки гигабайт) и работают на одной машине, а запросы выполнялись быстро. Возникает вопрос, правильно ли вы настроили сервер баз данных (программный и аппаратный). Возможно, вы испытываете временное ускорение, но нет гарантии, что он будет работать постоянно. Я оптимизировал бы приложение, запросы, программное и аппаратное обеспечение, необходимое для его запуска, а затем кэшировал результаты с помощью memcache, если вам не нужна последняя горячая копия результата запроса.

...