- 博客(392)
- 资源 (28)
- 收藏
- 关注
RSS订阅
原创 java 设计模式 深入理解
java 设计模式 深入理解在学习设计模式的时候，以前学习了下总以为理解了，但是在实际工作中基本上用不起来。在学习拆书后，想到用讲的方式去学习和思考的时候，要想讲清楚，就要深入理解其中的原理。在重新整理和写下来的过程中，感觉基本上是掌握了，在工作中遇到的时候，也慢慢也去考虑了。教是最好的学。在整理写的时候，也会有不同的思考。创建型抽象工厂模式工厂方法模式建造者模式原型模式-X单态模式-X结构型适配器模式-X桥接模式组合模式外观模式装饰者模式-X享...
2024-03-21 12:48:15
1355
2
原创 第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
537
原创 第9章-3 复制管理和维护
MySQL复制是其内置的一把“瑞士军刀”，极大地增加了MySQL的功能范围和实用性。事实上，这可能是MySQL如此迅速流行的主要原因之一。 尽管复制有许多限制和需要注意的事项，但事实证明，其中大多数相对来说都不重要或容易避免。有些缺点只是高级功能的特殊行为，大多数人不会用到，但对少数需要它们的用户来说非常有用。 在复制方面，你的座右铭应该是“保持简单”。除非确实需要，否则不要做任何花哨的事情，例如，使用环形复制或复制过滤器。应该简单地使用复制来镜像数据的整个副本，包括所有
2025-05-20 09:11:58
235
原创 第9章-2 复制切换
切换的最常见原因是某些维护事件，包括安全补丁、内核更新，有时候甚至只是重新启动一下MySQL，因为有一些配置选项更改后需要重新启动才能生效。这种类型的切换被称为计划内切换。要成功地执行此类切换，需要完成以下步骤： 1. 确定将哪个副本切换为新的源。这通常是一个包含所有数据的副本。这就是要操作的目标。 2. 检查延时，确保延时在秒级别。 3. 通过设置super_read_only停止数据写入源服务器。 [6] 4. 等待副本与目标完
2025-05-19 08:59:54
524
原创 第9章-1 复制
在启用半同步复制后，源在完成每个事务提交时，都需要确保事务至少被一个副本所接收。（所需的完成确认的副本数量是一个可配置的选项（rpl_semi_sync_source_wait_for_replica_count）。在一个更大的集群中，可以考虑在提交事务之前有两个甚至三个副本完成确认）需要确认副本已收到并成功将其写入自己的中继日志（但不一定应用到本地数据）。 由于每个事务都必须等待其他节点的响应，因此该功能会给服务器执行的每个事务都增加额外的延迟。需要根据实际情况考虑是否开启该选项
2025-05-19 08:57:54
498
原创 第8章-10 慢日志查询
MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阀值的语句具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中，ong_query_time的默认值为10，意思是运行10S以上的语句。就会被认作是慢查询。 默认情况下，Mysq数据库并不启动慢查询日志，需要我们手动来设置这个参数，如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。
2025-05-14 10:46:35
774
原创 第8章-8 优化技巧1
平时使用的时候，注意排序和分页的处理，尤其是大数据分页的，最直接的就说限制返回的数量，而不是全部数据。 小表驱动大表这个使用的时候根据实际的数据量去判断，一搬字典表，区域表，这些是小表，业务表是大表。
2025-05-13 09:34:51
757
原创 第8章-6 索引失效的情况
平时在写sql的时候，要注意索引失效的情况。对于like的模糊查询，确实要用，数据量大，这时候，就要考虑多加一些限制条件，缩小查询范围，再模糊查询；如果不行，就要考虑使用其它方案，比如使用ES查询了
2025-05-12 09:29:05
456
原创 第8章-5 sql的执行顺序
整体过程1，先对多表进行关系,根据条件找出符合条件的记录2，在符合条件的基础上进行再次where条件筛选3，对筛选出来的内容进行分组操作4，分组完成后, 使用having再次筛选出满足条件的记录5，取所满足条件的记录6，对取出的记录进行排序7，最终从取出的记录当中获取多少条记录显示出来
2025-05-12 08:59:30
481
原创 第8章-4 查询性能优化2
如果把创建高性能应用程序比作一个环环相扣的“难题”，除了前面介绍的schema、索引和查询语句设计之外，查询优化应该是解开“难题”的最后一步。要想写一个好的查询，你必须理解schema设计、索引设计等，反之亦然。 理解查询是如何被执行的以及时间都消耗在哪些地方，依然是前面我们介绍的响应时间的一部分。如果再加上一些诸如解析和优化过程的知识，就可以更进一步地理解我们在第7章中讨论的MySQL如何访问表和索引的内容了。这也可从另一个维度帮助你理解MySQL在访问表和索引时查询和索引的关系。
2025-05-09 09:28:27
957
原创 第8章-3 查询性能优化1
因为服务器没有存储任何统计信息，所以MySQL查询优化器在生成查询的执行计划时，需要向存储引擎获取相应的统计信息。存储引擎则给优化器提供对应的统计信息，包括：每个表或者索引有多少个页面、每个表的每个索引的基数是多少、数据行和索引的长度是多少、索引的分布信息等。优化器根据这些信息来选择一个最优的执行计划。在后面的小节中我们将看到统计信息是如何影响优化器的，帮助你理解MySQL在访问表和索引时查询和索引的关系。 优化通常需要三管齐下：不做、少做、快速地做
2025-05-08 09:03:17
752
原创 第8章-2 查询执行的基础
MySQL 主要分为 Server 层和引擎层，Server 层主要包括连接器、查询缓存、分析器、优化器、执行器，同时还有一个日志模块（binlog），这个日志模块所有执行引擎都可以共用，redolog 只有 InnoDB 有。 查询语句的执行流程如下：权限校验（如果命中缓存）--->查询缓存（mysql8.0后就废弃了）--->分析器--->优化器--->权限校验--->执行器--->引擎
2025-05-08 08:58:31
568
原创 第8章-1 查询性能优化-优化数据访问
在前面的章节中，我们介绍了如何设计最优的库表结构、如何建立最好的索引，这些对于提高性能来说是必不可少的。但这些还不够——还需要合理地设计查询。如果查询写得很糟糕，即使库表结构再合理、索引再合适，也无法实现高性能。查询优化、索引优化、库表结构优化需要齐头并进，一个不落。在获得编写MySQL查询的经验的同时，你还将学习到如何为高效的查询设计表和索引。同样地，你也可以学习到在优化库表结构时会影响到哪些类型的查询。这个过程需要时间，建议大家在学习后面章节的时候多回头看看这些章节的内容。
2025-05-07 14:54:20
1596
原创 第7章-3 维护索引和表
那么如何判断一个系统创建的索引是合理的呢？一般来说，我们建议按响应时间来对查询进行分析。找出那些消耗最长时间的查询或者那些给服务器带来最大压力的查询，然后检查这些查询的schema、SQL语句和索引结构，判断是否有查询扫描了太多的行，是否做了很多额外的排序或者使用了临时表，是否使用随机I/O访问数据，或者是否有太多回表查询查询那些不在索引中的列的操作。 如果一个查询无法从所有可能的索引中获益，则应该看看是否可以创建一个更合适的索引来提升性能。如果不行，还可以看看是否可以重写该查询，将其
2025-05-07 14:45:24
839
原创 第7章-2 高性能的索引策略
高效地选择和使用索引有很多种方式，其中有些是针对特殊案例的优化方法，有些则是针对特定行为的优化。（MySQL优化器是一个非常神秘且强大的“装置”，不过还好，它的“强大”应该略胜于“神秘”一筹。鉴于它查找最优执行计划的方式，你应该更多依靠EXPLAIN和具体业务负载情况，来决定最优的执行策略） 使用哪个索引，以及如何评估选择不同索引对性能的影响，则需要持续不断地学习。
2025-05-06 09:14:04
977
原创 第7章-1 索引类型
索引，在MySQL中也叫作键（key），是存储引擎用于快速找到记录的一种数据结构。要想获得好的性能，索引至关重要。尤其是当表中的数据量越来越大时，索引对性能的影响愈发重要。在数据量较小且负载较低时，缺少合适的索引对性能的影响可能还不明显，但当数据量逐渐增大时，性能会急剧下降（在本书的第4章介绍过，各种固态硬盘在性能上有一些不一样的特点。索引的原则依然成立，相比传统硬盘，在SSD设备上，糟糕的索引带来的负面影响要稍微小一些）。
2025-05-06 09:00:01
783
原创 第5章-3 安全设置
如果运行的是专用数据库服务器，那么可以设置的最佳选项是innodb_dedicated_server，它可以处理90%的性能配置。如果无法使用此选项，那么最重要的两个选项是：● innodb_buffer_pool_size● innodb_log_file_size
2025-04-23 08:37:22
571
原创 第5章-2 配置MySQL的I/O行为
一些配置选项会影响MySQL将数据同步到磁盘和执行恢复的方式。这会涉及I/O操作，因此会极大地影响性能。这些选项还代表了性能和数据安全之间的权衡。一般来说，确保数据立即且一致地写入磁盘的代价是很高的。如果愿意冒磁盘写入操作没有真正写入持久存储的风险，是可以增加并发性和/或减少I/O等待的，但你必须自己决定可以承受多大风险。
2025-04-23 08:33:18
614
原创 第5章-1 优化服务器设置
本章我们将解释如何为MySQL服务器创建合适的配置文件。这是一个迂回的旅程，有许多兴趣点和可以俯瞰风景的短途旅程。这些短途旅程是必要的。确定合适配置的最短路径并不是从研究配置选项并询问应该设置哪些配置或如何更改它们开始的，也不是从检查服务器行为并询问是否有任何配置选项可以改善它开始的。最好从了解MySQL的内部结构和行为开始。然后，你可以使用这些知识作为如何配置MySQL的指南。最后，你可以将期望的配置与当前配置进行比较，并纠正任何重要和值得修改的差异。
2025-04-22 09:39:33
706
原创 第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
910
原创 第6章-2 schema管理
请记住以下指导原则： ● 尽量避免在设计中出现极端情况，例如，强制执行非常复杂的查询或者包含很多列的表设计（很多的意思是介于有点多和非常多之间）。 ● 使用小的、简单的、适当的数据类型，并避免使用NULL，除非确实是对真实数据进行建模的正确方法。 ● 尝试使用相同的数据类型来存储相似或相关的值，尤其是在联接条件中使用这些值时。 ● 注意可变长度字符串，它可能会导致临时表和排序的全长内存分配不乐观。 ● 如果可能的话，尝
2025-04-21 08:57:21
547
原创 第6章-1 数据类型
良好的逻辑设计和物理设计是高性能的基石，应该根据系统将要运行的特定查询设计schema。这通常需要权衡各种因素。例如，反范式的schema可以加速某些类型的查询，但同时可能减慢其他类型的查询。添加计数器和汇总表是一个优化查询的好方法，但它们的维护成本可能很高。MySQL的某些独有的特性和实现细节对性能的影响也很大。
2025-04-21 08:54:28
1077
原创 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
577
原创 第4章-5 linux 网络管理
三次握手，其实就是主动打开方，发送 SYN，表示要建立连接，然后被动打开方对此进行确认，然后主动方收到确认之后，对确认进行确认；
2025-04-16 08:53:56
710
原创 第4章-3 linux 内存管理
在概念上来讲，虚拟内存被组织为由存放在磁盘上的 N 个连续的字节大小的单元组成的数组。每个字节都有唯一的虚拟地址，作为到数组的索引(现在我们知道了虚拟内存虽然叫做内存，但其实它并不在内存中，而是磁盘中的一块空间)。虚拟内存与物理内存构成了一个缓存系统。虚拟内存位于较低层，物理内存位于较高层。虚拟内存上的数据可以被缓存到主存中。VM 系统将虚拟内存分割为称为虚拟页(Virtual Page)的大小固定的块，每个虚拟页的大小为 P=pow(2,p)字节。
2025-04-15 08:01:13
1059
原创 第4章-2 CPU 优化
操作系统和 CPU 硬件配合，系统不繁忙的时候，为了节约电能和降低温度，它会将 CPU降频进入节能模式。在 server 环境的 CPU 一定要关闭节能模式，节能模式不适应于服务器环境。关闭 CPU 的节能模式有两种方法： 1) 在 BIOS 中进行设置，彻底关闭； 2) 关闭 Linux 中的服务 cpuspeed 和 irqbalance；
2025-04-15 07:56:20
630
原创 第4章-1 操作系统和硬件优化
带有旋转盘片和摆动磁头的硬盘驱动器有其固有的局限性和特性，这是所涉及的物理现象的后果。固态存储也是如此，它建立在闪存之上。不要以为固态存储很简单。在某些方面，它实际上比硬盘更复杂。闪存的局限性非常严重，很难克服，因此典型的固态设备具有复杂的体系结构，包含大量抽象、缓存和专有的“魔法”。闪存最重要的特点是，它可以被快速地多次读取，而且以很小的单元读取数据，但写入则要困难得多。只有进行特殊的擦除操作之后，存储单元才能被重新写入数据，并且每次擦除的块大小较大（例如512K B）。
2025-04-14 16:47:26
612
原创 第3章-2 Performance Schema 使用
Performance Schema是一个经常受到批评的特性。早期版本的MySQL对其的实现不够理想，导致资源消耗较高。通常的建议是干脆关掉它。 这也被认为是难以理解的。只是启用了一些插桩代码，这些代码用于记录数据并将其提交给消费者表。消费者表是一些内存表，需要使用标准SQL语句查询数据，获取信息。了解了Performance Schema如何管理自己的内存后，你就能认识到MySQL并没有泄漏内存，它只是将消费者数据保存在内存中，这些内存只有在MySQL重启时才会释放。
2025-04-09 07:06:33
1082
原创 第3章-1 Performance Schema
Performance Schema提供了有关MySQL服务器内部运行的操作上的底层指标。两个概念。第一个概念是程序插桩程序插桩在MySQL代码中插入探测代码，以获取我们想了解的信息。例如，如果想收集关于元数据锁的使用情况，需要启用wait/lock/meta-data/sql/mdl这个插桩。第二个概念是消费者表（consumer），指的是存储关于程序插桩代码信息的表。如果我们为查询模块添加插桩，相应的消费者表将记录诸如执行总数、未使用索引的次数、花费的时间等信息。
2025-04-09 07:01:56
703
原创 第2张-2 度量长期性能
在规划需要长期监控的指标时，为所有使用自增主键的表监控剩余整数空间是一个简单的操作，但几乎可以肯定的一点是，它会在将来为你避免一些重大事故，因为可以提前预测需要更大的键空间。将数据分解为可管理的小块，这项工作不是在数据对于一个集群来说太大的时候才开始的，而是在此之前，当你还在为提供成功的客户体验确定目标时开始的。如果你的数据库达到一定规模，从备份恢复所需的时间将超过恢复业务关键功能所需的时间，那么即使其他一切运行正常，也需要检查调整的MTTR目标，更改“关键功能”的定义，或找到缩短备份还原时间的方法。
2025-04-08 07:05:29
598
原创 第2章-1 可靠性工程世界中的监控
在讨论如何衡量客户对数据库集群的性能是否满意之前，我们必须首先知道目标是什么，并使用通俗的说法来表述这些目标。这里有一些问题，可以作为组织中确定这些目标的引导话题：● 衡量成功的合理指标是什么？● 客户和我们的业务需求可以接受这些指标的哪些值？● 在什么情况下会被视为处于降级状态？● 什么时候处于完全失败的状态，需要尽快补救？在某些情况下这些问题的答案是显而易见的（例如，源数据库故障，此时无法进行任何写入操作，这会导致业务暂停运作）。
2025-04-08 07:02:52
878
原创 java 正则表达式优化
正则表达式使用一些特定的元字符来检索、匹配以及替换符合规则的字符串。构造正则表达式语法的元字符，由普通字符、标准字符、限定字符（量词）、定位字符（边界字符）组成。
2025-04-06 17:02:48
1030
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人