关于数据库:在一条DML语句中插入更新删除获取几百万行数据你会特别注意什么

3次阅读

共计 2170 个字符，预计需要花费 6 分钟才能阅读完成。

前言

所以超时管制是所有分布式系统须要去解决好的问题，而解决不好就会导致系统运行停滞，无奈失常工作。

昆仑分布式数据库的超时管制机制简介

昆仑分布式数据库有以下超时控制变量：

一部分在计算节点中，计算节点的超时变量都在计算节点实例的配置文件中，能够按需批改，并且批改后刷新运行实例的参数。
一部分在存储节点中，存储节点的超时变量在存储节点配置文件中，能够批改配置文件，也能够通过在计算节点或者存储节点执行 set 语句批改对应变量值。

通常状况下用户并不需要批改这些变量，因为咱们曾经针对惯例状况最优化了计算节点和存储节点的配置参数。

不过在非凡场景下还是须要批改这些超时变量的。

典型场景就是须要在一个 DML 语句中插入 / 更新 / 删除数百万行甚至更多的数据，或者一个 select 语句中要返回数百万行甚至更多的数据。

例如，逻辑导入超大的数据表或者全量数据，对超大的表做全表更新，数据分析（OLAP）查问须要扫描一个超大的表，以及程序员或者 DBA 打算删库跑路😂等等。

这些场景下用户最好依据预估插入 / 更新 / 删除 / 读取的数据量，提前增大下述各个超时值，以确保相干语句和操作能够失常工作直至实现，不会被超时机制误认为是曾经超时无奈正确执行的语句而提前终止掉。

或者用户能够在尝试这些操作并失去谬误之后，再增大这些超时值。

上面就让咱们看一下昆仑分布式数据库的所有超时控制变量。

计算节点的超时变量性能

如果计算节点执行查问的总工夫超过这个限度，语句就会被回滚。

比方，如果计算节点应用存储集群返回的局部数据执行表连贯时耗过长，那么最终会在达到这个超时限度后进行（默认 100 秒）。

读取超过 mysql_read_timeout 或者写入超过 mysql_write_timeout 那么计算节点应用的 mysql 客户端库就会报错并且从读取 / 写入期待中返回，这样语句执行就提前终止了。

如果一条发送给计算节点的一条 insert 语句会插入 100 万行数据，或者一条 select 语句会从存储节点返回上百万行数据，那么最好减少这两个变量的值，它们默认是 50 秒。

另外，这种状况下还要增大 mysql_max_packet_size 变量，确保这样的超大数据包能够正确发送给存储节点。

并发执行的增删改查语句对表的所是相容的，不须要期待锁。

然而如果某个 alter table 语句正在执行，那么同一个计算节点上其余连贯中无奈执行针对这个表的 DML 语句，它们最多等这么久，还拿不到锁就会报错返回（默认 100 秒）。

如果要在每条 insert 语句中插入数万行甚至更多，那么肯定要把这个变量增大，否则会在日志文件中记录大量数据，导致计算节点磁盘空间用尽（默认 10 秒）。

存储节点的超时变量性能

期待 server 层的表锁的最大工夫。如果一个 DDL 语句在 alter table, 那么所有对该表做 DML 语句的事务会阻塞期待最多这么多表，还得不到表锁就会返回谬误。

在 MySQL8.0 时代，加列和加索引这种最常见的已经要锁住全表能力实现的操作曾经不须要全表长期锁定了，曾经变成了 online ddl，因而默认 5 秒一般来说足够了。

超过了那么 DML 语句就会报错返回。

如果要做全表更新，并且表的数据量十分大，比方几百 GB 甚至更多，那么 update 语句会锁住大量的行很长时间，此时其余事务通常会产生锁超时，除非增大了其 innodb_lock_wait_timeout（默认 20 秒）。

如果存储集群应用了 MySQL Group Replication 做高可用，那么须要增大
MGR 的 group_replication_member_expel_timeout，group_replication_component_stop_timeout, group_replication_unreachable_majority_timeout 超时控制变量，否则 MGR 的备机会误以为主节点宕机了从而发动主备切换，或者主节点认为备机失去分割了从而无奈写入。

结语

昆仑分布式数据库具备欠缺的超时管制机制，在任何节点间通信机制中都有超时管制，确保任何操作都有最大时耗下限，确保零碎状态能够继续推动，系统资源继续可服务更多的服务申请。

*KunlunDB 我的项目已开源

【GitHub：】
https://github.com/zettadb

【Gitee：】
https://gitee.com/zettadb

END

正文完