今天MySQL存储节点突然收到cpu持续100%的报警，持续时间长达数个小时。在控制台中通过show processlist查看当前进程，发现很多一模一样的SQL一直在运行，执行时间都超过数个小时。
针对上面第一种情况，很容易从字面意义就得出是读取超时。然而查询资料 JDBC 存在多种 timeout,仔细研究了一下，梳理一下。
connect timeout和socket timeout都属于TCP层面的超时。
有时候，由于业务的复杂性，在JVM中拼装一些数据，会造成资源的极大浪费。举个例子，从MySQL中查询出一个List，然后在代码里循环查询数据库，进行一些字段的填充。
jdbc提供fetchSize参数来设置每次查询按fetchSize分批获取。不同的数据库的jdbc driver实现不一样。
进入 MySQL 命令行后，长时间连接 MySQL 服务但未进行操作，MySQL服务自动断开，再次执行操作时出现以下提示
理解：这次查询的数据我要用于更新操作，所以麻烦Mysql帮我加锁，其他进程在我更新完成之前不能发起for update请求（可以发起普通select请求， 用于前端展示）
今天下午在线上遇到了一个业务反馈mysqldump频繁失败，大概的错误日志如下：
在传统的单机系统中，调用一个函数，要么返回成功，要么返回失败。这就是两态系统(2-state system)。
最近做了一个多人竞拍的小功能 因为以前没做过 所以踩了很多坑 用的是 mysql + php + redis 实现的竞拍功能
某个复杂查询虽然前端YearningSQL的窗口关闭了，但实际SQL已经下发到数据库层去执行了，这种任然会对MySQL造成过大的压力。
断路器（Circuit Breaker）就像保险丝，在电路系统中，一般在所有的家电系统连接外部供电的线路中间都会加一个保险丝，当外部电压过高，达到保险丝的熔点时，保险丝就会被熔断，从而可以切断家电系统与外部电路的联通，进而保障家电系统不会因为电压过高而损坏。
“锁”是我们实际工作和面试中无法避开的话题之一，正确使用锁可以保证高并发环境下程序的正确执行，也就是说只有使用锁才能保证多人同时访问时程序不会出现问题。
继上篇 2018年swoole实战4-异步io读写 本篇演示 swoole的异步mysql 模拟数据 在本地test数据库中新建book表，写入模拟数据 CREATE TABLE `book` `id` int(11) NOT NULL AUTO_INCREMENT, `content` text,( `titlle` varchar(255) NOT NULL COMMENT '标题', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET
在遭到DDos攻击后，整个服务都垮掉了。由于第四层交换机不堪重负，网络变得无法连接，从而导致业务系统也无法正常运转。安全组很快屏蔽了所有的DDos攻击，并恢复了网络，但业务系统却还是无法工作。 通过分析系统的thread dump发现，业务系统停在了JDBC API的调用上。20分钟后，系统仍处于WAITING状态，无法响应。30分钟后，系统抛出异常，服务恢复正常。
当系统的用户量上来，每秒QPS上千后，可能就会导致系统的各种卡顿，超时等情况，这时优化操作不可避免
数据库锁设计的初衷是处理并发问题。作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。
在并发访问下，MySQL事务中的死锁问题是一种常见的情况。当多个事务同时请求和持有相互依赖的资源时，可能会出现死锁现象，导致事务无法继续执行，严重影响系统的性能和可用性。
最近，IMG 的姜老师发布了一篇关于使用 gh-ost 会丢数据的文章（gh-ost 翻车！使用后导致数据丢失！），大致结论就是：在 MySQL AFTER_SYNC的 场景下，使用 gh-ost 进行表结构变更（包括最新 GA 的1.1.2版本在内），可能会导致数据丢失，还引起大家在微信群内展开了一些讨论。得知这个消息，还是觉得有些意外的，毕竟对于大部分 DBA 来说，gh-ost 属于比较常用的 DDL 工具，会用其替代 pt-osc 或 MySQL 自带的 online ddl 。出于好奇，去 gh-ost 的 Gtihub 主页上看了下，还真有相关的 issue ，并且已经有人提交了 fix 的 PR （目前该 fix 尚未得到官方回应）
上文（MySQL自我保护工具--pt-kill ） 提到用pt-kill工具来kill相关的会话，来达到保护数据库的目的，本文再通过修改数据库参数的方式达到阻断长时间运行的SQL的目的。
世界级的开源分布式数据库 TiDB 自 2016 年 12 月正式发布第一个版本以来，业内诸多公司逐步引入使用，并取得广泛认可。
在建立数据库连接时，你可以设置连接超时。这可以在GORM的初始化过程中完成。以下是一个示例：
从最初的单机部署，到我们现在的分布式，微服务，随着开发场景越来越复杂，也随之产生了很多很多以前没有遇到过的问题，比如今天我们今天的话题-----分布式锁，而这个话题也可以说是面试中必问的一个问题了，当然，实现分布式锁的方式有很多种，比如mysql，zookeeper等，读完这篇文章你将学到：
三、查询超时 查询超时限制，让慢查询及时结束，以免影响整个系统 mysql 5.6 及以后，有语句执行超时时间变量，用于在服务端对 select 语句进行超时时间限制；
最近在mysqldump时，遭遇mysqldump: Error 2013错误。以为是常见的参数设置有问题，调整之后，也没有任何成效。原来发生了OOM，以下是其具体描述。
问题发现 在七月份时，经常发现有几个定时任务报错，查看了下异常原因，大概定位是数据库执行异常 ### Error querying database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Unsupported command ### The error may exist in class path resource [mapper/XXXXXXXXX-Mapper.xml] ### T
这些地方都需要考虑超时的设定，但是PHP中的超时都是分门别类，各个处理方式和策略都不同，为了系统的描述，我总结了PHP中常用的超时处理的总结。
现在的系统都是集群部署，每个服务都不是单节点的了。比如库存服务，可能部署到3台机器上分别命名为节点1，节点2，节点3。库存服务需要扣减库存，扣减库存肯定需要锁吧，如果使用Lock或者synchronized，只能锁住自己的节点。而从前台访问是随机路由到这3台节点的。如果线程一进来使节点1上了锁，当线程二进来可能访问到的是节点2，这时节点2还没有上锁，那么库存就会扣减错误。而库存扣减还是一个核心操作，现在居然有Bug，想想就可怕。
为了让一个复制组正常使用消息分段功能，所有组成员必须运行MySQL 8.0.16或以上版本，并且组使用的组复制通信协议版本必须支持消息分段。可以使用group_replication_get_communication_protocol() UDF检查组使用的通信协议版本是多少，UDF 返回版本号字符串代表了组支持的最老的MySQL Server版本。MySQL 5.7.14的版本支持压缩消息，MySQL 8.0.16的版本支持消息分段。如果所有组成员都运行在MySQL 8.0.16以上版本，并且组中不需要运行更低版本的组成员，则可以使用group_replication_set_communication_protocol UDF()来设置通信协议版本为MySQL 8.0.16及其以上，这样就能够确保消息分段功能在组中所有成员上正常运行。有关更多信息，请参见"4.1.4. 设置组的通信协议版本”。
上周发了《几行烂代码，我赔了16万》 16w 这篇文章之后，有不下十个朋友来找我，问我一些文章中的问题。
资深数据库专家，专研 MySQL 十余年。擅长 MySQL、PostgreSQL、MongoDB 等开源数据库相关的备份恢复、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相关技术支持、MySQL 相关课程培训等工作。
数据库我想大家应该一点都不陌生吧，我想不管你写啥的，数据库就算没用过也听过了，是我们项目体系里面不可或缺的一环。
因为mysql有一个默认的connect_timeout时间，一旦超过，会自动关闭连接。
499 是 nginx 扩展的 4xx 错误，目的只是用于记录，并没有实际的响应。 看一下 nginx 源码 ngx_http_request.h 对 499 的定义：
MySQL 有一个参数叫 max_execution_time ，用来设置只读语句执行的超时时间，但是仅对单独执行的 select 语句有效；对于非单独执行的 select 语句，比如包含在存储过程、触发器等内置事务块里则不生效。官方手册上对这个参数解释如下：
在执行select语句运行了100多秒然后现了lost connection to MySQL server during query错误信息 排查原因：
当数据量比较大，若SQL语句写的不合适，会导致SQL的执行效率低，我们需要等待很长时间才能拿到结果
https://github.com/guyan0319/go-vue-admin
昨天下午，收到一个504的告警，显然这是一个超时告警。当时由于手头有其他事情，没在意，就只是瞄了一眼，但是引起告警的方法很熟悉，是我写的，第一反应有点诧异。
某客户使用TDSQL MySQL8.0版本，在跑批场景下出现连接中断现象。业务反馈的错误信息如下：
Doris 提供多种数据导入方案，可以针对不同的数据源进行选择不同的数据导入方式。Doris支持各种各样的数据导入方式：Insert Into、json格式数据导入、Binlog Load、Broker Load、Routine Load、Spark Load、Stream Load、S3 Load，后面文章分别进行介绍。
最近利用 MHA 做好 Mysql 读写分离后，时不时有用户反馈后台发布文章时，报程序“通用异常"，经问题排查，里面涉及应用JDBC连接池参数及Mysql参数调整问题。
本文实例讲述了PHP Swoole异步MySQL客户端实现方法。分享给大家供大家参考，具体如下：
主要是解决读数据从Redis缓存，一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。
MySQL 5.0 以后针对超长时间数据库连接做了一个处理，即一个数据库连接在无任何操作情况下过了 8 个小时后(MySQL 服务器默认的超时时间是 8 小时)，MySQL 会自动把这个连接关闭。在数据库连接池中的 connections 如果空闲超过 8 小时，MySQL 将其断开，而数据库连接池并不知道该 connection 已经失效，这个时候你请求数据库链接，连接池会将失效的 connection 给你，so~，SpringBoot 温柔的告诉你 No operations allowed after connection closed。SpringBoot 2.0 以上版本，mysql-connector-java 默认使用的是 8.0 以上版本。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
