云服务器内容精选

  • TaurusDB timeout相关参数简介 MySQL中有多种timeout参数,TaurusDB也将相关参数提供给用户设置,如下表: 表1 参数说明 参数名称 修改是否需要重启 参数含义 connect_timeout 否 控制客户端和MySQL服务端在建连接时,服务端等待三次握手成功的超时时间(秒),网络状态较差时,可以调大该参数。 innodb_flush_log_at_timeout 否 每N秒写入并刷新日志。当innodb_flush_log_at_trx_commit值为2时,此设置有效。 innodb_lock_wait_timeout 否 该变量控制innodb事务获取行锁等待的最长时间(秒),如果超过该时间还未获取到锁资源,则会返回执行失败。 parallel_queue_timeout 否 请求并行执行的查询的等待时间。如果超过该等待时间后,系统中并行执行的线程数仍然大于parallel_max_threads,则不再等待而进入单线程执行。 lock_wait_timeout 否 试图获得元数据锁的超时时间(秒)。 net_read_timeout 否 中止读数据之前从一个连接等待更多数据的秒数。 net_write_timeout 否 中止写之前等待一个块被写入连接的秒数。 interactive_timeout 否 服务器在关闭交互式连接之前等待活动的秒数。 wait_timeout 否 服务器关闭连接之前等待非交互式连接活动的秒数。 父主题: 参数类
  • 场景描述 用户将RDS for MySQL的“lower_case_table_names”设置成“大小写敏感”的状态时,创建了带有大写字母的表,如“tbl_newsTalking”,但后期改变了大小写敏感的设置状态后,无法找到该表。 案例:在执行备份恢复到新实例的时候,如果新实例的“大小写敏感”参数值与备份时原实例的参数值不一致,会导致恢复失败。 更多敏感参数,请参见《云数据库RDS用户指南》中“RDS for MySQL参数调优建议”的内容。 对于MySQL 5.6、5.7版本,支持在管理控制台或API创建数据库实例时指定表名大小写敏感,以及实例创建完成后设置表名大小写敏感(lower_case_table_names)。 对于MySQL 8.0版本,仅支持在管理控制台或API创建数据库实例时指定表名大小写敏感,创建完成的MySQL 8.0实例不支持设置表名大小写敏感(lower_case_table_names)。
  • 示例 举例中使用的是命令的方式做描述。 创建会话1。 # 查看参数值。 show variables like 'long_query_time'; +-----------------+-----------+ | Variable_name | Value | +-----------------+-----------+ | long_query_time | 10.000000 | +-----------------+-----------+ 1 row in set (0.08 sec) # 修改变量值 set global long_query_time=1; Query OK, 0 rows affected (0.02 sec) # 重新查看,发现未生效。 show variables like 'long_query_time'; +-----------------+-----------+ | Variable_name | Value | +-----------------+-----------+ | long_query_time | 10.000000 | +-----------------+-----------+ 1 row in set (0.01 sec) 创建会话2。 show variables like 'long_query_time'; +-----------------+-----------+ | Variable_name | Value | +-----------------+-----------+ | long_query_time | 10.000000 | +-----------------+-----------+ 1 row in set (0.01 sec) 在会话1中执行。 #会话1中执行set global后,再次查看,变量未生效。 show variables like 'long_query_time'; +-----------------+-----------+ | Variable_name | Value | +-----------------+-----------+ | long_query_time | 10.000000 | +-----------------+-----------+ 1 row in set (0.01 sec) # 会话1断开,重新连接,发现修改生效。 show variables like 'long_query_time'; +-----------------+----------+ | Variable_name | Value | +-----------------+----------+ | long_query_time | 1.000000 | +-----------------+----------+ 1 row in set (0.00 sec) 会话2断开,重新连接,发现修改生效。 show variables like 'long_query_time'; +-----------------+----------+ | Variable_name | Value | +-----------------+----------+ | long_query_time | 1.000000 | +-----------------+----------+ 1 row in set (0.01 sec)
  • 原因分析 控制台上修改“long_query_time”参数是全局级别生效,修改完后,后续新建连接会使用最新设置的参数,但是旧连接的“long_query_time”属性值不会被改变,仍然保持旧的值(该案例中是0.1s),所以小于0.2s的慢SQL是在旧连接上产生的。 出现该现象的原因是MySQL机制导致,所以不仅“long_query_time”参数会出现此类问题,其他控制台上可以修改的全局参数,也会发生类似现象:只有新建连接生效,旧连接不生效。