Every couple hours (sometimes every couple days) our database becomes extremely slow for no apparent reason. There is typically 1 active query in "Sending data" for over 30 minutes. There are also many queries "Waiting for table level lock". Once that query completes, all queries finish up very quickly.

I don't think the queries need optimizing because after this happened, I re-ran those queries manually, and they complete in 14 seconds or less. So it seems like it is just a temporary server issue.

Someone recommened I disable the query cache which I've done and the problem is still happening. This is a brand new server that we bought because we expect a lot more traffic soon. The old server which had much lower specs never had this problem.

This server runs nothing except mysql. Any help would be greatly appreciated.

This is one example query:
select distinct user.id from phplist_listuser as listuser, phplist_user_user as user, phplist_listmessage as listmessage where listmessage.messageid = 29244 and listmessage.listid = listuser.listid and user.id = listuser.userid and user.confirmed and !user.blacklisted and listuser.userid not in (select userid from phplist_usermessage where messageid = 29244) and listuser.userid in ( SELECT DISTINCT `phplist_user_user`.id FROM `phplistdb`.`phplist_user_user` JOIN `phplistdb`.`phplist_listuser` ON `phplist_user_user`.id = `phplist_listuser`.userid LEFT JOIN `geolocation`.`phplist_userid_cache` ON `phplist_user_user`.id = `phplist_userid_cache`.userid LEFT JOIN `geolocation`.`geolocation` ON `phplist_userid_cache`.geolocation__id = geolocation.id WHERE ( latitude BETWEEN 30.102734667283 AND 30.671357620625 && longitude BETWEEN -98.438274110938 AND -97.559367860938 && `phplist_user_user`.confirmed=1 && `phplist_user_user`.blacklisted=0 ) || `phplist_user_user`.email='something@domain.com' || `phplist_user_user`.email='something2@domain.com' || listid=8)

Here are some commands that I ran while it was in this state:

**pidstat -dru 1 3**:

Linux 3.8.0-29-generic (db1) 02/28/2014 _x86_64_ (32 CPU)

10:16:06 AM PID %usr %system %guest %CPU CPU Command
10:16:07 AM 2907 103.88 1.94 0.00 105.83 17 mysqld
10:16:07 AM 29727 0.97 1.94 0.00 2.91 17 pidstat

10:16:06 AM PID minflt/s majflt/s VSZ RSS %MEM Command
10:16:07 AM 2907 230.10 0.00 17380572 756892 1.15 mysqld
10:16:07 AM 29727 868.93 0.00 7636 1268 0.00 pidstat

10:16:06 AM PID kB_rd/s kB_wr/s kB_ccwr/s Command

10:16:07 AM PID %usr %system %guest %CPU CPU Command
10:16:08 AM 10 0.00 1.00 0.00 1.00 5 rcu_sched
10:16:08 AM 462 0.00 1.00 0.00 1.00 31 kworker/31:1
10:16:08 AM 2907 105.00 1.00 0.00 106.00 17 mysqld
10:16:08 AM 29727 1.00 2.00 0.00 3.00 17 pidstat

10:16:07 AM PID minflt/s majflt/s VSZ RSS %MEM Command
10:16:08 AM 2907 177.00 0.00 17380572 756892 1.15 mysqld
10:16:08 AM 29619 28.00 0.00 23304 4616 0.01 bash
10:16:08 AM 29727 895.00 0.00 7636 1300 0.00 pidstat

10:16:07 AM PID kB_rd/s kB_wr/s kB_ccwr/s Command

10:16:08 AM PID %usr %system %guest %CPU CPU Command
10:16:09 AM 2907 103.00 2.00 0.00 105.00 17 mysqld
10:16:09 AM 29727 2.00 2.00 0.00 4.00 17 pidstat

10:16:08 AM PID minflt/s majflt/s VSZ RSS %MEM Command
10:16:09 AM 2907 162.00 0.00 17380572 756892 1.15 mysqld
10:16:09 AM 29619 2.00 0.00 23304 4616 0.01 bash
10:16:09 AM 29727 887.00 0.00 7636 1300 0.00 pidstat

10:16:08 AM PID kB_rd/s kB_wr/s kB_ccwr/s Command
10:16:09 AM 2907 0.00 2000.00 0.00 mysqld

Average: PID %usr %system %guest %CPU CPU Command
Average: 10 0.00 0.33 0.00 0.33 - rcu_sched
Average: 462 0.00 0.33 0.00 0.33 - kworker/31:1
Average: 2907 103.96 1.65 0.00 105.61 - mysqld
Average: 29727 1.32 1.98 0.00 3.30 - pidstat

Average: PID minflt/s majflt/s VSZ RSS %MEM Command
Average: 2907 190.10 0.00 17380572 756892 1.15 mysqld
Average: 29619 9.90 0.00 23304 4616 0.01 bash
Average: 29727 883.50 0.00 7636 1289 0.00 pidstat

Average: PID kB_rd/s kB_wr/s kB_ccwr/s Command
Average: 2907 0.00 660.07 0.00 mysqld


**vmstat 1 2**:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 0 416 322964 191692 63370180 0 0 5 5 0 0 0 0 100 0
1 0 416 322908 191692 63370188 0 0 0 0 567 2422 3 0 97 0



**mpstat -P ALL 1 2**:

Linux 3.8.0-29-generic (db1) 02/28/2014 _x86_64_ (32 CPU)
10:16:02 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
10:16:03 AM all 3.16 0.00 0.03 0.00 0.00 0.00 0.00 0.00 96.81
10:16:03 AM 0 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
10:16:03 AM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 8 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 9 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 10 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 11 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 12 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 13 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 14 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 15 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 16 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 17 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 18 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 19 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 21 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 22 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 23 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 24 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 25 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 26 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 27 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 28 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 29 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 30 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:03 AM 31 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00

10:16:03 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
10:16:04 AM all 3.22 0.00 0.06 0.00 0.00 0.00 0.00 0.00 96.72
10:16:04 AM 0 98.02 0.00 0.99 0.00 0.00 0.00 0.00 0.00 0.99
10:16:04 AM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 4 1.98 0.00 0.99 0.00 0.00 0.00 0.00 0.00 97.03
10:16:04 AM 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 8 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 9 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 10 2.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 98.00
10:16:04 AM 11 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 12 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 13 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 14 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 15 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 16 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 17 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 18 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 19 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 21 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 22 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 23 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 24 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 25 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 26 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 27 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 28 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 29 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 30 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
10:16:04 AM 31 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00


**iostat -x 1 2**:

Linux 3.8.0-29-generic (db1) 02/28/2014 _x86_64_ (32 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.17 0.00 0.04 0.00 0.00 99.79

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.29 1.41 3.11 151.57 151.91 134.28 0.08 16.85 0.54 24.28 0.31 0.14
dm-0 0.00 0.00 1.41 4.40 151.57 151.91 104.44 0.08 14.06 0.54 18.41 0.24 0.14
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 2.27 0.54 5.68 1.22 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
3.25 0.00 0.03 0.00 0.00 96.72

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00


**free -m**:

total used free shared buffers cached
Mem: 64385 64070 315 0 187 61884
-/+ buffers/cache: 1998 62387
Swap: 65491 0 65491


**SHOW GLOBAL STATUS**:

Variable_name Value
Aborted_clients 32
Aborted_connects 2088
Binlog_cache_disk_use 0
Binlog_cache_use 0
Binlog_stmt_cache_disk_use 2
Binlog_stmt_cache_use 2798217
Bytes_received 1724697475
Bytes_sent 10912829491
Com_admin_commands 103619
Com_assign_to_keycache 0
Com_alter_db 0
Com_alter_db_upgrade 0
Com_alter_event 0
Com_alter_function 0
Com_alter_procedure 0
Com_alter_server 0
Com_alter_table 113
Com_alter_tablespace 0
Com_analyze 0
Com_begin 1095437
Com_binlog 0
Com_call_procedure 0
Com_change_db 393259
Com_change_master 0
Com_check 15189
Com_checksum 0
Com_commit 1095434
Com_create_db 1
Com_create_event 0
Com_create_function 0
Com_create_index 0
Com_create_procedure 1
Com_create_server 0
Com_create_table 42
Com_create_trigger 0
Com_create_udf 0
Com_create_user 0
Com_create_view 0
Com_dealloc_sql 24
Com_delete 9989
Com_delete_multi 2
Com_do 0
Com_drop_db 1
Com_drop_event 0
Com_drop_function 0
Com_drop_index 0
Com_drop_procedure 2
Com_drop_server 0
Com_drop_table 1
Com_drop_trigger 0
Com_drop_user 0
Com_drop_view 0
Com_empty_query 0
Com_execute_sql 24
Com_flush 4
Com_grant 0
Com_ha_close 0
Com_ha_open 0
Com_ha_read 0
Com_help 0
Com_insert 711847
Com_insert_select 6
Com_install_plugin 0
Com_kill 0
Com_load 0
Com_lock_tables 0
Com_optimize 55
Com_preload_keys 0
Com_prepare_sql 24
Com_purge 0
Com_purge_before_date 0
Com_release_savepoint 0
Com_rename_table 1
Com_rename_user 0
Com_repair 0
Com_replace 491733
Com_replace_select 31
Com_reset 0
Com_resignal 0
Com_revoke 0
Com_revoke_all 0
Com_rollback 0
Com_rollback_to_savepoint 0
Com_savepoint 0
Com_select 2842695
Com_set_option 388138
Com_signal 0
Com_show_authors 0
Com_show_binlog_events 0
Com_show_binlogs 0
Com_show_charsets 0
Com_show_collations 0
Com_show_contributors 0
Com_show_create_db 0
Com_show_create_event 0
Com_show_create_func 0
Com_show_create_proc 0
Com_show_create_table 0
Com_show_create_trigger 0
Com_show_databases 3
Com_show_engine_logs 0
Com_show_engine_mutex 0
Com_show_engine_status 0
Com_show_events 0
Com_show_errors 0
Com_show_fields 231871
Com_show_function_status 0
Com_show_grants 0
Com_show_keys 0
Com_show_master_status 0
Com_show_open_tables 0
Com_show_plugins 0
Com_show_privileges 0
Com_show_procedure_status 0
Com_show_processlist 4103
Com_show_profile 0
Com_show_profiles 0
Com_show_relaylog_events 0
Com_show_slave_hosts 0
Com_show_slave_status 0
Com_show_status 4099
Com_show_storage_engines 0
Com_show_table_status 0
Com_show_tables 1516319
Com_show_triggers 0
Com_show_variables 6
Com_show_warnings 0
Com_slave_start 0
Com_slave_stop 0
Com_stmt_close 24
Com_stmt_execute 24
Com_stmt_fetch 0
Com_stmt_prepare 24
Com_stmt_reprepare 0
Com_stmt_reset 0
Com_stmt_send_long_data 0
Com_truncate 3
Com_uninstall_plugin 0
Com_unlock_tables 0
Com_update 1584610
Com_update_multi 22
Com_xa_commit 0
Com_xa_end 0
Com_xa_prepare 0
Com_xa_recover 0
Com_xa_rollback 0
Com_xa_start 0
Compression OFF
Connections 445201
Created_tmp_disk_tables 1736238
Created_tmp_files 90
Created_tmp_tables 1795650
Delayed_errors 0
Delayed_insert_threads 0
Delayed_writes 0
Flush_commands 1
Handler_commit 3893481
Handler_delete 9342
Handler_discover 0
Handler_prepare 0
Handler_read_first 329186
Handler_read_key 4104519415
Handler_read_last 12543
Handler_read_next 5423345858
Handler_read_prev 27590297
Handler_read_rnd 5211189
Handler_read_rnd_next 42554732813
Handler_rollback 0
Handler_savepoint 0
Handler_savepoint_rollback 0
Handler_update 39411585
Handler_write 274236845
Key_blocks_not_flushed 1
Key_blocks_unused 0
Key_blocks_used 319666
Key_read_requests 17637822343
Key_reads 13404466
Key_write_requests 192935745
Key_writes 1202353
Last_query_cost 0.000000
Max_used_connections 412
Not_flushed_delayed_rows 0
Open_files 9779
Open_streams 0
Open_table_definitions 4767
Open_tables 5000
Opened_files 7094126
Opened_table_definitions 49482
Opened_tables 55504
Performance_schema_cond_classes_lost 0
Performance_schema_cond_instances_lost 0
Performance_schema_file_classes_lost 0
Performance_schema_file_handles_lost 0
Performance_schema_file_instances_lost 0
Performance_schema_locker_lost 0
Performance_schema_mutex_classes_lost 0
Performance_schema_mutex_instances_lost 0
Performance_schema_rwlock_classes_lost 0
Performance_schema_rwlock_instances_lost 0
Performance_schema_table_handles_lost 0
Performance_schema_table_instances_lost 0
Performance_schema_thread_classes_lost 0
Performance_schema_thread_instances_lost 0
Prepared_stmt_count 0
Qcache_free_blocks 15231
Qcache_free_memory 49970792
Qcache_hits 2495975
Qcache_inserts 2762600
Qcache_lowmem_prunes 182256
Qcache_not_cached 80858
Qcache_queries_in_cache 11811
Qcache_total_blocks 39192
Queries 13324094
Questions 13324094
Rpl_status AUTH_MASTER
Select_full_join 10253
Select_full_range_join 278
Select_range 5736
Select_range_check 18
Select_scan 1905346
Slave_heartbeat_period 0.000
Slave_open_temp_tables 0
Slave_received_heartbeats 0
Slave_retried_transactions 0
Slave_running OFF
Slow_launch_threads 0
Slow_queries 445
Sort_merge_passes 44
Sort_range 66431
Sort_rows 5055362
Sort_scan 67580
Ssl_accept_renegotiates 0
Ssl_accepts 0
Ssl_callback_cache_hits 0
Ssl_cipher
Ssl_cipher_list
Ssl_client_connects 0
Ssl_connect_renegotiates 0
Ssl_ctx_verify_depth 0
Ssl_ctx_verify_mode 0
Ssl_default_timeout 0
Ssl_finished_accepts 0
Ssl_finished_connects 0
Ssl_session_cache_hits 0
Ssl_session_cache_misses 0
Ssl_session_cache_mode NONE
Ssl_session_cache_overflows 0
Ssl_session_cache_size 0
Ssl_session_cache_timeouts 0
Ssl_sessions_reused 0
Ssl_used_session_cache_entries 0
Ssl_verify_depth 0
Ssl_verify_mode 0
Ssl_version
Table_locks_immediate 5984350
Table_locks_waited 21734
Tc_log_max_pages_used 0
Tc_log_page_size 0
Tc_log_page_waits 0
Threads_cached 0
Threads_connected 412
Threads_created 30180
Threads_running 38
Uptime 250436
Uptime_since_flush_status 250436

Hello,

I'm new here so I hope I'm posting in the right section.

I'm having trouble executing a specific kind of query (it'a a CREATE TABLE statement with some UNION, LEFT JOIN, ... )

This query take 2.5 seconds to execute on my laptop running OSX, take 3.5 seconds on a Windows 7 desktop computer.

But when I run it on a linux, the exact same query with the exact same dump of data take 30 to 50 MINUTES.

I tried several physical servers (Dual Xeon, SAS disk, ...), several versions of MySQL (5.1, 5.5 and 5.6), on Virtual Machine on the cloud...

For all my tests I'm using a regular Mysql Installation, from the distribution using the default settings.

My question is How can I identify what's going wrong ?
And how it is possible that the differences between systems are so big, from a few seconds to tens of minutes ?

Thanks in advance for your help.

Regards,

Julien

I have a table that looks like...

mysql> show create table tags;
+-------+------------------------------------------------------------
| Table | Create Table
+-------+------------------------------------------------------------
| tags | CREATE TABLE `tags` (
`rushID` char(32) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`tagtype` varchar(255) NOT NULL,
`start` int(11) NOT NULL,
`finish` int(11) NOT NULL,
`info` varchar(255) DEFAULT NULL,
`created` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
KEY `rushid` (`rushID`),
KEY `start` (`start`),
KEY `finish` (`finish`),
KEY `tagtype` (`tagtype`(32)),
KEY `info` (`info`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 |

I do a search on this table that looks like

SELECT DISTINCT start, finish, info FROM tags
WHERE tagtype = "Q_PixelAspect" AND
rushid = "418bbafefd8f00506887f858b8160987" AND
start < 139 AND (finish > 0 || finish = 0) ORDER BY start ;

Doing a describe on this I get

id: 1
select_type: SIMPLE
table: tags
type: ref
possible_keys: rushid,start,finish,tagtype
key: rushid
key_len: 96
ref: const
rows: 1
Extra: Using where; Using temporary; Using filesort

So it uses a temporary. Often this search goes very slow. Investigating shows that it is always creating a temporary table on disk. I've got max_heap_table_size and tmp_table_size set to 16M, which should be ample. I have tried increasing these and it makes no difference.

But, if I change the info column so it is VARCHAR(170) it stops creating temporary tables on disk and the query is always much faster. Changing the tagtype VARCHAR size doesn't seem to make any difference.

I can't find any reference to this magic 170 number and all the discussions on performance suggest VARCHARs can be upto 64K and still not write to disk. So what is going on? What do I have to do to use a VARCHAR bigger than 170 and still avoid temporary tables going to disk.

I have tried this on versions 5.1.47 (32 bit) & 5.5.16 (64 bit) all running on Windows with the same results.

Any help would be much appreciated.

Below are 2 queries. They're exactly the same except for the inner join to the t_lob table (which has 14 rows in it and an index on account and skill). The query with the join used to run in a matter of seconds before I upgraded to MySQL v5.6 (from 5.5). Now it crawls.

Why? What can I do to fix it?

Here are the explain results:

Query with Join:
id,select_type,table,type,possible_keys,key,key_len,ref,rows,Extra
1,PRIMARY,<derived2>,ALL,NULL,NULL,NULL,NULL,6066,"Using temporary; Using filesort"
2,DERIVED,l,ref,"Account,Skill",Account,11,const,6,"Using index condition; Using where"
2,DERIVED,t,ref,"StartDate,Skill,Account",Skill,103,att.l.Skill,1011,"Using where"


Query with Join Commented out:
id,select_type,table,type,possible_keys,key,key_len,ref,rows,Extra
1,PRIMARY,<derived2>,ALL,NULL,NULL,NULL,NULL,445155,"Using temporary; Using filesort"
2,DERIVED,t,range,"StartDate,Account",StartDate,4,NULL,593540,"Using index condition; Using where"



.....So, it seems to me that the inclusion of the inner join causes fewer rows to be evaluated. However, as I've explained it actually takes longer. Not even sure if it will complete. I've let it go for about 30 min before killing it. The version without the join takes 10.8 seconds

To clarify. t_transcripts has about 10M rows in it. t_lob has 14.


select distinct
#lob,
URL_Cleaned, count(URL_Cleaned) as URL_Count, sum(convcounter) as Conversions

from (select
t.account,
#l.lob,
#l.sortseq,
t.sessionid,
t.skill,
t.startdate,
t.chat_button_name,
t.chatreferer as URL,
substring_index(substring_index(substring_index(t.chatreferer, '://',-1),'#', 1), '?',1) as URL_Cleaned,
if(isnull(conversion), 0, 1) as convcounter

from
t_transcripts t

#inner join t_lob l
#on t.account = l.account
#and t.skill = l.skill

where
t.account = '12345678'
and t.startdate between '2014-02-12' and '2014-02-28'
)q

group by
#lob,
url_cleaned



-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SLOW QUERY (inner join is not commented out):




select distinct
#lob,
URL_Cleaned, count(URL_Cleaned) as URL_Count, sum(convcounter) as Conversions

from (select
t.account,
#l.lob,
#l.sortseq,
t.sessionid,
t.skill,
t.startdate,
t.chat_button_name,
t.chatreferer as URL,
substring_index(substring_index(substring_index(t.chatreferer, '://',-1),'#', 1), '?',1) as URL_Cleaned,
if(isnull(conversion), 0, 1) as convcounter

from
t_transcripts t

inner join t_lob l
on t.account = l.account
and t.skill = l.skill

where
t.account = '12345678'
and t.startdate between '2014-02-12' and '2014-02-28'
)q

group by
#lob,
url_cleaned

Hi,

I am running on MYSQL SERVER 5.6.15 and when select from a table with 100k row with sorting and limit as query below, there have a process of creating sort index which is very slow around 20 seconds for the first time and around 5 seconds for the second time. It only happen to myisam table.


Select * from artran where type = "SO" order by wos_date desc, refno desc limit 20

May I know what should I do to make the creating sort index part faster?

MySQL configuration as below

max_connections=10000
query_cache_size=0
table_open_cache=10000
tmp_table_size=150M
thread_cache_size=10
myisam_max_sort_file_size=100G
myisam_sort_buffer_size=175M
key_buffer_size=128M
read_buffer_size=1M
read_rnd_buffer_size=4M

Your help is really appreciated!

We have a server running LAMP stack on CentOS release 5.6 (Final)
MySQL is having high CPU usage constantly which causes server to lag as shown
<code>
top - 13:50:47 up 80 days, 13:53, 1 user, load average: 4.02, 3.44, 3.19
Tasks: 129 total, 2 running, 127 sleeping, 0 stopped, 0 zombie
Cpu0 : 24.7%us, 19.8%sy, 0.2%ni, 54.5%id, 0.7%wa, 0.0%hi, 0.1%si, 0.0%st
Cpu1 : 23.0%us, 9.4%sy, 0.1%ni, 67.0%id, 0.3%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 4034120k total, 3317400k used, 716720k free, 124324k buffers
Swap: 8385920k total, 9788k used, 8376132k free, 2004692k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26266 mysql 15 0 2472m 464m 4448 S 158.6 11.8 109:00.59 mysqld
30276 apache 16 0 310m 16m 3724 S 12.1 0.4 0:00.85 httpd
30205 apache 16 0 309m 17m 3860 S 8.6 0.4 0:01.81 httpd
</code>

<code>
MySQL version:
+----------------+
| 5.1.57-ius-log |
+----------------+
</code>

The server has 4GB RAM, tables are stored in MyISAM.
Our database is about 6.6GB. It has a replicated database (readonly) on another server
All our tables are in MyISAM, highest rows: 6930622
Info for a few large tables:
+--------+---------+------------+---------+----------------+-------------+-------------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------+
| Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment |
+------------------------------------+--------+---------+------------+---------+----------------+-------------+-------------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------+
| MyISAM | 10 | Dynamic | 6930622 | 72 | 503120776 | 281474976710655 | 497158144 | 0 | 21578189 | 2013-04-17 02:06:20 | 2014-03-24 02:24:04 | 2013-04-17 02:08:47 | latin1_swedish_ci | NULL | | |
| MyISAM | 10 | Dynamic | 2197631 | 1315 | 2891479112 | 281474976710655 | 133948416 | 0 | 2197632 | 2012-02-07 23:02:45 | 2014-03-24 02:28:20 | 2013-04-17 00:53:55 | latin1_swedish_ci | NULL | | |
| MyISAM | 10 | Dynamic | 3362364 | 29 | 98158700 | 281474976710655 | 145138688 | 0 | 3363221 | 2011-06-17 01:36:48 | 2014-03-24 02:28:18 | 2012-11-12 11:00:23 | latin1_swedish_ci | NULL | | |


Here's our my.cnf (IP information Xed out).
<code>
[mysqld]
# General
datadir = /home/mysql
tmpdir = /var/lib/mysqltmp
socket = /var/lib/mysql/mysql.sock
skip-external-locking = 1
skip-name-resolve
open-files-limit = 20000
# Cache
thread-cache-size = 16
table-open-cache = 2048
table-definition-cache = 512
query-cache-size = 32M
query-cache-limit = 1M
# Per-thread Buffers
sort-buffer-size = 1M
read-buffer-size = 1M
read-rnd-buffer-size = 8M
join-buffer-size = 1M
# Temp Tables
tmp-table-size = 64M
max-heap-table-size = 64M
# Networking
back-log = 100
max-connections = 200
max-connect-errors = 10000
max-allowed-packet = 16M
interactive-timeout = 600
wait-timeout = 600
#Storage Engines
innodb = FORCE
# MyISAM
key-buffer-size = 64M
myisam-sort-buffer-size = 128M
# InnoDB
innodb-buffer-pool-size = 16M
innodb_log_files_in_group = 2
innodb-log-buffer-size = 4M
# Replication
server-id = 1
bind-address = XX.XX.XXX.XXX
log-bin = /var/lib/mysqllogs/bin-log
binlog-do-db = rewards1
binlog-ignore-db = mysql
relay-log-index=master-relay-bin.index
relay-log = /var/lib/mysqllogs/relay-log
#Logging
slow-query-log = 1
slow-query-log-file = /var/log/slow-log
#MysqlTuner
skip-innodb
max_connections = 200
wait_timeout = 500
interactive_timeout = 500
query_cache_size = 64M
join_buffer_size = 5M
tmp_table_size = 256M
max_heap_table_size = 256M
table_cache = 4096
key_buffer_size = 2048M
[mysqld_safe]
log-error = /var/log/mysqld.log
</code>

We've seen similar problem as described in
http://dba.stackexchange.com/questions/41601/mysql-high-cpu-usage-myisam-table-indexes
which I've adjust the key_buffer_size to 2048M so it's greater than MyISAM index
<code>
mysql> sELECT SUM(index_length) ndxsize FROM information_schema.tables WHERE engine='MyISAM';
+------------+
| ndxsize |
+------------+
| 1876895744 |
+------------+
</code>
MySQL continues to have high %CPU, our system admin suggested that we add more RAM to the box, will this solve the problem?
Any suggestions are appreciated. Thanks!!

Below is some more detailed information that I pulled out:

<code>
mysql> show status;
+--------------------------------+------------+
| Variable_name | Value |
+--------------------------------+------------+
| Aborted_clients | 7 |
| Aborted_connects | 101 |
| Binlog_cache_disk_use | 0 |
| Binlog_cache_use | 0 |
| Bytes_received | 115 |
| Bytes_sent | 186 |
| Com_admin_commands | 0 |
| Com_assign_to_keycache | 0 |
| Com_alter_db | 0 |
| Com_alter_db_upgrade | 0 |
| Com_alter_event | 0 |
| Com_alter_function | 0 |
| Com_alter_procedure | 0 |
| Com_alter_server | 0 |
| Com_alter_table | 0 |
| Com_alter_tablespace | 0 |
| Com_analyze | 0 |
| Com_backup_table | 0 |
| Com_begin | 0 |
| Com_binlog | 0 |
| Com_call_procedure | 0 |
| Com_change_db | 0 |
| Com_change_master | 0 |
| Com_check | 0 |
| Com_checksum | 0 |
| Com_commit | 0 |
| Com_create_db | 0 |
| Com_create_event | 0 |
| Com_create_function | 0 |
| Com_create_index | 0 |
| Com_create_procedure | 0 |
| Com_create_server | 0 |
| Com_create_table | 0 |
| Com_create_trigger | 0 |
| Com_create_udf | 0 |
| Com_create_user | 0 |
| Com_create_view | 0 |
| Com_dealloc_sql | 0 |
| Com_delete | 0 |
| Com_delete_multi | 0 |
| Com_do | 0 |
| Com_drop_db | 0 |
| Com_drop_event | 0 |
| Com_drop_function | 0 |
| Com_drop_index | 0 |
| Com_drop_procedure | 0 |
| Com_drop_server | 0 |
| Com_drop_table | 0 |
| Com_drop_trigger | 0 |
| Com_drop_user | 0 |
| Com_drop_view | 0 |
| Com_empty_query | 0 |
| Com_execute_sql | 0 |
| Com_flush | 0 |
| Com_grant | 0 |
| Com_ha_close | 0 |
| Com_ha_open | 0 |
| Com_ha_read | 0 |
| Com_help | 0 |
| Com_insert | 0 |
| Com_insert_select | 0 |
| Com_install_plugin | 0 |
| Com_kill | 0 |
| Com_load | 0 |
| Com_load_master_data | 0 |
| Com_load_master_table | 0 |
| Com_lock_tables | 0 |
| Com_optimize | 0 |
| Com_preload_keys | 0 |
| Com_prepare_sql | 0 |
| Com_purge | 0 |
| Com_purge_before_date | 0 |
| Com_release_savepoint | 0 |
| Com_rename_table | 0 |
| Com_rename_user | 0 |
| Com_repair | 0 |
| Com_replace | 0 |
| Com_replace_select | 0 |
| Com_reset | 0 |
| Com_restore_table | 0 |
| Com_revoke | 0 |
| Com_revoke_all | 0 |
| Com_rollback | 0 |
| Com_rollback_to_savepoint | 0 |
| Com_savepoint | 0 |
| Com_select | 1 |
| Com_set_option | 0 |
| Com_show_authors | 0 |
| Com_show_binlog_events | 0 |
| Com_show_binlogs | 0 |
| Com_show_charsets | 0 |
| Com_show_collations | 0 |
| Com_show_column_types | 0 |
| Com_show_contributors | 0 |
| Com_show_create_db | 0 |
| Com_show_create_event | 0 |
| Com_show_create_func | 0 |
| Com_show_create_proc | 0 |
| Com_show_create_table | 0 |
| Com_show_create_trigger | 0 |
| Com_show_databases | 0 |
| Com_show_engine_logs | 0 |
| Com_show_engine_mutex | 0 |
| Com_show_engine_status | 0 |
| Com_show_events | 0 |
| Com_show_errors | 0 |
| Com_show_fields | 0 |
| Com_show_function_status | 0 |
| Com_show_grants | 0 |
| Com_show_keys | 0 |
| Com_show_master_status | 0 |
| Com_show_new_master | 0 |
| Com_show_open_tables | 0 |
| Com_show_plugins | 0 |
| Com_show_privileges | 0 |
| Com_show_procedure_status | 0 |
| Com_show_processlist | 0 |
| Com_show_profile | 0 |
| Com_show_profiles | 0 |
| Com_show_slave_hosts | 0 |
| Com_show_slave_status | 0 |
| Com_show_status | 1 |
| Com_show_storage_engines | 0 |
| Com_show_table_status | 0 |
| Com_show_tables | 0 |
| Com_show_triggers | 0 |
| Com_show_variables | 0 |
| Com_show_warnings | 0 |
| Com_slave_start | 0 |
| Com_slave_stop | 0 |
| Com_stmt_close | 0 |
| Com_stmt_execute | 0 |
| Com_stmt_fetch | 0 |
| Com_stmt_prepare | 0 |
| Com_stmt_reprepare | 0 |
| Com_stmt_reset | 0 |
| Com_stmt_send_long_data | 0 |
| Com_truncate | 0 |
| Com_uninstall_plugin | 0 |
| Com_unlock_tables | 0 |
| Com_update | 0 |
| Com_update_multi | 0 |
| Com_xa_commit | 0 |
| Com_xa_end | 0 |
| Com_xa_prepare | 0 |
| Com_xa_recover | 0 |
| Com_xa_rollback | 0 |
| Com_xa_start | 0 |
| Compression | OFF |
| Connections | 968489 |
| Created_tmp_disk_tables | 0 |
| Created_tmp_files | 11032 |
| Created_tmp_tables | 0 |
| Delayed_errors | 0 |
| Delayed_insert_threads | 0 |
| Delayed_writes | 0 |
| Flush_commands | 1 |
| Handler_commit | 0 |
| Handler_delete | 0 |
| Handler_discover | 0 |
| Handler_prepare | 0 |
| Handler_read_first | 0 |
| Handler_read_key | 0 |
| Handler_read_next | 0 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 0 |
| Handler_rollback | 0 |
| Handler_savepoint | 0 |
| Handler_savepoint_rollback | 0 |
| Handler_update | 0 |
| Handler_write | 0 |
| Key_blocks_not_flushed | 0 |
| Key_blocks_unused | 1437009 |
| Key_blocks_used | 277727 |
| Key_read_requests | 2674695082 |
| Key_reads | 275649 |
| Key_write_requests | 5678071 |
| Key_writes | 306760 |
| Last_query_cost | 0.000000 |
| Max_used_connections | 54 |
| Not_flushed_delayed_rows | 0 |
| Open_files | 1567 |
| Open_streams | 0 |
| Open_table_definitions | 531 |
| Open_tables | 1041 |
| Opened_files | 1526891 |
| Opened_table_definitions | 0 |
| Opened_tables | 0 |
| Prepared_stmt_count | 0 |
| Qcache_free_blocks | 10730 |
| Qcache_free_memory | 35561560 |
| Qcache_hits | 4540664 |
| Qcache_inserts | 4497693 |
| Qcache_lowmem_prunes | 438462 |
| Qcache_not_cached | 698900 |
| Qcache_queries_in_cache | 17658 |
| Qcache_total_blocks | 46546 |
| Queries | 13187921 |
| Questions | 2 |
| Rpl_status | NULL |
| Select_full_join | 0 |
| Select_full_range_join | 0 |
| Select_range | 0 |
| Select_range_check | 0 |
| Select_scan | 0 |
| Slave_open_temp_tables | 0 |
| Slave_retried_transactions | 0 |
| Slave_running | OFF |
| Slow_launch_threads | 3 |
| Slow_queries | 0 |
| Sort_merge_passes | 0 |
| Sort_range | 0 |
| Sort_rows | 0 |
| Sort_scan | 0 |
| Ssl_accept_renegotiates | 0 |
| Ssl_accepts | 0 |
| Ssl_callback_cache_hits | 0 |
| Ssl_cipher | |
| Ssl_cipher_list | |
| Ssl_client_connects | 0 |
| Ssl_connect_renegotiates | 0 |
| Ssl_ctx_verify_depth | 0 |
| Ssl_ctx_verify_mode | 0 |
| Ssl_default_timeout | 0 |
| Ssl_finished_accepts | 0 |
| Ssl_finished_connects | 0 |
| Ssl_session_cache_hits | 0 |
| Ssl_session_cache_misses | 0 |
| Ssl_session_cache_mode | NONE |
| Ssl_session_cache_overflows | 0 |
| Ssl_session_cache_size | 0 |
| Ssl_session_cache_timeouts | 0 |
| Ssl_sessions_reused | 0 |
| Ssl_used_session_cache_entries | 0 |
| Ssl_verify_depth | 0 |
| Ssl_verify_mode | 0 |
| Ssl_version | |
| Table_locks_immediate | 11982888 |
| Table_locks_waited | 158688 |
| Tc_log_max_pages_used | 0 |
| Tc_log_page_size | 0 |
| Tc_log_page_waits | 0 |
| Threads_cached | 13 |
| Threads_connected | 4 |
| Threads_created | 3811 |
| Threads_running | 4 |
| Uptime | 169005 |
| Uptime_since_flush_status | 169005 |
+--------------------------------+------------+
249 rows in set (0.00 sec)
</code>

A few samples of mysql: SHOW PROCESSLIST, there doesn't seem to be long query locking the table.

<code>
mysql> show processlist;
+---------+--------------+--------------------+----------+-------------+--------+----------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State |
+---------+--------------+--------------------+----------+-------------+--------+----------------------------------------------------------------+-
| 275 | repl | 64.237.59.18:55594 | NULL | Binlog Dump | 224213 | Has sent all binlog to slave; waiting for binlog to be updated |
| 1278042 | root | localhost | rewards1 | Query | 0 | NULL |
| 1279440 | rewards_user | localhost | rewards1 | Query | 1 | Sending data |
| 1279441 | rewards_user | localhost | rewards1 | Query | 1 | Sending data |
| 1279444 | rewards_user | localhost | rewards1 | Query | 1 | Locked |
+---------+--------------+--------------------+----------+-------------+--------+----------------------------------------------------------------mysql> show processlist;
+---------+--------------+--------------------+----------+-------------+--------+----------------------------------------------------------------+-
| Id | User | Host | db | Command | Time | State |
+---------+--------------+--------------------+----------+-------------+--------+----------------------------------------------------------------+
| 275 | repl | 64.237.59.18:55594 | NULL | Binlog Dump | 224383 | Has sent all binlog to slave; waiting for binlog to be updated |
| 1278042 | root | localhost | rewards1 | Query | 0 | NULL |
| 1279972 | rewards_user | localhost | rewards1 | Query | 1 | Sending data |
| 1279973 | rewards_user | localhost | rewards1 | Query | 1 | Sending data |
| 1279974 | rewards_user | localhost | rewards1 | Query | 1 | Sending data |
| 1279975 | rewards_user | localhost | rewards1 | Query | 0 | Sending data |
+---------+--------------+--------------------+----------+-------------+--------+----------------------------------------------------------------+
</code>

The following update statement times out:

UPDATE final f, crsp_stocknames q
SET f.permno=q.permno, f.ncusip=q.ncusip, f.namedt=q.namedt, f.nameenddt=q.nameenddt, f.ticker=q.ticker
WHERE f.ncusip is null AND f.symbol LIKE concat(q.ticker,'%') AND f.name LIKE concat(q.comnam,'%') AND (f.datef BETWEEN q.namedt and q.nameenddt);

The objective is to find at the same time partial matches of the symbol and name in the crsp table, (and it has to happen for a given time interval).


The tables are:

CREATE TABLE `final` (
`PK` int(11) NOT NULL AUTO_INCREMENT,
`permno` int(11) DEFAULT NULL,
`cusip` char(8) DEFAULT NULL,
`ncusip` char(8) DEFAULT NULL,
`namedt` int(11) DEFAULT NULL,
`datef` int(11) DEFAULT NULL,
`nameenddt` int(11) DEFAULT NULL,
`symbol` varchar(10) DEFAULT NULL,
`ticker` varchar(10) DEFAULT NULL,
`name` varchar(30) DEFAULT NULL,
PRIMARY KEY (`PK`) KEY_BLOCK_SIZE=8,
KEY `final_cusip` (`cusip`),
KEY `final_symbol` (`symbol`),
KEY `final_datef` (`datef`),
KEY `final_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=65536 DEFAULT CHARSET=utf8

CREATE TABLE `crsp_stocknames` (
`PK` int(10) unsigned NOT NULL AUTO_INCREMENT,
`permno` int(10) DEFAULT NULL,
`permco` int(11) DEFAULT NULL,
`namedt` int(11) DEFAULT NULL,
`nameenddt` int(11) DEFAULT NULL,
`cusip` char(8) DEFAULT NULL,
`ncusip` char(8) DEFAULT NULL,
`ticker` varchar(10) DEFAULT NULL,
`comnam` varchar(40) DEFAULT NULL,
`hexcd` tinyint(4) DEFAULT NULL,
`exchcd` tinyint(4) DEFAULT NULL,
`siccd` smallint(5) unsigned DEFAULT NULL,
`shrcd` tinyint(4) DEFAULT NULL,
`shrcls` char(1) DEFAULT NULL,
`st_date` int(10) unsigned DEFAULT NULL,
`end_date` int(10) unsigned DEFAULT NULL,
`namedum` tinyint(4) DEFAULT NULL,
PRIMARY KEY (`PK`),
UNIQUE KEY `PK_UNIQUE` (`PK`),
KEY `stocknames_ncusip` (`ncusip`),
KEY `stocknames_namedt` (`namedt`),
KEY `stocknames_nameenddt` (`nameenddt`),
FULLTEXT KEY `stocknames_name` (`comnam`),
FULLTEXT KEY `stocknames_ticker` (`ticker`)
) ENGINE=InnoDB AUTO_INCREMENT=55973 DEFAULT CHARSET=utf8

The status:

# Name Engine Version Row_format Rows Avg_row_length Data_length Max_data_length Index_length Data_free Auto_increment Create_time Update_time Check_time Collation Checksum Create_options Comment
crsp_stocknames InnoDB 10 Compact 55711 122 6832128 0 9535488 2097152 55973 2014-03-25 21:35:01 utf8_general_ci
final InnoDB 10 Compact 57402 82 4734976 0 10551296 4194304 65536 2014-03-25 18:29:07 2014-03-25 21:38:39 utf8_general_ci

And the explain of the update:

# id, select_type, table, partitions, type, possible_keys, key, key_len, ref, rows, filtered, Extra
1, SIMPLE, q, , ALL, stocknames_namedt,stocknames_nameenddt, , , , 55711, 100.00,
1, UPDATE, f, , ALL, final_datef, , , , 57402, 100.00, Range checked for each record (index map: 0x8)

Is there something fundamental I am missing? Amd could you explain if the explain is legit, because it says potential keys, but the keys field is empty.


Note that I have not tweaked the .conf

[UPDATE]

The following select runs in 13 seconds:

select f.*
from final f
inner join crsp_stocknames q on f.symbol LIKE concat(q.ticker,'%') AND f.name LIKE concat(q.comnam,'%')
AND (f.datef BETWEEN q.namedt and q.nameenddt)
WHERE f.ncusip is null and q.ticker is not null and q.comnam is not null

MySQL Performance Schema : Prepared Statements Instrumentation
http://mayankmysql.blogspot.com/2014/04/mysql-performance-schema-prepared.html

MySQL Workbench: Performance Dashboard
http://mysqlworkbench.org/2014/04/whats-new-in-mysql-workbench-6-1/

i have inherited the task of maintaining a mysql DB with amazon.
we're using mysql as an rds service from AWS.
i'm suffering from high lag between master and slave + max connections, so i decided to check my instance with mysqltuner.
i got interesting result, though some of them i did not get.
i hope you can guide me in the right direction in understanding whats given to me by mysqltuner:

------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 2G (Tables: 21)
[--] Data in InnoDB tables: 113G (Tables: 915)
[--] Data in MEMORY tables: 0B (Tables: 2)
[!!] Total fragmented tables: 485
-------- Performance Metrics -------------------------------------------------
[--] Up for: 31d 3h 53m 41s (302M q [112.267 qps], 70M conn, TX: 3882B, RX: 255B)
[--] Reads / Writes: 40% / 60%
[--] Total buffers: 11.1G global + 3.1M per thread (1263 max threads)
[!!] Maximum possible memory usage: 15.0G (102% of installed RAM)
[OK] Slow queries: 0% (130K/302M)
[!!] Highest connection usage: 100% (1266/1263)
[OK] Key buffer size / total MyISAM indexes: 16.0M/2.8G
[OK] Key buffer hit rate: 99.0% (12B cached / 123M reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (1K temp sorts / 66M sorts)
[!!] Joins performed without indexes: 22671697
[OK] Temporary tables created on disk: 1% (1M on disk / 63M total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (400 open / 1M opened)
[OK] Open file limit used: 0% (47/65K)
[OK] Table locks acquired immediately: 99% (700M immediate / 700M locks)
[!!] InnoDB data size / buffer pool: 113.0G/11.1G

-------- Recommendations -----------------------------------------------------
General recommendations:
(truncated to just show what i'm confused about)
Reduce or eliminate persistent connections to reduce connection usage
Adjust your join queries to always utilize indexes
Set thread_cache_size to 4 as a starting value
Increase table_cache gradually to avoid file descriptor limits



Any advice or hint on understanding the above, would be greatly appreciated

I have this table with 17 millions records. I added some indexes and 90% of time it runs very fast.

But sometimes most queries with this table stop returning any data.

The others queries return normally.

I imagined it was a lock problem, so I added this in all my application:

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ;

MY QUERY HERE

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ ;

It didn't solved the problem.


Any ideas?

I have this query
SELECT ICOF, OKRESLAUF, DDATVZN, DDATZAN, ZPZANF, DDATPAKT, FORMAF, ROSFORMAF, KATPOF, NACEF, KATOF, ICZUJF, FIRMA, ISEKTORF, CISS2010F, KODADM FROM `csu1`.`res1za3c`  ORDER BY ICOF ASC LIMIT 1000 OFFSET 67000
It created a temp file of 4GB
Why?
Data size is only 262,5 MiB
Key size is 363,7 MiB
Thanks

Hello,

so we face a problem regarding mysql is creating temp tables on disk.

The solution will be to change the sort_buffer_size.

So here is my question: How do I can see (select) which databaseusers or select statement is creating the temp tables on disk. Is there anything like 'select * from temp_table_on_disk';

Thanks for the advice !

Hi everyone,

We have a production server (Red Hat 6) with 5.6.16 MySQL Community Server (GPL) and when we execute the following query it uses index:

mysql> explain select distinct date(timestamp) as timestamp,
-> db_user as username,
-> db_name as dbname,
-> srv_name as dbinst,
-> count(*),
-> sum(count) as rowcount
-> from sec_dams_reports_facts
-> where timestamp = curdate() - interval 6 day
-> and count > 0
-> and dams_tech = 'G'
-> group by date(timestamp), db_user, db_name, srv_name;
+----+-------------+------------------------+------+------------------------+------------------------+---------+-------+------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------------------+------+------------------------+------------------------+---------+-------+------+----------------------------------------------+
| 1 | SIMPLE | sec_dams_reports_facts | ref | idx_reports_facts_time | idx_reports_facts_time | 4 | const | 87 | Using where; Using temporary; Using filesort |
+----+-------------+------------------------+------+------------------------+------------------------+---------+-------+------+----------------------------------------------+
1 row in set (0.00 sec)

And when doing this query the index isn't used:

mysql> explain select distinct date(timestamp) as timestamp,
-> db_user as username,
-> db_name as dbname,
-> srv_name as dbinst,
-> count(*),
-> sum(count) as rowcount
-> from sec_dams_reports_facts
-> where timestamp >= curdate() - interval 6 day
-> and count > 0
-> and dams_tech = 'G'
-> group by date(timestamp), db_user, db_name, srv_name;
+----+-------------+------------------------+------+------------------------+------+---------+------+-----------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------------------+------+------------------------+------+---------+------+-----------+----------------------------------------------+
| 1 | SIMPLE | sec_dams_reports_facts | ALL | idx_reports_facts_time | NULL | NULL | NULL | 195910374 | Using where; Using temporary; Using filesort |
+----+-------------+------------------------+------+------------------------+------+---------+------+-----------+----------------------------------------------+

The table structure is the following:

+---------------+---------------+------+-----+-------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+---------------+------+-----+-------------------+-----------------------------+
| timestamp | timestamp | NO | MUL | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| dams_tech | char(1) | NO | | NULL | |
| dams_source | varchar(15) | NO | | NULL | |
| db_brand | char(1) | NO | | NULL | |
| c_ip | varchar(15) | YES | | NULL | |
| db_user | varchar(30) | YES | | NULL | |
| os_user | varchar(30) | YES | | NULL | |
| s_ip | varchar(15) | YES | | NULL | |
| srv_name | varchar(50) | YES | | NULL | |
| db_name | varchar(50) | YES | | NULL | |
| src_prg | varchar(200) | YES | | NULL | |
| net_prot | varchar(15) | YES | | NULL | |
| net_prot_type | varchar(15) | YES | | NULL | |
| sql_verb | varchar(50) | YES | | NULL | |
| obj_name | varchar(50) | YES | | NULL | |
| field_name | varchar(50) | YES | | NULL | |
| policy_name | varchar(200) | YES | | NULL | |
| sql_id | decimal(25,0) | YES | MUL | NULL | |
| count | int(11) | YES | | NULL | |
+---------------+---------------+------+-----+-------------------+-----------------------------+

And as this indexes:

mysql> show index from sec_dams_reports_facts;
+------------------------+------------+-------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+------------------------+------------+-------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| sec_dams_reports_facts | 1 | idx_reports_facts_time | 1 | timestamp | A | 11973417 | NULL | NULL | | BTREE | | |
| sec_dams_reports_facts | 1 | idx_reports_facts_sqlid | 1 | sql_id | A | 20810940 | NULL | NULL | YES | BTREE | | |
+------------------------+------------+-------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

Any ideas why this happen?

Hi,

I am using MySQL 5.1 on a Windows Server 2008 (with 4GB RAM) and have the following configuration:

I have 2 MyISAM tables. One is in 1 database (DB1) and has 14 columns, which are mostly varchar. This table has about 5,000,000 rows and is the DB1.games table below.

It has a primary key on GameNumber (int(10)).

The other table is the DB2.gameposition and consists of the columns GameNumber (links to DB1.games) and PositionCode (int(10)). This table has about 400,000,000 rows and there is an index IX_PositionCode on PositionCode.

These 2 databases are on the same server.

I want to run a query on DB2.gameposition to find a particular PositionCode, and have the results sorted by the linking DB1.games.Yr field (smallint(6) - this represents a Year). This sorting of results I only introduced recently. There is an index on this Yr field in DB1.games.

In my stored procedure, I perform the following:

CREATE TEMPORARY TABLE tblGameNumbers(GameNumber INT UNSIGNED NOT NULL PRIMARY KEY);

INSERT INTO tblGameNumbers(GameNumber)
SELECT DISTINCT gp.GameNumber
FROM DB2.gameposition gp
WHERE PositionCode = var_PositionCode LIMIT 1000;

I just get 1000 to make it quicker...

And then I join it to the DB1.games table.

In order to generate an EXPLAIN from that, I took out the temporary table (I use in the stored procedure) and refactored it as seen in the inner subquery below:

EXPLAIN
SELECT *
FROM DB1.games g
INNER JOIN (SELECT DISTINCT gp.GameNumber
FROM DB2.gameposition gp
WHERE PositionCode = 669312116 LIMIT 1000
) B ON g.GameNumber = B.GameNumber
ORDER BY g.Yr DESC
LIMIT 0,28

Running the EXPLAIN above, I see the following:

1, 'PRIMARY', '', 'ALL', '', '', '', '', 1000, 'Using temporary; Using filesort'
1, 'PRIMARY', 'g', 'eq_ref', 'PRIMARY', 'PRIMARY', '4', 'B.GameNumber', 1, ''
2, 'DERIVED', 'gp', 'ref', 'IX_PositionCode', 'IX_PositionCode', '4', '', 1889846, 'Using temporary'

The query used to be almost instant before I introduced the ORDER BY clause. Now, sometimes it is quick (depending on different PositionCode), but other times it can take up to 10 seconds to return the rows. Before I introduced the sorting, it was always virtually instantaneous. Unfortunately, I am not too proficient in interpreting the EXPLAIN output. Or how to make the query faster.

I am thinking of increasing the server memory to 8GB and tune some variables (amongst them the key_buffer_size variable which is currently 512M)...would this be of any help?

Any help would be greatly appreciated!

Thanks in advance, Tim

I have a MyISAM table (call it A) with about 5 million rows, and a related MyISAM table B (which joins to A on the primary key) containing about 400 million rows. Table A has 14 fields, mostly varchar, while table B contains 2 integer fields.

I originally created these tables locally on my Windows 8 machine (4GB RAM - SSD Hard disk) by running scripts which inserted the rows in chunks. I then mysqldump'ed the database to a .sql file.

I then transferred this .sql file to my LIVE environment (Windows Server 2008, 4GB RAM and non-SSD Hard disk). I restored the database from the dump file to a new database.

If I now perform an update of, say, 2000 rows (in A; and about 80 in B for each row inserted in A) in the local machine, it takes a couple of minutes (maybe 3 at most), whilst if I updated the same rows on the LIVE environment, it would take about 1.5 hours.

Why is there this significant difference? Both the local and LIVE machines have the same memory, and specs are very similar...Could it be down to the fact that my local machine has an SSD hard drive? Or do I need to perform an OPTIMIZE/ANALYZE table(s) (or anything else?) on the LIVE database? (I only do inserts on both A and B, I never delete or update).

Thanks in advance, Tim

Hi, our web developer is suggesting we make the following value changes in our my.cnf file. Just wondering if these changes could have any negative impact on our server and/or sites.


max_allowed_packet = 512M
sort_buffer_size = 128M
read_buffer_size = 128M
wait_timeout = 3600
net_read_timeout = 3600

Thanks

MySQL is hanging up on a query where the subcomponents of the query all seem to work as expected. The whole query is:

SELECT IDIR,Surname,GivenName,BirthD,IDLRBirth FROM tblIR WHERE IDIR IN (SELECT DISTINCT IDIR FROM tblER WHERE IDType=0 AND (IDLREvent=96526 || IDLREvent=95981 || IDLREvent=95701 || IDLREvent=12912 || IDLREvent=96008 || IDLREvent=96009 || IDLREvent=10692 || IDLREvent=95980 || IDLREvent=75204 || IDLREvent=95951 || IDLREvent=12815 || IDLREvent=3784 || IDLREvent=33777 || IDLREvent=96374 || IDLREvent=94456 || IDLREvent=66760 || IDLREvent=18117 || IDLREvent=79123 || IDLREvent=21376 || IDLREvent=96376 || IDLREvent=21411 || IDLREvent=94451 || IDLREvent=20714 || IDLREvent=33896 || IDLREvent=21471 || IDLREvent=80322 || IDLREvent=21487 || IDLREvent=21512 || IDLREvent=21525 || IDLREvent=21530 || IDLREvent=21532 || IDLREvent=21601 || IDLREvent=92640 || IDLREvent=4802 || IDLREvent=96078 || IDLREvent=19660 || IDLREvent=96336 || IDLREvent=33925 || IDLREvent=33805 || IDLREvent=24843 || IDLREvent=21787 || IDLREvent=21796 || IDLREvent=95948 || IDLREvent=20444 || IDLREvent=21837 || IDLREvent=94452 || IDLREvent=21877 || IDLREvent=95950 || IDLREvent=95949 || IDLREvent=96377 || IDLREvent=21882 || IDLREvent=21924 || IDLREvent=93743 || IDLREvent=21935 || IDLREvent=93714 || IDLREvent=21960 || IDLREvent=92647 || IDLREvent=21975 || IDLREvent=20449 || IDLREvent=96529 || IDLREvent=93180 || IDLREvent=93719 || IDLREvent=22013 || IDLREvent=96532 || IDLREvent=93713 || IDLREvent=96527 || IDLREvent=22050 || IDLREvent=39040 || IDLREvent=22083 || IDLREvent=96894 || IDLREvent=25196 || IDLREvent=22132 || IDLREvent=22145 || IDLREvent=22154 || IDLREvent=6144 || IDLREvent=92629 || IDLREvent=22155 || IDLREvent=22157 || IDLREvent=95630 || IDLREvent=93239 || IDLREvent=70696 || IDLREvent=22220 || IDLREvent=22223 || IDLREvent=22229 || IDLREvent=59488 || IDLREvent=22228 || IDLREvent=33926 || IDLREvent=22235 || IDLREvent=33932 || IDLREvent=33797 || IDLREvent=33795 || IDLREvent=96037 || IDLREvent=95929 || IDLREvent=22311 || IDLREvent=96766 || IDLREvent=13750 || IDLREvent=59487 || IDLREvent=33674 || IDLREvent=96036 || IDLREvent=22329 || IDLREvent=96075 || IDLREvent=22338 || IDLREvent=22344 || IDLREvent=22359 || IDLREvent=34261 || IDLREvent=96015 || IDLREvent=96034 || IDLREvent=95996 || IDLREvent=22387 || IDLREvent=22390 || IDLREvent=22391 || IDLREvent=96007 || IDLREvent=22402 || IDLREvent=96528 || IDLREvent=95992 || IDLREvent=95991 || IDLREvent=96035 || IDLREvent=22416 || IDLREvent=22422 || IDLREvent=22423 || IDLREvent=25382 || IDLREvent=59484 || IDLREvent=95994 || IDLREvent=96032 || IDLREvent=22440 || IDLREvent=22441 || IDLREvent=33771 || IDLREvent=33800 || IDLREvent=22489 || IDLREvent=22490 || IDLREvent=95995 || IDLREvent=24667 || IDLREvent=22497 || IDLREvent=96038 || IDLREvent=92639 || IDLREvent=22498 || IDLREvent=96767 || IDLREvent=22500 || IDLREvent=33770 || IDLREvent=96810 || IDLREvent=95595 || IDLREvent=95526 || IDLREvent=92635 || IDLREvent=4607 || IDLREvent=22604 || IDLREvent=34042 || IDLREvent=22665 || IDLREvent=33796 || IDLREvent=33851 || IDLREvent=75232 || IDLREvent=33801 || IDLREvent=22773 || IDLREvent=1486 || IDLREvent=1515 || IDLREvent=94454 || IDLREvent=95947 || IDLREvent=93098 || IDLREvent=39037 || IDLREvent=22820 || IDLREvent=2404 || IDLREvent=95946 || IDLREvent=22824 || IDLREvent=94885 || IDLREvent=23284 || IDLREvent=96010 || IDLREvent=33462 || IDLREvent=23593 || IDLREvent=96142 || IDLREvent=23626 || IDLREvent=94379 || IDLREvent=23632 || IDLREvent=96586 || IDLREvent=93175 || IDLREvent=24045 || IDLREvent=24131 || IDLREvent=20003 || IDLREvent=24196 || IDLREvent=24197 || IDLREvent=19259 || IDLREvent=66365 || IDLREvent=33570 || IDLREvent=16279 || IDLREvent=9727 || IDLREvent=6558 || IDLREvent=96077 || IDLREvent=17424 || IDLREvent=25233 || IDLREvent=25273 || IDLREvent=33170 || IDLREvent=92637 || IDLREvent=24503 || IDLREvent=24511 || IDLREvent=33891 || IDLREvent=96375 || IDLREvent=24551 || IDLREvent=33143 || IDLREvent=25228 || IDLREvent=419 || IDLREvent=96702 || IDLREvent=12775 || IDLREvent=7555 || IDLREvent=3943 || IDLREvent=11630 || IDLREvent=11945 || IDLREvent=45687 || IDLREvent=75202) ORDER BY IDIR) ORDER BY Surname,GivenName LIMIT 20 OFFSET 0

The subquery, ridiculous as it is, takes only 0.54 seconds to execute against a table with 43,233 rows and returns 468 values of IDIR. But the query as a whole never completes.

EXPLAIN reports:
+----+--------------------+-------+------+---------------+------+---------+------+-------+------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------------+-------+------+---------------+------+---------+------+-------+------------------------------+
| 1 | PRIMARY | tblIR | ALL | NULL | NULL | NULL | NULL | 76372 | Using where; Using filesort |
| 2 | DEPENDENT SUBQUERY | tblER | ALL | NULL | NULL | NULL | NULL | 43233 | Using where; Using temporary |
+----+--------------------+-------+------+---------------+------+---------+------+-------+------------------------------+
2 rows in set (0.00 sec)

Since the subquery returns a list of unique keys for the main table, how do I restructure this SELECT so that it can use the index?

The definition of tblER is:
CREATE TABLE `tblER` (
`IDER` int(10) unsigned NOT NULL AUTO_INCREMENT,
`IDIR` int(10) unsigned DEFAULT NULL,
`IDET` int(10) unsigned DEFAULT NULL,
`Order` smallint(5) DEFAULT NULL,
`EventD` varchar(100) DEFAULT NULL,
`EventSD` int(10) DEFAULT NULL,
`IDLREvent` int(10) unsigned DEFAULT NULL,
`Desc` longtext,
`GEDTag` varchar(30) DEFAULT NULL,
`EventExclude` tinyint(3) unsigned,
`IDType` tinyint(3) unsigned DEFAULT NULL,
`IDAR` int(10) unsigned DEFAULT NULL,
`Description` varchar(255) DEFAULT NULL,
`SentenceOverride` varchar(255) DEFAULT NULL,
`qsTag` tinyint(3) unsigned DEFAULT NULL,
`RGExclude` tinyint(3) unsigned DEFAULT NULL,
PRIMARY KEY (`IDER`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

The definition of tblIR is:

CREATE TABLE `tblIR` (
`ID` int(10) NOT NULL AUTO_INCREMENT,
`IDIR` int(10) DEFAULT NULL,
`FSID` varchar(255) DEFAULT NULL,
`Surname` varchar(120) DEFAULT NULL,
`SoundsLike` varchar(4) DEFAULT NULL,
`GivenName` varchar(120) DEFAULT NULL,
`Prefix` varchar(120) DEFAULT NULL,
`Title` varchar(120) DEFAULT NULL,
`NameNote` longtext,
`Gender` tinyint(3) unsigned DEFAULT NULL,
`BirthD` varchar(100) DEFAULT NULL,
`BirthSD` int(10) DEFAULT NULL,
`IDLRBirth` int(10) DEFAULT NULL,
`ChrisD` varchar(100) DEFAULT NULL,
`ChrisSD` int(10) DEFAULT NULL,
`IDLRChris` int(10) DEFAULT NULL,
`ChrTerm` varchar(100) DEFAULT NULL,
`DeathD` varchar(100) DEFAULT NULL,
`DeathSD` int(10) DEFAULT NULL,
`IDLRDeath` int(10) DEFAULT NULL,
`BuriedD` varchar(100) DEFAULT NULL,
`BuriedSD` int(10) DEFAULT NULL,
`IDLRBuried` int(10) DEFAULT NULL,
`Cremated` tinyint(3) unsigned DEFAULT NULL,
`IDARBirth` int(10) DEFAULT NULL,
`IDARChris` int(10) DEFAULT NULL,
`IDARDeath` int(10) DEFAULT NULL,
`IDARBuried` int(10) DEFAULT NULL,
`BirthNote` longtext,
`ChrisNote` longtext,
`DeathNote` longtext,
`BuriedNote` longtext,
`Living` tinyint(3) unsigned DEFAULT NULL,
`BaptismD` varchar(100) DEFAULT NULL,
`BaptismSD` int(10) DEFAULT NULL,
`BaptismKind` tinyint(3) unsigned DEFAULT NULL,
`IDTRBaptism` int(10) DEFAULT NULL,
`BaptismNote` longtext,
`LDSB` tinyint(3) unsigned DEFAULT NULL,
`ConfirmationD` varchar(100) DEFAULT NULL,
`ConfirmationSD` int(10) DEFAULT NULL,
`ConfirmationKind` tinyint(3) unsigned DEFAULT NULL,
`IDTRConfirmation` int(10) DEFAULT NULL,
`ConfirmationNote` longtext,
`LDSC` tinyint(3) unsigned DEFAULT NULL,
`InitiatoryD` varchar(100) DEFAULT NULL,
`InitiatorySD` int(10) DEFAULT NULL,
`IDTRInitiatory` int(10) DEFAULT NULL,
`InitiatoryNote` longtext,
`LDSI` tinyint(3) unsigned DEFAULT NULL,
`EndowD` varchar(100) DEFAULT NULL,
`EndowSD` int(10) DEFAULT NULL,
`IDTREndow` int(10) DEFAULT NULL,
`EndowNote` longtext,
`LDSE` tinyint(3) unsigned DEFAULT NULL,
`TempleTag` tinyint(3) unsigned DEFAULT NULL,
`IDMRPref` int(10) DEFAULT NULL,
`IDMRParents` int(10) DEFAULT NULL,
`IDAR` int(10) DEFAULT NULL,
`AncInterest` tinyint(3) unsigned DEFAULT NULL,
`DecInterest` tinyint(3) unsigned DEFAULT NULL,
`Tag1` tinyint(3) unsigned DEFAULT NULL,
`Tag2` tinyint(3) unsigned DEFAULT NULL,
`Tag3` tinyint(3) unsigned DEFAULT NULL,
`Tag4` tinyint(3) unsigned DEFAULT NULL,
`Tag5` tinyint(3) unsigned DEFAULT NULL,
`Tag6` tinyint(3) unsigned DEFAULT NULL,
`Tag7` tinyint(3) unsigned DEFAULT NULL,
`Tag8` tinyint(3) unsigned DEFAULT NULL,
`Tag9` tinyint(3) unsigned DEFAULT NULL,
`TagGroup` tinyint(3) unsigned DEFAULT NULL,
`TagAnc` tinyint(3) unsigned DEFAULT NULL,
`TagDec` tinyint(3) unsigned DEFAULT NULL,
`SaveTag` tinyint(3) unsigned DEFAULT NULL,
`SrchTag` tinyint(3) unsigned DEFAULT NULL,
`SrchTagIGI` tinyint(3) unsigned DEFAULT NULL,
`SrchTagRG` tinyint(3) unsigned DEFAULT NULL,
`SrchTagFS` tinyint(3) unsigned DEFAULT NULL,
`qsTag` tinyint(3) unsigned DEFAULT NULL,
`ReminderTag` tinyint(3) unsigned DEFAULT NULL,
`ReminderTagDeath` tinyint(3) unsigned DEFAULT NULL,
`TreeNum` smallint(5) DEFAULT NULL,
`LTMP1` int(10) DEFAULT NULL,
`LTMP2` int(10) DEFAULT NULL,
`AlreadyUsed` tinyint(3) unsigned DEFAULT NULL,
`UserRef` varchar(50) DEFAULT NULL,
`AncestralRef` varchar(20) DEFAULT NULL,
`Notes` longtext,
`References` longtext,
`Medical` longtext,
`DeathCause` varchar(255) DEFAULT NULL,
`PPCheck` tinyint(3) unsigned DEFAULT NULL,
`Imported` tinyint(3) unsigned DEFAULT NULL,
`Added` int(10) DEFAULT NULL,
`AddedTime` varchar(5) DEFAULT NULL,
`Updated` int(10) DEFAULT NULL,
`UpdatedTime` varchar(5) DEFAULT NULL,
`Relations` varchar(20) DEFAULT NULL,
`NeverMarried` tinyint(3) unsigned DEFAULT NULL,
`DirectLine` tinyint(3) unsigned DEFAULT NULL,
`STMP1` varchar(255) DEFAULT NULL,
`ColorTag` tinyint(3) unsigned DEFAULT NULL,
`IntelliShare` varchar(50) DEFAULT NULL,
`Private` tinyint(3) unsigned DEFAULT NULL,
`PPExclude` varchar(50) DEFAULT NULL,
`RGExclude` tinyint(3) unsigned DEFAULT NULL,
`DNA` longtext,
`FSSync` tinyint(3) unsigned DEFAULT NULL,
`FSDups` tinyint(3) unsigned DEFAULT NULL,
`FSOrdinance` tinyint(3) unsigned DEFAULT NULL,
`FSLinks` longtext,
PRIMARY KEY (`ID`),
UNIQUE KEY `IDIR` (`IDIR`),
KEY `Surname` (`Surname`),
KEY `GivenName` (`GivenName`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

We are using MySql 5.6.10 on Cent OS 6.2 with 32 Cores CPU. Recently we have upgraded RAM from 64G to 189G and updated my.cnf according to the available RAM.
After upgrading the MySql configurations we have observed that Innodb Cache hit ratio is 99% (earlier it is around 60%), Query cache hit ratio is 70% (earlier it is around 60%) and prune ratio is 10% (earlier it is around 50%) but we didn't observe any significant performance improvement instead we are getting insert/update queries in the slow log. DB size is 180G and rate of size increase 10-15% for every month, most of the tables of type InnoDB engine. Below are configuration we have now
key_buffer_size - 2G
query_cache_size - 4G
tmp_table_size - 3G
innodb_buffer_pool_size - 133G
innodb_additional_mem_pool_size - 2G
innodb_log_buffer_size - 1G
max_connections - 500
sort_buffer_size - 8M
read_buffer_size - 32M
read_rnd_buffer_size - 8M
join_buffer_size - 1M
thread_stack - 1M
binlog_cache_size - 0.25
table_open_cache - 1024

Could you please suggest the optimal configurations

I am trying to sum a variable, fPurchaseAmt, which is a float, grouped by iCompanyID, which is a BigInt. Adding an index on iCompanyID seems to have killed the performance. My table, Trans_smp, has 15 million rows, and about 10 other columns. The engine is InnoDB. In an effort to improve performance, I added an index on iCompanyID and another variable, iBrandID:

create index idxCompBrand on Trans_smp (iCompanyID, iBrandID);

No problems. I ran the following test code before and after creating the index:

select iCompanyID, count(fPurchaseAmt) FROM Trans_smp GROUP BY iCompanyID;

Before creating the index, it ran in about 34 seconds, after creating the index, it ran in about 14 seconds.

I then ran the code I want:

select iCompanyID, sum(fPurchaseAmt) FROM Trans_smp GROUP BY iCompanyID;

Before creating the index, it ran in about 33 seconds, roughly the same as the count. After creating the index, it either fails or it takes a long time. The most recent time I tried it, I waited 4 hours and it didn't finish. In an effort to get it to work, I tried creating a second index, limited just to iCompanyID:

create index idxComp on Trans_smp (iCompanyID);

After creating the second index, I tried again and it didn't finish in less than 4 hours, so I pulled the plug.

After creating the second index, I tried again with the following code:

select iCompanyID, sum(fPurchaseAmt)
FROM Trans_smp
ignore index idxCompBrand
ignore index idxComp
GROUP BY iCompanyID
;

Once again, ran without problems in about 33 seconds.

At someone's suggestion, I also tried creating an index on iCompanyID and fPurchaseAmt:

create index idxCompPurchAmt on Trans_smp (iCompanyID, fPurchaseAmt);

This also did not help - after several hours, I killed the sum query before it finished.

Anyone have any ideas about what my problem is, and how to avoid it? Obviously I can just use the "ignore index" approach, but I hope to start using this and similar steps on the full set, with has 350 million rows, so I would like to be able to use indexes.

Here's the full results for "show create table":

create table Trans_smp (
aTrans BigInt bigint(20) unsigned not null default '0'
, iCustID BigInt(20) unsigned default null
, iChainID SmallInt(5) unsigned default null
, iDeptID SmallInt(5) unsigned default null
, iCategoryID BigInt(20) unsigned default null
, iCompanyID BigInt(20) default null
, iBrandID BigInt(20) unsigned default null
, dTransDt date default null
, fProductSz float default null
, cProductMeasure char(8) default null
, iPurchaseQty MediumInt(9) default null
, fPurchaseAmt float default null
, key idxCompBrand (iCompanyID, iBrandID)
, key idxComp (iCompanyID)
, key idxCompPurchAmt (iCompanyID, fPurchaseAmt)
)
engine=InnoDB default charset=latin1;