glon commented on issue #10063: URL: https://github.com/apache/shardingsphere/issues/10063#issuecomment-819268082
@strongduanmu Our backend MySQL DB timeout setting： ```mysql >show global variables like '%timeout%'; +------------------------------+----------+ | Variable_name | Value | +------------------------------+----------+ | connect_timeout | 10 | | delayed_insert_timeout | 300 | | have_statement_timeout | YES | | innodb_flush_log_at_timeout | 1 | | innodb_lock_wait_timeout | 50 | | innodb_rollback_on_timeout | OFF | | interactive_timeout | 120 | | lock_wait_timeout | 31536000 | | net_read_timeout | 120 | | net_write_timeout | 120 | | rpl_semi_sync_master_timeout | 10000 | | rpl_stop_slave_timeout | 31536000 | | slave_net_timeout | 60 | | wait_timeout | 120 | +------------------------------+----------+ 14 rows in set (0.01 sec) ``` And I don't think it should be the reason. Executing SQLs behind won't take a long time : ```mysql root@localhost:6033 [(none)]>use sharding_db Database changed sharding_user@localhost:6033 [sharding_db]>select * from city; Query OK, 0 rows affected, 25971 warnings (0.01 sec) sharding_user@localhost:6033 [(none)]> ``` I can execute SQL `select * from not_broadcast_table` ，this problem only appears in broadcast tables, sharding tables do not have this problem. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
