- 博客(404)
- 资源 (28)
- 收藏
- 关注
RSS订阅
原创 java 设计模式 深入理解
java 设计模式 深入理解在学习设计模式的时候，以前学习了下总以为理解了，但是在实际工作中基本上用不起来。在学习拆书后，想到用讲的方式去学习和思考的时候，要想讲清楚，就要深入理解其中的原理。在重新整理和写下来的过程中，感觉基本上是掌握了，在工作中遇到的时候，也慢慢也去考虑了。教是最好的学。在整理写的时候，也会有不同的思考。创建型抽象工厂模式工厂方法模式建造者模式原型模式-X单态模式-X结构型适配器模式-X桥接模式组合模式外观模式装饰者模式-X享...
2024-03-21 12:48:15
1359
2
原创 mysql Innodb性能参数设置
val < 95% 则考虑减小 innodb_buffer_pool_size， 建议设置为：Innodb_buffer_pool_pages_data * Innodb_page_size * 1.05 / (1024*1024*1024)实际测试发现，该值对插入数据的速度影响非常大，设置为2时插入10000条记录只需要两秒，设置为0时只需要一秒，设置为1时，则需要229秒。当设置为2，该模式速度较快，也比0安全，只有在操作系统崩溃或者系统断电的情况下，上一秒钟所有事务数据才可能丢失。
2025-06-10 10:15:16
233
原创 14 高性能MySQL 附录
Kubernetes是目前技术领域发展最快的基础设施平台之一，这是有原因的。它带来的工程师速度及云原生基金会所支持的丰富生态系统，使其成为对企业有吸引力的投资。但是你应该从团队和公司的风险和回报的角度来考虑是否在Kubernetes上运行MySQL。应确保对有状态服务（如数据存储）在组织的Kubernetes旅程中的位置有共同的理解。要想利用Kubernetes的现有投资来满足所有工作负载是可以理解的，但这需要与数据存储层的稳定性需求进行很好的平衡。
2025-06-10 10:14:43
470
原创 第13章-2 合规控制构建
合规是一个涉及政策和控制的广泛领域，对每种政策和控制的解释也很多。它不仅影响企业运行数据库的方式，还影响法律、财务和IT部门，甚至影响软件变更的部署方式。本章重点介绍了每种常见的合规性法规如何影响你作为数据库工程师的职责。然后，我们讨论了可能受到这些规则影响的不同实践和架构决策，你也需要考虑这些规则。 总的来说，解决与控制措施相关的难题的最佳方法是及早计划。分离应用程序用户，计划凭据轮换策略，并确保密码始终以加密方式而不是以明文形式存储。确保在需要开启数据库访问日志之前，有一个可以信任的日
2025-05-28 09:20:24
1050
原创 第13章-1 什么是合规性
治理（Governance）、风险管理（Risk management）和合规性（Compliance），合称为GRC，它们是一些原则、流程和法律，用于指导企业如何评估和优先考虑其资产的风险，以及如何遵守个人或健康数据处理和传输的法律法规。早期的创业公司通常没有太多合规性需求，重要的是发现适合市场的产品。然而，随着业务的增长，你将开始碰到一些合规性要求。有些合规性要求适用于企业的所有数据，有些则适用于特定的部分数据。 合规性中经常使用的术语是控制。控制是公司内部定义的流程和规则，用于减少意
2025-05-28 09:17:37
1011
原创 第12章-2 虚拟机上的 MySQL
果你公司的数据运行在公有云上，那么当涉及如何运行数据库时，可以有很多选择。作为一名数据库工程师，你将被问及使用哪种托管解决方案，是否使用托管关系数据库解决方案，以及每种选择的利弊。当在讨论中提出自己的观点时，要记住的最重要的一点是，天下没有免费的午餐，每一个选择都伴随着一系列的权衡。你所能做的最有用的事情就是，根据业务如何运行以及处于哪个成熟度阶段的综合背景，为这些权衡制定框架，以帮助指导你的组织做出最合适的选择。我们希望本章能够帮助你进行这些话题讨论，从而能够将可掌控的权衡与公司的需求进行比较
2025-05-28 09:15:10
543
原创 第12章-1 云中的MySQL
对于是否迁移到云端，甚至组织最终采用哪一家云服务商，你很可能都没有太多的控制权。你可以控制的是如何构建数据库环境。有两个方向可以选择：托管MySQL或在VM上构建。托管MySQL往往不需要太多的干涉，但它通常更昂贵，给你的控制权也更少。在VM上构建意味着你在如何构建和观察平台方面获得了更多的灵活性，但这需要更多的时间和操作开销。 在本章中，我们将概述托管MySQL的主要选项，以及它们的作用。还将解释如何开始构建VM选项，包括选择正确的规格和磁盘类型，并且涵盖在云端的VM上运行MySQL时必
2025-05-27 09:00:11
840
原创 第11章-3 ProxySQL
你可以使用ProxySQL作为任何应用程序代码和MySQL实例的中间层。ProxySQL为应用程序与数据库交互提供了一个会话感知的、基于MySQL协议的接口。与应用程序直接打开到数据库实例的连接不同，ProxySQL会代表应用程序来打开数据库连接。这种设计使代理对应用程序节点而言好像是不可见的。它的会话感知允许在MySQL实例之间移动这些连接，而不需要停机。当处理不再维护的应用程序时，这特别有用，因为现在可以利用ProxySQL的特性，而无须对代码进行任何不确定的更改。
2025-05-27 08:56:18
963
原创 第11章-2 使用分片扩展写入
Vitess强烈建议使用半同步复制（相对于默认的异步复制），以确保在向应用程序确认写入操作之前，此写入已被数据库层中的多个节点持久化。这是为了保证持久性而在延迟方面采取的一个重要折中方案，当Vitess需要以一种计划外的方式对写入主机进行故障切换时，这种折中方案会带来好处。
2025-05-26 09:04:21
955
原创 第11章-1 扩展 MySQL
可扩展性是系统支撑不断增长的流量的能力。一个系统扩展能力的好坏可以用成本和简单性来衡量。如果增加系统的扩展能力十分昂贵或复杂，那么在达到天花板时可能需要花费更多的努力来解决相关问题。容量是一个和可扩展性相关的概念。系统容量表示在一定时间内能够完成的工作量 （从物理学来看，单位时间内做的功称为功率（power），而在计算机领域，“power”是一个被用在多处的术语，有多种含义，因此应避免使用它。但是关于容量的精确定义是系统的最大输出功率） ，但容量必须是可以被有效利用的。系统的最大吞吐量并不等同于容量。
2025-05-26 09:01:59
1147
原创 第10章-3 Percona XtraBackup
每个人都知道需要备份，但并不是每个人都能意识到需要的是可恢复的备份。有许多方法可以规划能满足恢复需求的备份。为了避免出现问题，我们建议你要明确并记录恢复点目标和恢复时间目标，并且在选择备份系统时将其作为参考。 在日常基础上做恢复测试以确保备份可以正常工作也很重要。设置mysqldump并让它在每天晚上运行是很简单的，但很多时候你没有意识到数据随着时间已经增长到可能只有几天或几周才能再次导入的地步。最糟糕的是，当你真正需要恢复的时候，才发现原来需要这么长时间。毫不夸张地说，一个在几个小时内完
2025-05-22 09:03:06
1324
原创 第10章-2 备份与恢复工具
备份工具有很多，有的很好用，有的较一般。对于裸文件备份，推荐使用Percona XtraBackup。它是开源的，被广泛使用，而且文档也非常完善。对于逻辑备份，我们首选mydumper。尽管mysqldump随MySQL一起提供，可以开箱即用，但是它的单线程特性会让备份和恢复的时间变得非常长。mydumper具有内置的并行性，可以更快地完成逻辑备份
2025-05-21 10:19:30
976
原创 第10章-1 备份与恢复
如果你没有提前做好备份规划，也许以后会发现已经错失了一些最佳的选择。例如，在服务器已经配置好以后，才想起应该使用LVM，以便获取文件系统的快照——但这时已经太迟了。在为备份配置系统参数时，可能没有注意到某些系统配置对性能有着重要影响。 如果你没有计划做定期的恢复演练，当真的需要恢复时，就会发现并没有那么顺利。在本章中，我们不会涵盖备份和恢复解决方案的所有部分，而是仅涉及与MySQL相关的部分。以下是我们决定不在此处包含的一些要点，但在你的整体备份和恢复策略中仍旧应该考虑涵盖：
2025-05-21 10:14:54
990
原创 第9章-4 主从复制
主从复制的原理 1，数据库有个bin-log二进制文件，记录了所有sql语句。 2，我们的目标就是把主数据库的bin-log文件的sql语句复制过来。 3，让其在从数据的relay-log重做日志文件中再执行一次这些sql语句即可。 4，下面的主从配置就是围绕这个原理配置 5，具体需要三个线程来操作： 1，i/o线程去请求主库 的binlog，并将得到的binlog日志写到relay l
2025-05-20 09:26:52
1172
原创 第9章-3 复制管理和维护
MySQL复制是其内置的一把“瑞士军刀”，极大地增加了MySQL的功能范围和实用性。事实上，这可能是MySQL如此迅速流行的主要原因之一。 尽管复制有许多限制和需要注意的事项，但事实证明，其中大多数相对来说都不重要或容易避免。有些缺点只是高级功能的特殊行为，大多数人不会用到，但对少数需要它们的用户来说非常有用。 在复制方面，你的座右铭应该是“保持简单”。除非确实需要，否则不要做任何花哨的事情，例如，使用环形复制或复制过滤器。应该简单地使用复制来镜像数据的整个副本，包括所有
2025-05-20 09:11:58
599
原创 第9章-2 复制切换
切换的最常见原因是某些维护事件，包括安全补丁、内核更新，有时候甚至只是重新启动一下MySQL，因为有一些配置选项更改后需要重新启动才能生效。这种类型的切换被称为计划内切换。要成功地执行此类切换，需要完成以下步骤： 1. 确定将哪个副本切换为新的源。这通常是一个包含所有数据的副本。这就是要操作的目标。 2. 检查延时，确保延时在秒级别。 3. 通过设置super_read_only停止数据写入源服务器。 [6] 4. 等待副本与目标完
2025-05-19 08:59:54
907
原创 第9章-1 复制
在启用半同步复制后，源在完成每个事务提交时，都需要确保事务至少被一个副本所接收。（所需的完成确认的副本数量是一个可配置的选项（rpl_semi_sync_source_wait_for_replica_count）。在一个更大的集群中，可以考虑在提交事务之前有两个甚至三个副本完成确认）需要确认副本已收到并成功将其写入自己的中继日志（但不一定应用到本地数据）。 由于每个事务都必须等待其他节点的响应，因此该功能会给服务器执行的每个事务都增加额外的延迟。需要根据实际情况考虑是否开启该选项
2025-05-19 08:57:54
977
原创 第8章-10 慢日志查询
MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阀值的语句具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中，ong_query_time的默认值为10，意思是运行10S以上的语句。就会被认作是慢查询。 默认情况下，Mysq数据库并不启动慢查询日志，需要我们手动来设置这个参数，如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。
2025-05-14 10:46:35
782
原创 第8章-8 优化技巧1
平时使用的时候，注意排序和分页的处理，尤其是大数据分页的，最直接的就说限制返回的数量，而不是全部数据。 小表驱动大表这个使用的时候根据实际的数据量去判断，一搬字典表，区域表，这些是小表，业务表是大表。
2025-05-13 09:34:51
764
原创 第8章-6 索引失效的情况
平时在写sql的时候，要注意索引失效的情况。对于like的模糊查询，确实要用，数据量大，这时候，就要考虑多加一些限制条件，缩小查询范围，再模糊查询；如果不行，就要考虑使用其它方案，比如使用ES查询了
2025-05-12 09:29:05
463
原创 第8章-5 sql的执行顺序
整体过程1，先对多表进行关系,根据条件找出符合条件的记录2，在符合条件的基础上进行再次where条件筛选3，对筛选出来的内容进行分组操作4，分组完成后, 使用having再次筛选出满足条件的记录5，取所满足条件的记录6，对取出的记录进行排序7，最终从取出的记录当中获取多少条记录显示出来
2025-05-12 08:59:30
491
原创 第8章-4 查询性能优化2
如果把创建高性能应用程序比作一个环环相扣的“难题”，除了前面介绍的schema、索引和查询语句设计之外，查询优化应该是解开“难题”的最后一步。要想写一个好的查询，你必须理解schema设计、索引设计等，反之亦然。 理解查询是如何被执行的以及时间都消耗在哪些地方，依然是前面我们介绍的响应时间的一部分。如果再加上一些诸如解析和优化过程的知识，就可以更进一步地理解我们在第7章中讨论的MySQL如何访问表和索引的内容了。这也可从另一个维度帮助你理解MySQL在访问表和索引时查询和索引的关系。
2025-05-09 09:28:27
967
原创 第8章-3 查询性能优化1
因为服务器没有存储任何统计信息，所以MySQL查询优化器在生成查询的执行计划时，需要向存储引擎获取相应的统计信息。存储引擎则给优化器提供对应的统计信息，包括：每个表或者索引有多少个页面、每个表的每个索引的基数是多少、数据行和索引的长度是多少、索引的分布信息等。优化器根据这些信息来选择一个最优的执行计划。在后面的小节中我们将看到统计信息是如何影响优化器的，帮助你理解MySQL在访问表和索引时查询和索引的关系。 优化通常需要三管齐下：不做、少做、快速地做
2025-05-08 09:03:17
762
原创 第8章-2 查询执行的基础
MySQL 主要分为 Server 层和引擎层，Server 层主要包括连接器、查询缓存、分析器、优化器、执行器，同时还有一个日志模块（binlog），这个日志模块所有执行引擎都可以共用，redolog 只有 InnoDB 有。 查询语句的执行流程如下：权限校验（如果命中缓存）--->查询缓存（mysql8.0后就废弃了）--->分析器--->优化器--->权限校验--->执行器--->引擎
2025-05-08 08:58:31
579
原创 第8章-1 查询性能优化-优化数据访问
在前面的章节中，我们介绍了如何设计最优的库表结构、如何建立最好的索引，这些对于提高性能来说是必不可少的。但这些还不够——还需要合理地设计查询。如果查询写得很糟糕，即使库表结构再合理、索引再合适，也无法实现高性能。查询优化、索引优化、库表结构优化需要齐头并进，一个不落。在获得编写MySQL查询的经验的同时，你还将学习到如何为高效的查询设计表和索引。同样地，你也可以学习到在优化库表结构时会影响到哪些类型的查询。这个过程需要时间，建议大家在学习后面章节的时候多回头看看这些章节的内容。
2025-05-07 14:54:20
1610
原创 第7章-3 维护索引和表
那么如何判断一个系统创建的索引是合理的呢？一般来说，我们建议按响应时间来对查询进行分析。找出那些消耗最长时间的查询或者那些给服务器带来最大压力的查询，然后检查这些查询的schema、SQL语句和索引结构，判断是否有查询扫描了太多的行，是否做了很多额外的排序或者使用了临时表，是否使用随机I/O访问数据，或者是否有太多回表查询查询那些不在索引中的列的操作。 如果一个查询无法从所有可能的索引中获益，则应该看看是否可以创建一个更合适的索引来提升性能。如果不行，还可以看看是否可以重写该查询，将其
2025-05-07 14:45:24
845
原创 第7章-2 高性能的索引策略
高效地选择和使用索引有很多种方式，其中有些是针对特殊案例的优化方法，有些则是针对特定行为的优化。（MySQL优化器是一个非常神秘且强大的“装置”，不过还好，它的“强大”应该略胜于“神秘”一筹。鉴于它查找最优执行计划的方式，你应该更多依靠EXPLAIN和具体业务负载情况，来决定最优的执行策略） 使用哪个索引，以及如何评估选择不同索引对性能的影响，则需要持续不断地学习。
2025-05-06 09:14:04
997
原创 第7章-1 索引类型
索引，在MySQL中也叫作键（key），是存储引擎用于快速找到记录的一种数据结构。要想获得好的性能，索引至关重要。尤其是当表中的数据量越来越大时，索引对性能的影响愈发重要。在数据量较小且负载较低时，缺少合适的索引对性能的影响可能还不明显，但当数据量逐渐增大时，性能会急剧下降（在本书的第4章介绍过，各种固态硬盘在性能上有一些不一样的特点。索引的原则依然成立，相比传统硬盘，在SSD设备上，糟糕的索引带来的负面影响要稍微小一些）。
2025-05-06 09:00:01
792
原创 第5章-3 安全设置
如果运行的是专用数据库服务器，那么可以设置的最佳选项是innodb_dedicated_server，它可以处理90%的性能配置。如果无法使用此选项，那么最重要的两个选项是：● innodb_buffer_pool_size● innodb_log_file_size
2025-04-23 08:37:22
581
原创 第5章-2 配置MySQL的I/O行为
一些配置选项会影响MySQL将数据同步到磁盘和执行恢复的方式。这会涉及I/O操作，因此会极大地影响性能。这些选项还代表了性能和数据安全之间的权衡。一般来说，确保数据立即且一致地写入磁盘的代价是很高的。如果愿意冒磁盘写入操作没有真正写入持久存储的风险，是可以增加并发性和/或减少I/O等待的，但你必须自己决定可以承受多大风险。
2025-04-23 08:33:18
630
原创 第5章-1 优化服务器设置
本章我们将解释如何为MySQL服务器创建合适的配置文件。这是一个迂回的旅程，有许多兴趣点和可以俯瞰风景的短途旅程。这些短途旅程是必要的。确定合适配置的最短路径并不是从研究配置选项并询问应该设置哪些配置或如何更改它们开始的，也不是从检查服务器行为并询问是否有任何配置选项可以改善它开始的。最好从了解MySQL的内部结构和行为开始。然后，你可以使用这些知识作为如何配置MySQL的指南。最后，你可以将期望的配置与当前配置进行比较，并纠正任何重要和值得修改的差异。
2025-04-22 09:39:33
718
原创 第6章-3 数据库设计
指数是有符号整数，而有符号整数的计算是比无符号整数麻烦。float的指数部分是8位，IEEE规定这个指数的取值范围是 -126到+127，为了消除负数带来的计算上的影响（比如比较大小，加减法等），在实际存储的时候，给指数做一个映射（加上一个偏移量），即float的指数偏移量为127(double的偏移量是1023)。varchar类型是变长的， 仅分配必要的存储空间，但varchar需要使用1或2个额外字节记录字符串的长度。指数如果是6，则实际存储的是6+127=133，即把133转换为二进制之后再存储。
2025-04-22 09:36:17
919
原创 第6章-2 schema管理
请记住以下指导原则： ● 尽量避免在设计中出现极端情况，例如，强制执行非常复杂的查询或者包含很多列的表设计（很多的意思是介于有点多和非常多之间）。 ● 使用小的、简单的、适当的数据类型，并避免使用NULL，除非确实是对真实数据进行建模的正确方法。 ● 尝试使用相同的数据类型来存储相似或相关的值，尤其是在联接条件中使用这些值时。 ● 注意可变长度字符串，它可能会导致临时表和排序的全长内存分配不乐观。 ● 如果可能的话，尝
2025-04-21 08:57:21
556
原创 第6章-1 数据类型
良好的逻辑设计和物理设计是高性能的基石，应该根据系统将要运行的特定查询设计schema。这通常需要权衡各种因素。例如，反范式的schema可以加速某些类型的查询，但同时可能减慢其他类型的查询。添加计数器和汇总表是一个优化查询的好方法，但它们的维护成本可能很高。MySQL的某些独有的特性和实现细节对性能的影响也很大。
2025-04-21 08:54:28
1087
原创 Caused by: feign.RetryableException: Connect to user-service:80 [user-service/192.168.129.12] failed
如果遇到feign请求失败的情况（之前都是正常的），检查下服务上配置的host的地址。如果不是默认的nacos，比如用的是nacos.k8s命名空间，那可能导致服务注册有问题，服务之间无法直接调用。因为nacos要开启鉴权，调整了项目里面gradle、springCloud，springBoot和nacos客户端引用的版本（也不能升得太高，不然无法启动）。检查了下，并没有80端口，用户中心的服务设置的端口是：8793。至于为啥这样的写法会连接不上，没理解过来。如果服务有开放端口的，就改成具体的ip地址。
2025-04-16 15:53:32
601
原创 第4章-5 linux 网络管理
三次握手，其实就是主动打开方，发送 SYN，表示要建立连接，然后被动打开方对此进行确认，然后主动方收到确认之后，对确认进行确认；
2025-04-16 08:53:56
720
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人