2013-08-28 111 views
0

民间MySQL查询性能问题与MyISAM表

我有一个表(billing_data)与约6000万条记录。表引擎是MyISAM。我们有一个存储过程,它将读取csv文件并每10-15分钟转储到临时表中,然后将其插入此表(billing_data)中。这个表格中插入了很多记录。

我们正试图在同一张表(加上联接中的其他表)上运行查询以生成报表。

"select b.destination,b.release_cause_protocol_stack,b.binary_value_protocol_stack,b.release_cause from billing_datas b inner join (select id from carriermasters where id in (99, 100, 101)) c1 on b.carrierid_customer=c1.idinner join (select id from technicalprofiles where id in (83, 274, 84, 416)) t1 on b.technical_profileid_customer=t1.id inner join (select trunk from trunks where trunk in (90409, 90310, 30230, 30313)) tr1 on b.origination_trunkid=tr1.trunk inner join (select id from carriermasters where id in (214, 215, 59, 60, 62, 292, 63, 216, 64, 61, 217, 274, 58)) c2 on b.carrierid_supplier=c2.id inner join (select id from technicalprofiles where id in (223, 55, 224, 56, 225, 57, 226, 58, 227, 228, 229, 230, 393, 394, 395, 59, 231, 232, 233, 460, 234)) t2 on b.technical_profileid_supplier=t2.id inner join (select trunk from trunks where trunk in (90106, 30249, 90249, 30250, 90250, 90445, 30409, 90446, 30410, 30294, 90363, 30293, 90293, 30175, 30146, 90146, 90435, 90049, 30177, 90294, 90130, 30130, 90189, 30145, 90145, 90389, 30400, 90429, 90121, 90159)) tr2 on b.supplierid=tr2.trunk where b.start_time_date between '2013-08-02 00:00:00' and '2013-08-02 23:59:59' order by b.start_time_date asc" 

现在的情况是

一)如果我们停止cron作业在billing_datas表中插入数据,然后将上面的查询大约需要40多分钟。 b)如果cron作业正在运行(从文件中插入数据)到临时表,然后到billing_data。那时上面的查询将永远运行。

我不知道我在哪里出错。

我们还检查了索引和罚款。

MySQL查询:显示变量


automatic_sp_privileges ON 
back_log 50 
big_tables OFF 

binlog_cache_size 32768 
binlog_direct_non_transactional_updates OFF 
binlog_format STATEMENT 
bulk_insert_buffer_size 8388608 
completion_type 0 
concurrent_insert 1 
connect_timeout 10 
default_week_format 0 
delay_key_write ON 
delayed_insert_limit 100 
delayed_insert_timeout 300 
delayed_queue_size 1000 
div_precision_increment 4 
engine_condition_pushdown ON 
event_scheduler OFF 
flush OFF 
flush_time 0 
foreign_key_checks ON 
ft_query_expansion_limit 20 
ignore_builtin_innodb OFF 
innodb_adaptive_hash_index ON 
innodb_additional_mem_pool_size 1048576 
innodb_autoextend_increment 8 
innodb_autoinc_lock_mode 1 
innodb_buffer_pool_size 8388608 
innodb_checksums ON 
innodb_commit_concurrency 0 
innodb_concurrency_tickets 500 
innodb_data_file_path ibdata1:10M:autoextend 
innodb_data_home_dir  
innodb_doublewrite ON 
innodb_fast_shutdown 1 
innodb_file_io_threads 4 
innodb_file_per_table OFF 
innodb_flush_log_at_trx_commit 1 
innodb_flush_method 
innodb_force_recovery 0 
innodb_lock_wait_timeout 50 
innodb_locks_unsafe_for_binlog OFF 
innodb_log_buffer_size 1048576 
innodb_log_file_size 5242880 
innodb_log_files_in_group 2 
innodb_max_dirty_pages_pct 90 
innodb_max_purge_lag 0 
innodb_mirrored_log_groups 1 
innodb_open_files 300 
innodb_rollback_on_timeout OFF 
innodb_stats_method nulls_equal 
innodb_stats_on_metadata ON 
innodb_support_xa ON 
innodb_sync_spin_loops 20 
innodb_table_locks ON 
innodb_thread_concurrency 8 
innodb_thread_sleep_delay 10000 
innodb_use_legacy_cardinality_algorithm ON 
insert_id 0 
interactive_timeout 28800 
join_buffer_size 131072 
keep_files_on_create OFF 
key_buffer_size 8384512 
key_cache_age_threshold 300 
key_cache_block_size 1024 
key_cache_division_limit 100 
large_files_support ON 
large_page_size 0 
large_pages OFF 
last_insert_id 0 
local_infile ON 
locked_in_memory OFF 
log OFF 
log_bin OFF 
log_bin_trust_function_creators OFF 
log_bin_trust_routine_creators OFF 
long_query_time 10 
low_priority_updates OFF 
max_allowed_packet 1048576 
max_binlog_cache_size 1.84467E+19 
max_binlog_size 1073741824 
max_connect_errors 10 
max_connections 151 
max_delayed_threads 20 
max_error_count 64 
max_heap_table_size 16777216 
max_insert_delayed_threads 20 
max_join_size 1.84467E+19 
max_length_for_sort_data 1024 
max_long_data_size 1048576 
max_prepared_stmt_count 16382 
max_relay_log_size 0 
max_seeks_for_key 1.84467E+19 
max_sort_length 1024 
max_sp_recursion_depth 0 
max_tmp_tables 32 
max_user_connections 0 
max_write_lock_count 1.84467E+19 
min_examined_row_limit 0 
multi_range_count 256 
myisam_data_pointer_size 6 
myisam_max_sort_file_size 9.22337E+18 
myisam_mmap_size 1.84467E+19 
myisam_recover_options OFF 
myisam_repair_threads 1 
myisam_sort_buffer_size 8388608 
myisam_stats_method nulls_unequal 
myisam_use_mmap OFF 
net_buffer_length 16384 
net_read_timeout 30 
net_retry_count 10 
net_write_timeout 60 
open_files_limit 1024 
optimizer_prune_level 1 
optimizer_search_depth 62 
optimizer_switch index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on 
preload_buffer_size 32768 
pseudo_thread_id 7256 
query_alloc_block_size 8192 
query_cache_limit 1048576 
query_cache_min_res_unit 4096 
query_cache_size 0 
query_cache_type ON 
query_cache_wlock_invalidate OFF 
query_prealloc_size 8192 
range_alloc_block_size 4096 
read_buffer_size 131072 
read_only OFF 
read_rnd_buffer_size 262144 
skip_external_locking ON 
slow_launch_time 2 
sort_buffer_size 2097144 
sql_auto_is_null ON 
sql_big_selects ON 
sql_big_tables OFF 
sql_buffer_result OFF 
sql_log_bin ON 
sql_log_off OFF 
sql_log_update ON 
sql_low_priority_updates OFF 
sql_max_join_size 1.84467E+19 
sql_quote_show_create ON 
sql_safe_updates OFF 
sql_select_limit 1.84467E+19 
storage_engine MyISAM 
sync_binlog 0 
sync_frm ON 
table_definition_cache 256 
table_lock_wait_timeout 50 
table_open_cache 64 
table_type MyISAM 
thread_cache_size 0 
thread_handling one-thread-per-connection 
thread_stack 262144 
timed_mutexes OFF 
tmp_table_size 16777216 
transaction_alloc_block_size 8192 
transaction_prealloc_size 4096 
unique_checks ON 
updatable_views_with_limit YES 
version 05/01/69 
version_compile_os redhat-linux-gnu 
wait_timeout 28800 
+1

后'的输出EXPLAIN SELECT '。 “我们也检查了指标,并罚款。” - 真的? :) –

回答

1
SELECT b.destination 
    , b.release_cause_protocol_stack 
    , b.binary_value_protocol_stack 
    , b.release_cause 
    FROM billing_datas b 
    JOIN carriermasters customer 
    ON b.carrierid_customer = customer.id 
    JOIN technicalprofiles tpc 
    ON b.technical_profileid_customer = tpc.id 
    JOIN trunks kc 
    ON b.origination_trunkid = kc.trunk 
    JOIN carriermasters supplier 
    ON b.carrierid_supplier = supplier.id 
    JOIN technicalprofiles tps 
    ON b.technical_profileid_supplier = tps.id 
    JOIN trunks ks 
    ON b.supplierid = ks.trunk 
WHERE b.start_time_date BETWEEN '2013-08-02 00:00:00' AND '2013-08-02 23:59:59' 
    AND customer.id IN (99, 100, 101) 
    AND tpc.id IN (83, 274, 84, 416) 
    AND kc.trunk IN (90409, 90310, 30230, 30313) 
    AND supplier.id IN (214, 215, 59, 60, 62, 292, 63, 216, 64, 61, 217, 274, 58) 
    AND tps.id IN (223, 55, 224, 56, 225, 57, 226, 58, 227, 228, 229, 230, 393, 394, 395, 59, 231, 232, 233, 460, 234) 
    AND ks.trunk IN (90106, 30249, 90249, 30250, 90250, 90445, 30409, 90446, 30410, 30294, 90363, 30293, 90293, 30175, 30146, 90146, 90435, 90049, 30177, 90294, 90130, 30130, 90189, 30145, 90145, 90389, 30400, 90429, 90121, 90159) 
ORDER 
    BY b.start_time_date ASC; 
+0

嘿草莓,上面的查询完美的需要大约9分钟,如果我们有一个情景A。如果我们遵循方案B,我们仍然会对查询产生性能问题。我们可以在mysql系统变量中做一些优化,使其更快。 – dell

+0

如需帮助,您需要提供解释 – Strawberry