Question Kunena 1.5.11 Query optimization to improve performance of large forum

# Query_time: 4 Lock_time: 0 Rows_sent: 20 Rows_examined: 799532 SELECT t.id, MAX(m.id) AS lastid FROM jos_fb_messages AS t INNER JOIN jos_fb_messages AS m ON t.id = m.thread WHERE t.parent='0' AND t.hold='0' AND t.catid='2' AND m.hold='0' AND m.catid='2' GROUP BY m.thread ORDER BY t.ordering DESC, lastid DESC LIMIT 0, 20;

ALTER TABLE `jos_fb_messages` ADD INDEX `catid_parent` ( `catid`,`parent` );

ALTER TABLE `jos_kunena_messages` DROP INDEX `catid`; ALTER TABLE `jos_kunena_messages` DROP INDEX `parent`; ALTER TABLE `jos_kunena_messages` ADD INDEX `catid_parent` ( `catid`, `parent` );

ALTER TABLE `jos_fb_messages` ADD INDEX `catid_parent` ( `catid`,`parent` ) ALTER TABLE `jos_fb_messages` DROP INDEX `catid`; ALTER TABLE `jos_fb_messages` DROP INDEX `parent`;

id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE t ref PRIMARY,hold_time,parent_hits,liko_id,catid_parent catid_parent 9 const,const 33507 Using where; Using temporary; Using filesort 1 SIMPLE m ref thread,hold_time,catid_parent thread 5 dev_pewter.t.id 22 Using where

-- MYSQL PERFORMANCE TUNING PRIMER -- - By: Matthew Montgomery - MySQL Version 5.0.90-log x86_64 Uptime = 78 days 19 hrs 16 min 52 sec Avg. qps = 138 Total Questions = 944369290 Threads Connected = 12 Server has been running for over 48hrs. It should be safe to follow these recommendations To find out more information on how each of these runtime variables effects performance visit: http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html Visit http://www.mysql.com/products/enterprise/advisors.html for info about MySQL's Enterprise Monitoring and Advisory Service SLOW QUERIES The slow query log is enabled. Current long_query_time = 1 sec. You have 48519 out of 944369312 that take longer than 1 sec. to complete Your long_query_time seems to be fine BINARY UPDATE LOG The binary update log is NOT enabled. You will not be able to do point in time recovery See http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html WORKER THREADS Current thread_cache_size = 10 Current threads_cached = 9 Current threads_per_sec = 0 Historic threads_per_sec = 0 Your thread_cache_size is fine MAX CONNECTIONS Current max_connections = 256 Current threads_connected = 9 Historic max_used_connections = 99 The number of used connections is 38% of the configured maximum. Your max_connections variable seems to be fine. MEMORY USAGE Max Memory Ever Allocated : 963 M Configured Max Per-thread Buffers : 1 G Configured Max Global Buffers : 506 M Configured Max Memory Limit : 1 G Physical Memory : 3.86 G Max memory limit seem to be within acceptable norms KEY BUFFER Current MyISAM index space = 64 M Current key_buffer_size = 24 M Key cache miss rate is 1 : 875488 Key buffer fill ratio = 55.00 % Your key_buffer_size seems to be too high. Perhaps you can use these resources elsewhere QUERY CACHE Query cache is enabled Current query_cache_size = 96 M Current query_cache_used = 69 M Current query_cache_limit = 1 M Current Query cache Memory fill ratio = 72.68 % Current query_cache_min_res_unit = 2 K MySQL won't cache query results that are larger than query_cache_limit in size SORT OPERATIONS Current sort_buffer_size = 2 M Current read_rnd_buffer_size = 256 K Sort buffer seems to be fine JOINS Current join_buffer_size = 2.00 M You have had 242444 queries where a join could not use an index properly You have had 820 joins without keys that check for key usage after each row You should enable "log-queries-not-using-indexes" Then look for non indexed joins in the slow query log. If you are unable to optimize your queries you may want to increase your join_buffer_size to accommodate larger joins in one pass. Note! This script will still suggest raising the join_buffer_size when ANY joins not using indexes are found. OPEN FILES LIMIT Current open_files_limit = 8458 files The open_files_limit should typically be set to at least 2x-3x that of table_cache if you have heavy MyISAM usage. Your open_files_limit value seems to be fine TABLE CACHE Current table_cache value = 4096 tables You have a total of 1233 tables You have 2479 open tables. The table_cache value seems to be fine TEMP TABLES Current max_heap_table_size = 128 M Current tmp_table_size = 32 M Of 28316715 temp tables, 19% were created on disk Created disk tmp tables ratio seems fine TABLE SCANS Current read_buffer_size = 128 K Current table scan ratio = 311 : 1 read_buffer_size seems to be fine TABLE LOCKING Current Lock Wait ratio = 1 : 1339 You may benefit from selective use of InnoDB. If you have long running SELECT's against MyISAM tables and perform frequent updates consider setting 'low_priority_updates=1' If you have a high concurrency of inserts on Dynamic row-length tables consider setting 'concurrent_insert=2'.