2016-09-30 61 views
6

我们最近将percona 5.5 sql server升级到了percona 5.7。到目前为止工作良好。不幸的是,我们有一个巨大的查询,在5.7以下速度极慢。在5.5之下。即使使用sql_no_cache,也只需不到一秒钟的时间。随着Percona 5.7。执行此查询最多需要1分钟。奇怪的是,随着我们使用更多的组合索引,它变得越慢。删除所有组合的指示导致执行时间为30秒。强制sql_straight_join使查询在不到一秒的时间内运行。Percona 5.7在很多联接上缓慢

所以这里是查询:

SELECT t0_.tree_id AS tree_id0, t1_.treetype_name AS treetype_name1, c2_.contentelement_id AS contentelement_id2, t0_.tree_name AS tree_name3, (CASE WHEN t3_.treetype_name <> 'global' THEN t4_.tree_name ELSE t0_.tree_name END) AS sclr4, p5_.picture_id AS picture_id5, t6_.tree_misc_value_text AS tree_misc_value_text6, (CASE WHEN t3_.treetype_name <> 'global' THEN t7_.tree_misc_value_text ELSE t6_.tree_misc_value_text END) AS sclr7, w8_.widgetgeneral_slug AS widgetgeneral_slug8, (CASE WHEN t3_.treetype_name <> 'global' THEN w9_.widgetgeneral_slug ELSE w8_.widgetgeneral_slug END) AS sclr9, t10_.tree_misc_value_text AS tree_misc_value_text10, t11_.tree_misc_value_text AS tree_misc_value_text11 
FROM tree_relation t12_ 
INNER JOIN tree t4_ ON t12_.tree_relation_parent = t4_.tree_id 
INNER JOIN treetype t3_ ON t4_.tree_type_id = t3_.treetype_id AND (t3_.treetype_name IN ('global', 'country')) 
INNER JOIN contentelement c13_ ON t4_.tree_id = c13_.contentelement_tree_id 
INNER JOIN contentleaf c14_ ON c13_.contentelement_contentleaf_id = c14_.contentleaf_id AND (c14_.contentleaf_contentbranch_id = 1) 
INNER JOIN widgetgeneral w9_ 
INNER JOIN widgetabstract w15_ ON w9_.widgetabstract_id = w15_.widgetabstract_id AND (w15_.widgetabstract_contentelement_id = c13_.contentelement_id AND w15_.widgetabstract_discriminator IN ('general') AND w15_.widgetabstract_state = 'preview') 
INNER JOIN tree t0_ ON t12_.tree_relation_child = t0_.tree_id 
INNER JOIN treetype t1_ ON t0_.tree_type_id = t1_.treetype_id AND (t1_.treetype_name IN ('city','region')) 
INNER JOIN contentelement c2_ ON t0_.tree_id = c2_.contentelement_tree_id 
INNER JOIN contentleaf c16_ ON c2_.contentelement_contentleaf_id = c16_.contentleaf_id AND (c16_.contentleaf_contentbranch_id = 1) 
INNER JOIN widgetgeneral w8_ 
INNER JOIN widgetabstract w17_ ON w8_.widgetabstract_id = w17_.widgetabstract_id AND (w17_.widgetabstract_contentelement_id = c2_.contentelement_id AND w17_.widgetabstract_discriminator IN ('general') AND w17_.widgetabstract_state = 'preview') 
INNER JOIN widgetgeneral w18_ 
INNER JOIN widgetabstract w19_ ON w18_.widgetabstract_id = w19_.widgetabstract_id AND (w19_.widgetabstract_contentleaf_id = c16_.contentleaf_id AND w19_.widgetabstract_discriminator IN ('general') AND w19_.widgetabstract_state = 'preview') 
LEFT JOIN picture p5_ ON t0_.tree_picture_id = p5_.picture_id 
LEFT JOIN tree_misc t6_ ON t0_.tree_id = t6_.tree_misc_tree_id AND (t6_.tree_misc_attributetype_key = 'flagId') 
LEFT JOIN tree_misc t7_ ON t4_.tree_id = t7_.tree_misc_tree_id AND (t7_.tree_misc_attributetype_key = 'flagId') 
LEFT JOIN tree_misc t10_ ON t0_.tree_id = t10_.tree_misc_tree_id AND (t10_.tree_misc_attributetype_key = 'latitude') 
LEFT JOIN tree_misc t11_ ON t0_.tree_id = t11_.tree_misc_tree_id AND (t11_.tree_misc_attributetype_key = 'longitude') 
WHERE w17_.widgetabstract_visibility = 'active' OR (w17_.widgetabstract_visibility = 'parent' AND w19_.widgetabstract_visibility = 'active') 

和解释:5.7 enter image description here

我们试图升级以及完整的空白安装。打开和关闭所有sql模式并查询优化器选项。如果你需要更多的信息或服务器变量让我知道。

OS:的Debian GNU/Linux的8(杰西) 服务器版本为:5.7.14-7-LOG的Percona服务器(GPL),推出 '7',修订 '083e298'

也许你有一个提示我们缺少什么。

编辑: 增加配置

[mysqld] 
port       = 3306 
user       = mysql 
socket       = /var/run/mysqld/mysqld.sock 
pid-file      = /var/run/mysqld/mysqld.pid 
basedir       = /usr 
datadir       = /var/lib/mysql 
tmpdir       = /tmp 
lc-messages-dir     = /usr/share/mysql 
max_connect_errors    = 1000000 
log-error      = /var/log/mysql/error.log 
skip-external-locking 
myisam-recover-options   = BACKUP 
character-set-server   = utf8 
collation-server    = utf8_general_ci 
interactive_timeout    = 28800 
wait_timeout     = 28800 
skip-name-resolve 
group_concat_max_len   = 268435456 

innodb_file_per_table 
innodb_buffer_pool_size    = 48G 
innodb_buffer_pool_instances   = 1 
innodb_flush_log_at_trx_commit  = 1 
innodb_data_file_path     = ibdata1:2G:autoextend 
innodb_log_file_size     = 256M 
innodb_log_buffer_size    = 64M 
innodb_file_format     = barracuda 
innodb_flush_method     = O_DIRECT[mysqld_safe] 
syslog 
numa_interleave 

# Per Thread 
sort_buffer_size  = 4M 
read_buffer_size  = 2M 

# Cache/connection relevant 
thread_cache_size  = 850 
table_open_cache  = 4048 
max_connections   = 1300 

# MyISAM settings (also valid for queries with temporary tables) 
key_buffer_size   = 128M 
myisam_sort_buffer_size = 16M 

# Misc 
max_allowed_packet  = 256M 
max_heap_table_size  = 16M 
thread_stack   = 192K 
tmp_table_size   = 16M 

# Query cache 
query_cache_limit  = 5M 
query_cache_size  = 4024M 

server-id    = 102 
log_bin    = /var/log/mysql/mysql-bin.log 
binlog_format   = mixed 
expire_logs_days  = 10 
max_binlog_size  = 100M 
# enforce syncing of every transation to binlog (crash safe, with bbu this should be fast) 
sync_binlog   = 1 
sync_relay_log   = 1 
sync_master_info  = 1 
sync_relay_log_info = 1 
relay-log    = mysqld-relay-bin 
skip-slave-start 
log-slave-updates 

slow_query_log     = 1 
slow_query_log_file   = /var/log/mysql/mysql-slow.log 
long_query_time    = 1 
log-queries-not-using-indexes 

编辑2: 加解释5.5 enter image description here

+0

MySQL配置文件会很好,特别是'innodb_buffer_pool_size'的值。添加索引不会使查询工作更快,就像那样.. – Mjh

+0

add config @Mjh - innodb_buffer_pool_size站在48G,但也尝试了一个完整的空白配置 – tom

+0

你有5.5'EXPLAIN'吗?这可能会更容易看出哪些优化出了问题。 –

回答

1

新的连接顺序很可能是由于到MySQL 5.7高估过滤可以做出效果基于WHERE和ON子句。在MySQL 5.6中,没有考虑过滤,这往往导致不必要的昂贵的连接顺序被选择。一般来说,MySQL 5.7通常可以通过考虑过滤来找到更好的连接顺序。但是,对于未索引列上的条件,过滤估计值只是一种猜测,对于不太有选择性的条件可能效果不佳。

通过设置optimizer_switch ='condition_fanout_filter = off',您可以恢复到5.6行为,或者您可以使用STRAIGHT_JOIN强制执行特定的连接排序。

+0

感谢您的支持。 我们已经尝试过“condition_fanout_filter = off”,但它对查询运行时没有显着影响。 – tom

+0

嗯。然后我想我需要查看优化器跟踪来了解发生了什么。 – oysteing