SQLMon: мониторинг запросов MySQL
Наверное, каждый разработчик знает, что во многих случаях плохая производительность связана с ошибками при проектировании базы данных либо неоптимальными запросами к MySQL (например, в таблице нет индекса, который мог бы использоваться для выполнения запроса, либо запрос использует ORDER BY/GROUP BY, без которых можно обойтись).
WordPress может вывести только список всех выполненных запросов — разработчику придётся запускать каждый подозрительный запрос вручную и анализировать результат. Это очень муторно и непродуктивно. SQLMon пытается помочь разработчикам, анализируя все запросы перед их выполнением, сообщая обо всём, что требует внимания.
Каждый запрос, который передаётся WordPress, анализируется (используя EXPLAIN); результаты показываются в подвале темы или панели администрирования. Лог запросов виден только администраторам, что позволяет использовать плагин даже на живых сайтах.
Одна из особенностей SQLMon — возможность выполнения EXPLAIN не только на запросах SELECT, но и UPDATE/DELETE и INSERT/REPLACE INTO … AS или CREATE TABLE … AS.
Перед использованием плагина рекомендую к прочтению статью Optimizing Queries with EXPLAIN.
Активация плагина: для успешной активации каталог wp-content должен быть доступен на запись — в него помещается файл db.php, который занимается отловом и анализом запросов.
Деактивация/удаление: аналогично, чтобы плагин смог удалить файл db.php, каталог wp-content должен быть доступен на запись. Тем не менее, в плагин добавлены средства контроля, позволяющие сохранить работоспособность блога, если плагин был удалён, а wp-content/db.php — нет.
Внимание:
- плагин не будет работать с PHP 4;
- плагин конфликтует со всеми плагинами, устанавливающими свой собственный
db.php(W3 Total Cache, DB Cache, DB Cache Reloaded).
Плагин пригодится разработчикам WordPress, разработчикам плагинов и тем, а также администраторам, знающим MySQL, пытающимся понять, почему блог так медленно работает.
Домашняя страница SQLMon на wordpress.org.
Автор: Vladimir;
Комментарии к статье «SQLMon: мониторинг запросов MySQL» (15) »
Пожалуйста, не используйте эту форму для комментирования! Данная форма предназначена исключительно для ботов.
Оставить комментарий к записи «SQLMon: мониторинг запросов MySQL»
गते गते पारगते पारसंगते बोधि स्वाहा
Меня зовут Владимир, я программист-фрилансер, специализирующийся на Web-программировании и програмировании под Linux.
По совместительству занимаюсь администрированием LAMP/LNMP-серверов и техническим переводом.


[...] SQLMon: мониторинг запросов MySQL [...]
[...] SQLMon: мониторинг запросов MySQL [...]
Does this plugin actually make mysql recommendations and fix them? I have a mysql bottleneck issue and my server is quite slow right now. thanks
To some extent. It does not give you recommendations but it shows what can cause problems.
For example, please take a look at the attached file: you will see these comments in red: «Using temporary; Using filesort». Temporary tables and filesort are known to be performance killers (especially on large datasets). If you can get rid of them, you will get a faster query. The next (by importance) is the orange label — »range». It means that MySQL has to do several lookups in the index to get all necessary rows.
rangeis OK unless you have a large «x IN (List)» condition or when more than 30% of the rows match the range condition (if you have a large dataset).To summarize: the plugin just simplifies the analysis of the queries but it is the user who has to make the final decision.
PS — if you need help with the query optimization, feel free to ask
query.png
[...] SQLMon: мониторинг запросов MySQL [...]
[...] плагина MySQL Monitor [...]
http://photo.aquadb.com/wordpress/optimizaciya-nextgen-gallery.htmlHi – we’ve installed this plugin, but I can’t figure out where the reports appear. Where can I see the reports in the admin?
Thanks!
Hi Miriam,
By default the plugin displays the stats for the users which have «administrator» capability (this can be changed by installing
enable_sqlmonfilter). Stats are displayed duringwp_footerandadmin_footerevents.And please make sure that the plugin was able to create
wp-content/db.phpafter activation; if it hasn’t you will have to copywp-content/plugins/sqlmon/db.phptowp-content/db.phpHope that helps.
На версии 3.0.4 плагин почему-то не отображает никаких данных. До этого нормально работал и был деактивирован, сейчас включил ничего не вижу.
wp-content/db.phpсоздался? В теме присутствует вызовwp_footer()? Вы зашли как администратор?Спасибо! Проблема решилась установкой прав на wp-content 777 вместо 755. При активации плагин не выдавал никакой ошибки, но и не создавал db.php.
Пытался поставить этот плагин, сначала он ругался на
require_once(WP_PLUGIN_DIR . ‘/sqlmon/lib/class.Logger.php’);
require_once(WP_PLUGIN_DIR . ‘/sqlmon/lib/class.LogEntry.php’);
не мог найти корректный путь, поменял руками на
require_once(‘/usr/share/wordpress/wp-content/plugins/sqlmon/lib/class.Logger.php’);
require_once(‘/usr/share/wordpress/wp-content/plugins/sqlmon/lib/class.LogEntry.php’);
После этого плагин отработал без ошибок, но файл wp-content/db.php не создал, хотя на папку права стоят 777
WP_PLUGIN_DIR,WP_CONTENT_DIR, если да, то верны ли их значения?sqlmon.phpв методеSqlMonitor::activate()в строке@copy(dirname(__FILE__) . '/db.php', WP_CONTENT_DIR . '/db.php');убрать@, какая ошибка появляется при активации плагина?Проблема была в версии wordpress’a(2.5.1), после обновления на последнюю, плагин заработал корректно.
Кстати
wp_enqueue_style(‘sqlmon-css’, plugins_url(‘sqlmon/sqldebug.css’), array(), », ‘all’);
до обновления на стиль ругался, пришлось закомментировать эту строку.
Извините за беспокойство.
Понимаю, что вопрос не совсем по теме, но уж очень беспокоит то, что обращение к странице генерит 4 запроса:
3 SELECT ID, post_name, post_parent FROM wp_posts WHERE post_name = ‘legal’ AND (post_type = ‘page’ OR post_type = ‘attachment’)
4 SELECT * FROM wp_posts WHERE ID = 545 LIMIT 1
5 SELECT wp_posts.* FROM wp_posts WHERE 1=1 AND (wp_posts.ID = ’545′) AND wp_posts.post_type = ‘page’ ORDER BY wp_posts.post_date DESC0
6 SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN (545)
Это стандартное поведение вордпреса и у всех так или у меня что-то сломано и можно уменьшить количество запросов?