SQL的生命周期？

用心去追梦

于 2024-01-17 17:41:00 发布

阅读量338

点赞数 9

文章标签：数据库

本文链接：https://blog.csdn.net/qq_33240556/article/details/135656575

版权

本文详细描述了应用服务器如何通过连接数据库服务器，解析SQL获取执行计划，读取数据到内存进行处理，最终将结果发送给客户端并关闭连接释放资源的过程。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

                    
                    应用服务器与数据库服务器建立一个连接
数据库进程拿到请求sql
解析并生成执行计划，执行
读取数据到内存并进行逻辑处理
通过步骤一的连接，发送结果到客户端
关掉连接，释放资源

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

用心去追梦

关注关注

9
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

参与评论您还未登录，请先登录后发表或查看评论

博客

Kafka Consumer源码分析：消息消费的实现过程

04-30

553

我们在上节课中提到过，用于解决消息队列一些常见问题的知识和原理，最终落地到代码上，都包含在收、发消息这两个流程中。对于消息队列的生产和消费这两个核心流程，在大部分消息队列中，它实现的主要流程都是一样的，所以，通过这两节课的学习之后，掌握了这两个流程的实现过程。无论你使用的是哪种消息队列，遇到收发消息的问题，你都可以用同样的思路去分析和解决问题。

博客

RocketMQ Producer源码分析：消息生产的实现过程

04-30

569

对于消息队列来说，它最核心的功能就是收发消息。也就是消息生产和消费这两个流程。我们在之前的课程中提到了消息队列一些常见问题，比如，“如何保证消息不会丢失？”“为什么会收到重复消息？”“消费时为什么要先执行消费业务逻辑再确认消费？”，针对这些问题，我讲过它们的实现原理，这些最终落地到代码上，都包含在这一收一发两个流程中。在接下来的两节课中，我会带你一起通过分析源码的方式，详细学习一下这两个流程到底是如何实现的。

博客

数据压缩：时间换空间的游戏

04-30

566

这节课我们一起来聊一聊数据压缩。我在前面文章中提到过，我曾经在一台配置比较高的服务器上，对Kafka做过一个极限的性能压测，想验证一下Kafka到底有多快。我使用的种子消息大小为1KB，只要是并发数量足够多，不开启压缩时，可以打满万兆网卡的全部带宽，TPS接近100万。开启压缩时，TPS可以达到2000万左右，吞吐量提升了大约20倍！

博客

如何用硬件同步原语（CAS）替代锁？

04-30

570

为什么硬件同步原语可以替代锁呢？要理解这个问题，你要首先知道硬件同步原语是什么。硬件同步原语（Atomic Hardware Primitives）是由计算机硬件提供的一组原子操作，我们比较常用的原语主要是CAS和FAA这两种。CAS（Compare and Swap），它的字面意思是：先比较，再交换。*p ← newp: 要修改的变量的指针。old: 旧值。new: 新值。返回的是一个布尔值，标识是否赋值成功。

博客

如何正确使用锁保护共享数据，协调异步线程？

04-30

630

在前几天的加餐文章中我讲到，JMQ为了提升整个流程的处理性能，使用了一个“近乎无锁”的设计，这里面其实隐含着两个信息点。第一个是，在消息队列中，“锁”是一个必须要使用的技术。第二个是，使用锁其实会降低系统的性能。那么，如何正确使用锁，又需要注意哪些事项呢？今天我们就来聊一聊这个问题。我们知道，使用异步和并发的设计可以大幅提升程序的性能，但我们为此付出的代价是，程序比原来更加复杂了，多线程在并行执行的时候，带来了很多不确定性。

博客

Kafka如何实现高性能IO？

04-30

499

Apache Kafka是一个高性能的消息队列，在众多消息队列产品中，Kafka的性能绝对是处于第一梯队的。我曾经在一台配置比较好的服务器上，对Kafka做过极限的性能压测，Kafka单个节点的极限处理能力接近每秒钟2000万条消息，吞吐量达到每秒钟600MB。你可能会问，Kafka是如何做到这么高的性能的？我们在专栏“进阶篇”的前几节课，讲的知识点一直围绕着同一个主题：怎么开发一个高性能的网络应用程序。

博客

内存管理：如何避免内存溢出和频繁的垃圾回收？

04-30

356

今天，我们来聊一聊内存管理的问题。不知道你有没有发现，在高并发、高吞吐量的极限情况下，简单的事情就会变得没有那么简单了。一个业务逻辑非常简单的微服务，日常情况下都能稳定运行，为什么一到大促就卡死甚至进程挂掉？再比如，一个做数据汇总的应用，按照小时、天这样的粒度进行数据汇总都没问题，到年底需要汇总全年数据的时候，没等数据汇总出来，程序就死掉了。之所以出现这些情况，大部分的原因是，程序在设计的时候，没有针对高并发高吞吐量的情况做好内存管理。要想解决这类问题，首先你要了解内存管理机制。

博客

传输协议：应用程序之间对话的语言

04-30

795

经过前面几课的学习，我们已经可以实现高性能的结构化数据传输了。不过，应用程序之间要想互相通信，一起配合来实现业务功能，还需要有一套传输协议来支持。**传输协议就是应用程序之间对话的语言。**设计传输协议，并没有太多规范和要求，只要是通信双方的应用程序都能正确处理这个协议，并且没有歧义就好了。这节课，我们就来说一下设计高性能传输协议的一些方法和技巧。

博客

序列化与反序列化：如何通过网络传输结构化的数据？

04-30

389

最近有一些同学留言说，感觉这几节课讲的内容和消息关系不大。这里我解释一下，因为我们课程其中的一个目的，是让同学们不仅会使用消息队列，还可以通过对消息队列的学习，在代码能力上有一个提升，具备“造轮子”的能力。这样，你对消息队列的理解才能足够的深入，而不只是浮于表面。如果你细心可能也会发现，很多大厂在面试时，提到消息队列的问题，也不会仅仅局限在消息队列的使用上，他更多的会考察“你为什么这么实现”。

博客

如何实现高性能的异步网络传输？

04-30

253

你好，我是李玥。上一节课我们学习了异步的线程模型，异步与同步模型最大的区别是，同步模型会阻塞线程等待资源，而异步模型不会阻塞线程，它是等资源准备好后，再通知业务代码来完成后续的资源处理逻辑。这种异步设计的方法，可以很好地解决IO等待的问题。我们开发的绝大多数业务系统，都是IO密集型系统。跟IO密集型系统相对的另一种系统叫计算密集型系统。通过这两种系统的名字，估计你也能大概猜出来IO密集型系统是什么意思。

博客

如何使用异步设计提升系统性能？

04-29

776

这一讲我们来聊一聊异步。对于开发者来说，异步是一种程序设计的思想，使用异步模式设计的程序可以显著减少线程等待，从而在高吞吐量的场景中，极大提升系统的整体性能，显著降低时延。因此，像消息队列这种需要超高吞吐量和超低时延的中间件系统，在其核心流程中，一定会大量采用异步的设计思想。接下来，我们一起来通过一个非常简单的例子学习一下，使用异步设计是如何提升系统性能的。

博客

学习开源代码该如何入手？.

04-29

770

对于很多开源软件来说，如果我们把它作为我们业务系统的重要组成部分之一，真正地用于生产，仅仅知道如何使用是远远不够的，你必须掌握它的实现原理和很多细节，这样才能找到最佳的使用姿势，当你的系统出现问题时，你才有可能基于它的实现原理，再根据一些现象来排查问题原因。掌握这些开源软件的最佳方式就是去学习它的源代码。很多同学跟我说：“我也很想去看一些开源软件的代码，也尝试去看过，但是面对上千个源码文件，几十万行代码，完全不知道从哪儿入手啊。这节课我们就针对这个情况来聊一聊，学习开源软件的代码该如何入手。

博客

网关如何接收服务端的秒杀结果？

04-29

893

在留言中，很多同学留言提出来，能不能讲一讲某个消息队列的某个功能具体如何配置。我的建议是，你先不要太关注功能、API和配置这些细节，在学习如何使用消息队列的过程中，要保持一定的高度来学习。因为使用消息队列，大部分的难点在宏观架构层面，要解决这些难点，你需要掌握消息队列宏观层面上的实现原理和最佳实践，这样，无论你使用什么消息队列，都可以做到游刃有余。在选定了合适的消息队列产品，准备写代码之前，再去文档中查看这些细节都来得及。所以，我们专栏的“基础篇”讲消息队列的使用，更多讲的是一些通用的原理。

博客

消息积压了该如何处理？

04-29

841

这节课我们来聊一聊关于消息积压的问题。据我了解，在使用消息队列遇到的问题中，消息积压这个问题，应该是最常遇到的问题了，并且，这个问题还不太好解决。我们都知道，消息积压的直接原因，一定是系统中的某个部分出现了性能问题，来不及处理上游发送的消息，才会导致消息积压。所以，我们先来分析下，在使用消息队列时，如何来优化代码的性能，避免出现消息积压。然后再来看看，如果你的线上系统出现了消息积压，该如何进行紧急处理，最大程度地避免消息积压对业务的影响。

博客

如何处理消费过程中的重复消息？

04-29

905

上节课我们讲了如何确保消息不会丢失，课后我给你留了一个思考题，如果消息重复了怎么办？这节课，我们就来聊一聊如何处理重复消息的问题。在消息传递过程中，如果出现传递失败的情况，发送方会执行重试，重试的过程中就有可能会产生重复的消息。对使用消息队列的业务系统来说，如果没有对重复消息进行处理，就有可能会导致系统的数据出现错误。比如说，一个消费订单消息，统计下单金额的微服务，如果没有正确处理重复消息，那就会出现重复统计，导致统计结果错误。你可能会问，如果消息队列本身能保证消息不重复，那应用程序的实现不就简单了。

博客

如何确保消息不会丢失？

04-29

609

这节课我们来聊聊丢消息的事儿。对于刚刚接触消息队列的同学，最常遇到的问题，也是最头痛的问题就是丢消息了。对于大部分业务系统来说，丢消息意味着数据丢失，是完全无法接受的。其实，现在主流的消息队列产品都提供了非常完善的消息可靠性保证机制，完全可以做到在消息传递过程中，即使发生网络中断或者硬件故障，也能确保消息的可靠传递，不丢消息。绝大部分丢消息的原因都是由于开发者不熟悉消息队列，没有正确使用和配置消息队列导致的。

博客

如何利用事务消息实现分布式事务？

04-29

638

那什么是事务呢？如果我们需要对若干数据进行更新操作，为了保证这些数据的完整性和一致性，我们希望这些更新操作**要么都成功，要么都失败。**至于更新的数据，不只局限于数据库中的数据，可以是磁盘上的一个文件，也可以是远端的一个服务，或者以其他形式存储的数据。这就是通常我们理解的事务。其实这段对事务的描述不是太准确也不完整，但是，它更易于理解，大体上也是正确的。所以我还是倾向于这样来讲“事务”这个比较抽象的概念。一个严格意义的事务实现，应该具有4个属性：原子性、一致性、隔离性、持久性。

博客

该如何选择消息队列？

04-29

526

在了解了上面这些开源消息队列各自的特点和优劣势后，我相信你对于消息队列的选择已经可以做到心中有数了。我也总结了几条选择的建议供你参考。如果说，消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，我建议你使用RabbitMQ。如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那RocketMQ的低延迟和金融级的稳定性是你需要的。

博客

为什么需要消息队列？

04-29

980

今天我们来讲讲为什么需要消息队列，消息队列主要解决的是什么问题。消息队列是最古老的中间件之一，从系统之间有通信需求开始，就自然产生了消息队列。但是给消息队列下一个准确的定义却不太容易。我们知道，消息队列的主要功能就是收发消息，但是它的作用不仅仅只是解决应用之间的通信问题这么简单。我们举个例子说明一下消息队列的作用。话说小袁是一家巧克力作坊的老板，生产出美味的巧克力需要三道工序：首先将可可豆磨成可可粉，然后将可可粉加热并加入糖变成巧克力浆，最后将巧克力浆灌入模具，撒上坚果碎，冷却后就是成品巧克力了。

博客

如何成为优秀的性能和容量工程师？

04-28

921

中国的互联网事业一直在高速前进。性能和容量工程相关的工作，也是这一事业相当重要的一部分，我们的工作会让公司的业务效率和性能不断地提升，也就是对社会做出了贡献。这种工作需要软硬两方面的知识、技能和经验。若想在这一领域做得出色，你尤其要加强对英文、协调能力和情商方面的训练。古人云：天助自助者，天道酬勤。哪怕你天资有限，机遇不足，现在还做不了“第一名”，但是只要每天进步，不断超越自我，那么你其实就是“成功者”。古人说：“泰山不让土壤，故能成其大；河海不择细流，故能就其深。